[mapguide-psc] RFC process...

[Jason Birch]

Oh no, can't close the discussion that easily; keep arguing :)  
 
Do you think that we should do away with the RFC project, and just let developers commit as they want?  I know that there are lots of developers that prefer to just build stuff, and most are smart enough to come up with solutions that are reasonably generic while solving their particular needs.  I don't want to discredit this kind of contribution.
 
I guess my main concern here is that if we design the RFC process as basically an afterthought, the PMC becomes a reactive and negative body rather than a proactive and positive one.  In open source development, egos play such a large role that when faced with complete solutions the PMC will likely choose to avoid confrontation unless there is a severe outstanding defect in the implementation.  Again, not having community direction and a common vision here will leave us with a Frankenstein's monster.  I have an incredible amout of respect for what happenned with the GeoRSS spec, and is now happening with the tiling spec, and would love to see that kind of process around new features in MapGuide.
 
I wasn't suggesting that the entire RFC process be completed before any code is implemented.  I think that once the initial collaborative brainstorming on the problem, general solution, and implications are done on the DEV list/channel (where the PMC participates), it would be safe to just go ahead and implement in a development branch, with the assurance that the feature already has the buy-in of the community.  At this point any changes made during the RFC process before commit to trunk would be minor at worst.
 
This would allow the PMC to take on a more positive role, setting a general vision and communicating any concerns with specific implementations on the DEV list at an early stage of development.  Any negative energy could be saved for features that are presented implementation-complete.
 
This whole discussion is only really relevant for large features/refactorings.  Small or obvious features (such as adding a new version of WMS support) will likely just be met with a "looks good" on the dev list, and then breeze through the RFC process.
 
Another option would be to make the acceptance process more rigourous.  Instead of requiring only two positive votes, a feature would require 50% + 1 of the active PMC to accept it.  While this might encourage developers to pay close attention to the direction set by the PMC for the product, it also has a considerable downside in required structure and uncertainty of feature adoption.
 
Jason

________________________________

From: Paul Spencer
Sent: Sun 2006-10-29 11:53 AM
To: psc at mapguide.osgeo.org
Subject: Re: [mapguide-psc] RFC process...



Jason,

 From mapserver experience, I know that there are some developers 
(who are committers even) who prefer not to go through the 
bureaucratic nausea of the RFC process to implement something.

I won't argue further against this point, but I really feel that it 
is both unnecessary and unnecessarily daunting.

I'm -0 on this :)

Paul


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 5882 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/mapguide_psc/attachments/20061029/24c86f7d/attachment.bin