[mapguide-psc] RFC process...

[Paul Spencer]

Jason, I agree in principle but not in practice.  Don't forget that  
this is an open source project and we are trying to encourage  
participation and contribution through volunteer efforts :)

If someone has thought through and implemented a workable solution,  
that's actually a pretty decent start.  It may not be the best way to  
solve a problem, but as long as the code is sound and architecturally  
in line with the project, it is better to have the feature than to  
not have it.

People will generally contribute stuff that solves a problem for  
them, not for anyone else.  There is not a lot of incentive to solve  
a problem that doesn't impact them.

We (the PSC) has the power to accept or reject an RFC, or to turn it  
back for rewriting with comments.  And at the end of the day, it is a  
group decision to accept it.  I, for one, will be happy to get any  
outside contributions and will be generally accepting of those  
contributions even if they don't meet all potential needs.  You have  
to start somewhere.

Anyway, that's my opinion ... :)

Cheers

Paul

On 28-Oct-06, at 1:17 PM, Jason Birch wrote:

> 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
>>
>>
>
>
>
> <winmail.dat>

+-----------------------------------------------------------------+
|Paul Spencer                          pspencer at dmsolutions.ca    |
+-----------------------------------------------------------------+
|Chief Technology Officer                                         |
|DM Solutions Group Inc                http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+