[GRASS5] Proposal: RFC 1: Project Steering Committee Guidelines

[Hamish]

A couple of small thoughts,

For a technical committee I would say anyone with write access to CVS
who has committed something in the last 12 months could vote.
Can anyone throw together a cvs2cl.pl parsing script to generate that?
  [invitation for other non-CVS active contributors to speak up now..]
I don't think this should be all too strict, if someone becomes emeritus
by a script, it should be simple for them to rejoin by offering a small
gift of code to the CVS ;). By CVS I mean CVS+Bug Tracker+ future SVN
documentation team. I know there are a lot of translation people I don't
know well. How to include them?

For an executive committee I would leave it to fewer people (say 5-7).
They would be shepherds for copyright, trademark, license, website, etc.
Hopefully wouldn't have to be used often and work could be passed
through them to OSGeo :) Obviously they shouldn't (and legally couldn't)
be making relicensing etc decisions without the approval of the
technical committee/everyone. The technical committee could vote
(annually?) on who sits on this, or maybe better it could be
bootstrapped with nominations and empty seats filled as they become
vacant (by general tech committee vote).

I see the need more for an executive committee than a technical one, or
at least I am nervous that there is nothing in place in the event that
such a matter needs an executive decision made quickly and clearly by
the group.

For technical decisions I think the grass5 list has worked very well up
to now, I see no pressing need to go changing it too radically, and
worry that to do so could needlessly slow development. Remember for
these items we are interested in technical answers not political ones.
Votes force an answer unnaturally at one moment in time instead of
letting the answer and consensus grow naturally. We are lucky that we
have the option of no hard deadlines here so votes are needed less
often. (still we shouldn't argue trivial matters for years)

Yes, a new raster format will need a well thought out and published
plan. I am not all that familiar with the formulation of the new vector
library- can someone provide some history? I expect this is something
that is much harder to do well by a committee of many slightly
interested parties than it is to be done by a small team of full
knowledge coders. Probably with a single sub-project coordinator (not
dictator). I have a slight idea of how the original USACE team worked.
As well as the vector lib experience I expect Frank has some good
insights on this process that he could share with us?

A system where 50 people have voting rights and it only takes 2* +1
votes to pass something clearly has problems. Two people could pass a
strange idea before anyone else notices and then the result is ignored..
Ok, then it could be buried but then what was the point of the 2* +1
rule? Leave votes open for 5 days? Do Glynn's votes on raster matters
and Radim's votes on vector matters count more than mine? (honestly they
probably should..) Do I get veto rights on stuff which I am the primary
or sole author of?

I have no idea how to kick someone off of a committee / cvs access /
etc. in the free software context. Hopefully never, but in the event
would you have a public or private vote? (private means only exec
committee sees who voted what) The informal 12 month cvs commit/
contributing to the mailing list/somehow test could help keep the
voting member list relevant due to people moving on to other things
without many hurt feelings.