[mapguide-psc] RFC process...

[Jason Birch]

Does working group sound better? :)
 
I think that the website, documentation, etc will be an area where non-developers will really be able to contribute, and the split between coding/presentation is clear enough (at least in my fuzzy mind) that splitting the work between coders/documentors would be reasonable.  As an aside, I think that these two roles would need to be distinct in LDAP.  Anyway, this is a while down the road and will come up again.
 
I don't buy that a solution a developer has thought through and even coded themselves is necessesarily the best solution for the project.  By nature a single individual, or even a single organisation, does not have the breadth of experience or understanding of the problem realm to create a solution that is the best fit for our entire user base.  We need to ensure that the project does not turn into a Frankenstein's monster of solutions that have been built in isolation.  The problem is that the investment (time and emotion) in fait-accomplis solutions is such that it is difficult to shift their path once they are presented unless there is a severe defect.
 
I concede that a lot of the existing development will likely come as pre-canned solutions because of where this project is starting from, and that in some cases it will be desirable to accept contributions to the code base that have been developed in isolation, but I really want to stress that by default we should have open development starting at the conceptualisation phase.
 
Jason

 
________________________________

From: Robert Bray [mailto:rbray at robertbray.net]
Sent: Sat 2006-10-28 12:00 AM
To: psc at mapguide.osgeo.org
Subject: Re: [mapguide-psc] RFC process...



Jason,

Personally I would like to avoid subcommittees, mainly because of the
pain OSGeo is feeling now due to fragmentation. Whether we need an RFC
for the web site is a different debate, maybe / maybe not. It really
depends on the scope of the change.

To address your core concern though, I expect a mix of RFCs. Some will
start with lots of discussion on the dev list and evolve into a fully
baked RFC. Others may come pre-baked, because the developer has already
thought it through pretty thoroughly (and maybe even has a prototype
running). It really depends highly on the author and what is being
proposed. The key is to welcome active discussion of ideas on the dev
list. Also remember that an RFC is a living document up until the time
it is voted on and approved. It can start with just an idea and no
implementation detail. We should make that clear on the how to create an
RFC page (hmm guess we need one of those).

Does that clarify or confuse the issue more?

Bob

Jason Birch wrote:
> http://wiki.osgeo.org/index.php/MapGuide_RFC_Template
> 
> Do we really want the RFC process to apply to the web site?  Maybe for major overhauls, but personally I think that this kind of thing could be better dealt with informally, perhaps by a web site subcommittee. 
> 
> Also, I'm a bit scared of an RFC process that appears to expect the presentation of a well-thought-out canned solution, which is then subject to debate on the DEV list.  I think that we should be encouraging an informal process where a problem/solution pair (or just the problem) is put forward to the DEV list/channel as a rough WIKI page, and is then debated and polished into a form where it can be submitted as an RFC.
> 
> This kind of process gives us better solutions, and ensures that the original submitter only needs to do a limited amount of work before starting the discussion, reducing the emotional attachment to a particular solution.
>
> Jason
>
>  



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 6318 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/mapguide_psc/attachments/20061028/9abc7c86/attachment.bin