[Gnumed-devel] Gnumed governance junta plus development guidelines

[Jim Busser]

<x-tad-smaller>Does the following look appropriate to add to the wiki, linked from gnumed.org?
------------------------------------------------------------------------


Key area coordinators for GnuMed (referencing also our wiki RoadMap):

</x-tad-smaller>
> <x-tad-smaller>per http://mail.gnu.org/archive/html/gnumed-devel/2003-11/msg00119.html
>
> 1. Karsten: backend database schemas, bootstrapping of same, i18n policing
> 2. Ian: middleware layer
> 3. Syan: wxPython frontend
> 4. ?: packaging
> 5. ?: Documentation
> </x-tad-smaller>
<x-tad-smaller>


Module-design guidelines (springing from referenced example problem):

</x-tad-smaller>
> <x-tad-smaller>http://mail.gnu.org/archive/html/gnumed-devel/2002-11/msg00024.html
>
> (posted by Horst)
> I am just in the process of hooking gmDemographics.py up to the backend.
> I fail to understand the philosophy behind it.
>
> The gmDemographics plugin extends the top line of the tool bar - so far so 
> good. Would have been nicer to implement it as an independent panel which is 
> the added to the toolbar as a whole, but that can still be done. 
>
> But then - how dare the "PatientPanel" grab hold of the plugin and set up 
> event handlers for it? Never! This is akin with using global variables.
>
> Each GUI panel must be a self sufficient black box, communicating with other 
> panels ONLY via messages or with the main process via the broker objects. 
> Always.
>
> In the current example the plugin must set up wx event handlers for the 
> "search" event, and the post a message "gmSignals.PatientSelected()" via the 
> dispatcher. How else should other GUI elements get notice that something that 
> they are concerned with has changed?
>
> Please read the relevant online documentation at 
> </x-tad-smaller><x-tad-smaller>http://gnumed.net/whitepapers/messenging.html</x-tad-smaller><x-tad-smaller>
> and
> </x-tad-smaller><x-tad-smaller>http://gnumed.net/whitepapers/signals.html
> </x-tad-smaller>
<x-tad-smaller>

</x-tad-smaller><x-tad-smaller>CVS Guidelines... bordering on rules... maybe "Code of Conduct?"

</x-tad-smaller>
> <x-tad-smaller>reference http://mail.gnu.org/archive/html/gnumed-devel/2003-11/msg00126.html
> reference http://mail.gnu.org/archive/html/gnumed-devel/2003-11/threads.html#00126
> </x-tad-smaller>
> <x-tad-smaller>The most important rule is that you have to think before commiting.
> Code, test, retest, make sure you did not introduce new bugs, if unsure 
> contact the author of that code or admininistator. For anything significant, if you do not receive sufficient feedback within a reasonable timeframe inqire again. Do not assume saying nothing means approval.
>
> </x-tad-smaller><x-tad-smaller>1.) start your work in test-area</x-tad-smaller><x-tad-smaller>
> </x-tad-smaller><x-tad-smaller>11.) take a close look at what code is already in CVS, use existing code</x-tad-smaller><x-tad-smaller> </x-tad-smaller><x-tad-smaller>whenever possible, enhance existing code whenever necessary</x-tad-smaller><x-tad-smaller>
> </x-tad-smaller><x-tad-smaller>8.) do NOT mix tabs and spaces when indenting (tabs preferred, pure space acceptable)
> adhere to module-writing guidelines, no accessing the SQL tables directly, only through business objects</x-tad-smaller><x-tad-smaller>
> 2.) </x-tad-smaller><x-tad-smaller>commits to CVS must be small AND working -OR- peer reviewed -OR- for an area/file YOU are maintaining *</x-tad-smaller><x-tad-smaller>
> </x-tad-smaller><x-tad-smaller>3.) patches not meeting the above will not make it into CVS (main trunk)</x-tad-smaller><x-tad-smaller>
> </x-tad-smaller><x-tad-smaller>4.) comment your code ( and I mean comment everything even if it might seem</x-tad-smaller><x-tad-smaller> </x-tad-smaller><x-tad-smaller>stupid to you !!!! )</x-tad-smaller><x-tad-smaller>
> </x-tad-smaller><x-tad-smaller>5.) uncommented code (new files etc. ) will not make it into the main trunk
> 6.) submit early and often PROVIDED the code runs/ announce changes to the list</x-tad-smaller><x-tad-smaller>
> </x-tad-smaller><x-tad-smaller>7.) be aware that huge patches will most likely be ignored by peer</x-tad-smaller><x-tad-smaller> </x-tad-smaller><x-tad-smaller>reviewers unless they agree with it</x-tad-smaller><x-tad-smaller>
> </x-tad-smaller><x-tad-smaller>9.) never commit files you did not change</x-tad-smaller><x-tad-smaller>
> </x-tad-smaller><x-tad-smaller>10.) add commit comments to each file you commit !!!</x-tad-smaller><x-tad-smaller>
> </x-tad-smaller><x-tad-smaller>12.) wanna code your own client ? That's perfectly fine . Please stick to</x-tad-smaller><x-tad-smaller> </x-tad-smaller><x-tad-smaller>test-area for that</x-tad-smaller><x-tad-smaller>
>
> * If you code like crazy in test-area and add new functions to files 
> you are not responsible for (you did not append it initially or have not take 
> over the duty of maintaining the file) do not commit substantial changes 
> without contacting the guy that is responsible for the file.
> </x-tad-smaller>