[GRASS5] Project Steering Committee voting

[Helena Mitasova]

Frank, Markus,

if people on this list do not follow osgeo activities, it hard to 
understand from emails that Markus posted
what is needed for GRASS project incubation, setting up PSC, etc. So I 
am not surprised at all by Glynn's questions,
I had similar ones. So Markus, if you could let us know what needs to be 
done - step 1.2.3,
maybe we will get it moving. We have nominations for the PSC but nobody 
said what is next step - who votes
to set it up etc.
Frank, thank you for your explanation - this helps a lot - now we need 
to know what is the next step after nominations.
And BTW, as I have already expressed to Markus, we should really keep 
the management structures and procedures
to minimum (there already was a GRASS steering committee, GRASS 
interagency committe, GRASS foundation
and soon everybody is sitting in meetings and nobody has time for 
development and you also lose the freespirit
of open source development), so I am with Glynn on this, but
a minimal steering committee is really needed for reasons well explained 
by Frank,

Helena
 

Frank Warmerdam wrote:
> Glynn Clements wrote:
>> Markus Neteler wrote:
>>> Instead of recursively reverted changes of other developers,
>>> we should come up with a design discussion and then *vote* on it.
>>
>> Who gets to vote? Anyone who wants to, only people who contribute
>> code, only people who will be affected by the decision, ...?
>
> Glynn,
>
> I will respond based on how the MapServer or GDAL/OGR PSC operate.
> There is certainly latitude for the GRASS community to define a PSC
> that operates slightly differently.
>
> Only the members of the PSC would get to vote.  However, the
> discussion and voting would normally occur on the public project
> mailing list and anyone can express an opinion.
>
>> E.g. with a display architecture, the risk is that "application"
>> developers would vote for the ultimate graphics API which includes
>> everything provided by both OpenGL and PostScript and then some
>> extras, which consequently never gets implemented.
>
> Normally the practice is that someone interested in implementing
> a feature must prepare a proposal.  This would be then discussed,
> and potentially revised by the original proposer based on feedback
> before a formal vote.
>
> The GDAL and MapServer (and Apache) practice is that anyone who
> votes +1 (ie. supporting the proposal) is also agreeing to help
> with implementation if needed.  But for the most part the original
> proposer is responsible for implementing what they have proposed.
> This highly motivates proposers to only propose what they are
> prepared to implement.
>
>>> At least for such crucidal pieces of the code I would like to see 
>>> less anarchy and a more formal approach.
>>
>> I'd certainly agree with the "less anarchy" part, although I'm not
>> sure that a "committee" is the answer. The mailing list is a perfectly
>> suitable forum; people just need to use it (the first thing anyone
>> heard about the alpha "enhancement" was a message informing everyone
>> that it had been committed).
>
> Note that PSC committee discussions would be occuring on the public
> mailing list.  The PSC primarily provides a formal way of deciding
> whether to adopt a proposal when it is unclear.   The proposal
> process is also very helpful in preventing the sort of surprise you
> seem to have run into.
>
>> A simpler solution would be to have defined maintainers for specific
>> sections of the code base. Developers would be expected to discuss any
>> non-trivial changes to another developer's section beforehand. 
>> Maintainers would have more liberty to act within their own section,
>> but would still be expected to discuss more substantial changes,
>> particularly if the changes would be "visible" to users or other
>> developers (as opposed to purely internal changes such as refactoring
>> or optimisation).
>
> This is essentially the process taken by the GeoTools project.  They
> have the GeoTools code base clearly broken into something like 10
> modules, and each module has a module maintainer that is responsible
> for their module, and relatively free to make internal changes as
> desired.
>
> I do think having module maintainers is a good idea if you have some
> sort of logical way of segmenting the code, end have folks willing
> to take on the responsibility for sections.  But I think that having
> public discussions of anything that could affect users or other modules
> is important.
>
> I would like to stress that a PSC based process is used by many 
> successful
> community projects.  It is part of the Apache process for all Apache
> projects.  It is already used by GeoTools and MapServer quite 
> successfully.
> And with project specific variations it will be used for other OSGeo 
> projects.
> This is not a radical idea.  It is a "best practice" for open source 
> projects.
>
> On a more meta level, I feel the GRASS community is not going out of it's
> way to support Markus as he tries to bring GRASS into OSGeo.   He needs
> senior members of the GRASS community to get involved, and support this
> migration work.  That means working on a PSC charter, following the
> "incubation process", helping with code copyright review, and 
> participating
> in other OSGeo activities.
>
> The GRASS community has a lot of offer OSGeo and I hope OSGeo has a 
> lot to
> offer the GRASS community.  You can tailor GRASS's involvement and also
> contribute to the overall direction of the foundation.  Already the GRASS
> community feedback on the risk of relicensing has been taken very 
> seriously
> and contributed to us dropping the idea of contributor agreements.
>
> PS. Sorry for missing Glynn's question about PSC voting on the first 
> pass.
> I have been skipping all the "suggested color function names" emails 
> assuming
> they were related to some esoteric detail of little interest to me.   
> I have
> taken the liberty of retitling this email.
>
> Best regards,


-- 
Helena Mitasova
Department of Marine, Earth and Atmospheric Sciences
North Carolina State University
1125 Jordan Hall
NCSU Box 8208
Raleigh, NC 27695-8208
http://skagit.meas.ncsu.edu/~helena/

email: hmitaso at unity.ncsu.edu
ph: 919-513-1327 (no voicemail)
fax 919 515-7802