GRASS Project Steering Commitee
This page discusses the need for a GRASS Project Steering Commitee (PSC), preferably at a low level of complication.
1st Letter to GRASS mailing lists
02/10/2006 06:15 PM Dear GRASS community, in the Chicago meeting the GRASS project was suggested to as one of the initial OSGeo foundation projects. So far I only received positive feedback on the idea of moving GRASS more formally to the foundation (while the individual authors are keeping their copyright which is a major difference to the Apache Foundation.) A couple of things will have to be sorted out in the coming months to make GRASS's membership possible (below list is inspired by Frank's mail to the GRASS project): o We will need to form a "GRASS Project Steering Committee" (PSC). Foundation projects need a formalized management which may be desired in any case. I would be glad to receive suggestions of names for this committee. For inspiration, please look at the MapServer Technical Steering Committee as described here: http://mapserver.gis.umn.edu/development/rfc/ms-rfc-1 o One benefit of the foundation is some degree of legal support and protection for the project. The flip side of that is that the foundation needs to ensure some degree of rigor and process in how code comes into the project. One part of that is getting committers to sign a legal agreement indicating that they agree that changes they commit will be under the license of GRASS (GPL) and that they have the right to submit the code (they wrote it, it is not patented, have permission from their employer, etc). o We will have to review the existing code base (which is huge - more than 500000 lines of source code in GRASS 6). Luckily a major code review was already done for GRASS 5. Also the "Debianization" process was performed for GRASS 5 and GRASS 6. o It is suggested to move the support infrastructure for GRASS to new foundation systems. Stuff like CVS (maybe SVN then), and bugtracker and mailing lists. The web site will also likely appear under a foundation subdomain (ie. grass.osgeo.org) with hopefully the known mirror site structure as before with grass.itc.it, grass.ibiblio.org etc as principal mirror sites. If so, the web site will be migrated into a contents management system (CMS) in a harmonized "foundation style". A CMS will hopefully solve the problem to get more people involved in the Web site contents management. o We hope to establish options to enable sponorship for the foundation - be as direct funding or for selected foundation projects. Details have to be worked out. My suggestion is to create national tax-exempt organizations (such as the German GRASS Anwender-Vereinigung e.V. which already exists) which may offer to receive donations. o For now we should think about nominating people with recognized contribution to the GRASS project, to free data, to whatever deems significant. A small paragraph describing why the candidate is proposed as member to the foundation is needed as well. This will be announced more formally soon. Please see ongoing discussions here: http://lists.osgeo.org/mailman/listinfo/discuss (Nearly) nothing is set in stone yet. More details will follow, a couple of official documents are being currently prepared Your feedback is welcome. Markus
2nd Letter to GRASS mailing lists
02/11/2006 12:16 AM Dear all, while I already received two suggestions for a GRASS Project Steering Committee (PSC), I suggest to post the nominations in public, if there are no objections. I would like to have that transparent to everyone. Nominations should contain the name and a short paragraph why it is a good candidate. We also have to decide, how many members the PSC should have. It is worth reading - http://www.apache.org/foundation/how-it-works.html (they are very successful, and the document applies much to the GRASS project culture) - http://mapserver.gis.umn.edu/development/rfc/ms-rfc-1/ (MS RFC 1: Technical Steering Committee Guidelines) apparently 7 members there. - http://lists.maptools.org/pipermail/gdal-dev/2006-February/thread.html#7881 (GDAL PSC to be formed) - http://mapserver.gis.umn.edu/development/rfc/ms-rfc-10/ (MS RFC 10: Joining the Open Source Geospatial Foundation) Related: - https://sourceforge.net/mailarchive/forum.php?thread_id=9682788&forum_id=475 (Community MapBuilder PMC membership nomination) - https://sourceforge.net/mailarchive/forum.php?thread_id=9673493&forum_id=475 (MapBuilder & Mapbender and the OSGeo Foundation) In fact, there is lot of material to digest in these days.. Markus
3rd Letter to GRASS Dev mailing list
Markus Neteler neteler at itc.it Sun, 23 Apr 2006 18:10:25 +0200 On Sat, Apr 22, 2006 at 01:00:01PM +0100, Glynn Clements wrote: ... > Alpha support in the current display architecture isn't going to > happen (I reverted the last attempt to add it, and will do likewise in > future). ... this is why I really suggest to get interested in a project steering committee , . Instead of recursively reverted changes of other developers, we should come up with a design discussion and then *vote* on it. At least for such crucidal pieces of the code I would like to see less anarchy and a more formal approach. This will render development more transparent to everybody. The scope cannot be to have two display management systems in parallel, one without and one with alpha support. Existing steering committees, to get inspired from: Mapserver: http://mapserver.gis.umn.edu/development/rfc/ms-rfc-1 GDAL: http://www.gdal.org/rfc1_pmc.html Mapbender: http://www.mapbender.org/index.php/Mapbender_PSC ... Please think about it! Thanks Markus  http://grass.itc.it/pipermail/grass5/2006-February/021178.html  http://grass.itc.it/pipermail/grass5/2006-April/022185.html
The comments were copied from the related emails.
- Michael Barton (nominated by 1): very responsive to comments and questions; various code contributions
- Radim Blazek (nominated by 1): for his extensive GRASS work including vector and DBMS support
- Hamish Bowman (nominated by 1): for documentation, integration, and various modules
- Brad Douglas (nominated by 1): for clone removal and code refactoring
- Glynn Clements (nominated by 1): for his vast knowledge of standards, practices and compatibility
- Paul Kelly (nominated by 1): for PROJ and platform support
- Markus Neteler (nominated by 2): for the obvious. :-)
- Cedric Shock (nominated by 1): various code contributions
Status July 2006
The story got stuck due to the low interest among GRASS developers. We'll see for the future.