[GRASS5] Project Steering Committee voting

[Frank Warmerdam]

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,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGF, http://osgeo.org