[GRASS5] Project Steering Committee voting
glynn at gclements.plus.com
Wed Apr 26 16:09:12 EDT 2006
Frank Warmerdam wrote:
> > 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.
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.
Also, there's no point in making formal proposals unless people are
going to review them, and reviewing proposals itself requires some
Glynn Clements <glynn at gclements.plus.com>
More information about the grass-dev