[GRASS5] Project Steering Committee voting
warmerdam at pobox.com
Wed Apr 26 23:24:45 EDT 2006
>> 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.
Glynn Clements wrote:
> OK, that makes sense. At least, in general.
> The problem with GRASS is that it is understaffed, in the sense that
> the total amount of code is large relative to the number of active
> developers. As a consequence, we can't afford to create too many
> obstacles for potential contributors.
I will assure you that most projects feel understaffed, but I will
concede that GRASS has a very large code base in proportion to the
developer time available to work on it. I've been amazed at the
substantial rework that has been accomplished on GRASS in recent years.
But you must carefully consider fundamental changes as they require
revisiting a lot of code!
I would add that having a mechanism for new contributors to go through
to "get permission" can in some ways be enabling. With mapserver
outside folks used to propose ideas on mapserver-dev from time to
time but only get a bit of vague feedback. It was very hard for them
to determine if they had permission to proceed, or what.
> Also, there's no point in making formal proposals unless people are
> going to review them, and reviewing proposals itself requires some
Agreed. But it isn't critical that everyone on the PSC or off do
a careful review of a proposal. If it does not seem to affect anything
you have an interest in, you can just let it slide with an implicit
vote of "no opinion". It is important that at least a few people
go over the proposals. Hopefully for any given area of the code there
will be at least one person interested in possible effects to comment
and vote. In the case of MapServer it only takes two +1's to pass a
proposal if there are no objections. So a potential contributor does
need to make a proposal interesting enough to get two people to review
and give a +1.
One approach that GeoTools uses is they have an area in source control
they call "the spike" (I think). Which is basically an experimental area
that folks can freely work on new and radical stuff without affecting the
baseline source tree. For GRASS it is easy to imagine such an area for
new experimental contributed programs. How to use such a thing for library
changes is less obvious.
In the case of GDAL I have generally taken a very liberal approach to
letting people contribute new drivers as long as they aren't disrupting builds.
So I think each project can work to provide a play area for work-in-progress
without a complex process.
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
More information about the grass-dev