[GRASS5] Project Steering Committee voting

Wed Apr 26 12:39:51 EDT 2006

Helena,

I thought that I had explained a few times the need of having
a steering committee. I agree on not adding much overhead.

But so far I got only negative responses on this while the
issue that one reverts the changes of others isn't really
solved.

In fact we have nominations for the PSC but nobody said what
is next step. The first step is that people agree on *having*
such structure. Only then we can render the nominations into
something else.

As far as I remember only Michael and Glynn answered, both
pointing out that a PSC is not desired.

The big question is maybe if people are interested to join
the OSGeo efforts or not. If not, it should also be discussed
how to maintain this project in future. So far we have sponsorship
from ITC-irst (web site structure, partial funding of developers
working at ITC-irst) and Intevation (CVS, RT). But this isn't
granted forever. I see OSGeo as an opportunity to give GRASS
a stable (secondary) home.

As Frank pointed out: the comments here on the "contributors agreement"
already had major impact. So it is not true that OSGeo would take
the software and do something else with it (this even doesn't
make sense).

Here the steps as I see them currently:

step 1: do we want to join the OSGeo foundation, at least make GRASS
        a foundation project?

if yes/no to 1:
  step 2: do we want to establish a project steering committee for
          general decisions

if yes to 1 and 2:
  step 3: how do we render the nominations into members (sort of 
          bootstrapping democracy)

if yes to 1, 2, 3:
  step 4: do the needed steps for incubation.

My emails so far:

ad 1: 
  http://www.grass.itc.it/pipermail/grass5/2006-February/021101.html
  http://www.grass.itc.it/pipermail/grass5/2006-February/021127.html

ad 2:
  http://grass.gdf-hannover.de/twiki/bin/view/GRASS/ProjectSteeringCommitee
  http://www.grass.itc.it/pipermail/grass5/2006-February/021178.html
  http://www.grass.itc.it/pipermail/grass5/2006-April/thread.html#22185

as 3:
  we could follow the other projects. Bootstrapping PSC is a sort of
  dictatorial thing (selection), later people can be elected/removed etc.
  No need to reinvent the wheel, there are many successful open source
  projects out there as Frank pointed out.

ad 4:
  http://www.grass.itc.it/pipermail/grass5/2006-February/021445.html
  http://grass.gdf-hannover.de/twiki/bin/view/GRASS/ProjectIncubation

Maybe my role here is unclear: I don't feel priviledged to take
these decisions myself. But apparently this is partially expected... or
at least that I guide the process. If so, I would guide it versus the
foundation. However, in my opinion we first need to agree upon very
basic things - see above.

In the OSGeo Wiki I have written some documents for a potential
incubation (things which we should do also without OSGeo!):

 http://wiki.osgeo.org/index.php/GRASS_Incubation_Progress
 http://wiki.osgeo.org/index.php/GRASS_Provenance_Review

The code provenance review we partially did for the change to GPL in 1999,
but tons of copyright statements are missing. I have received a nice perl
script to semi-automatize this from Schuyler Erle which I am happy to
add to the tools/ directory. Obviously I cannot review a few thousand
files myself... but a code review is needed from time to time.

Well, let's start with item (1) from above list.

Best

 Markus

On Wed, Apr 26, 2006 at 12:05:17PM -0400, Helena Mitasova wrote:
> 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
> 
> _______________________________________________
> grass5 mailing list
> grass5 at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5