Someone who knows this should write the early days. Starting in 2009-2010, some Oregon agencies evaluated and selected GeoMoose for online webmapping. Part of that included numerous additions to the GM project. It is the Oregon agencies' goal for most or all of these contributions to make it into the core GM project and advance the project. Independent one-off implementations don't really help us or move the project forward, particularly, where does it leave us in three to five years after having extensively diverged from the main project? Up the creek. Also we hope that our efforts engage others to get their efforts into the core project. That way we all move along forward with the project rather than all moving apart with incompatible slightly different projects. The current governance structure appears a little casual and ad hoc. Several email threads on the email list initiated interest in formalizing some governance structure and now this wiki page.

• MapServer - MapServer RFC1 superseded by: MapServer RFC23
• OpenLayers - How to contribute to OpenLayers
• OpenLayers Steering Committee- OpenLayers Steering Committee
• GDAL, which is what OpenLayers cites as their model, GDAL RFC1

1. They are all almost the same with many word for word sections, also all written originally by Frank Warmerdam.
2. They are loosely based on the Apache project
3. They seem reasonable and match many OSGEO projects

1. Decide if these example governance models match the project done. We like MapServer RFC23.
2. Ask a project if you can copy their work - Done. FrankW says both MapServer RFC1 and GDAL RFC1 are free for adoption, adaption, and copying. Steve gave ok on MS RFC23 too.
3. Write an RFC to adopt the governance model and set out initial PSC - done 9/17/2011
4. Announce RFC
5. Amend RFC as needed based on comments
6. Call for vote on RFC
7. If RFC passes, declare it passed and implement the RFC

with some subsequent lime green bold italic comments by Eli

• Feel free to add comments here, using a color and identifying yourself may help keep it readable. Try something like:

'''''<span style="color:#32CD32"> with some subsequent lime green bold italic comments by Eli</span>'''''

More info here

• 1. Someone proposes an idea/need/wishlist through a “Request for Comments” (RFC). This needs to include whether the proposer has funding to complete or looking for additional funding.

I think that an RFC should be sufficiently technical so that other developers can evaluate it. I don't think that funding is relevant to an RFC, although most RFCs should only be written once someone has resources (money or developer time) to do something about the RFC. If you have no way to implement the RFC, then it doesn't need writing. Finding funding should be independent of the RFC. General idea/need/wishlists can go on the roadmap and sit until it is actually going to be implemented then a more detailed technical RFC can be written for it.

• 2. The community comments RFC for the proposer.

Sounds good. This is also the time for users to raise suggestions for changes and developers to give a conceptual peer review

• 2.5) What about the Project Steering Committee voting here? +1/-1 with a goal of consensus.
• 3. The proposer develops the RFC into a real application/widget/thing the community and Project Steering Committee (PSC) can see/test. The PSC was loosely defined in the past, but this probably needs to be re-visited again.

Yes, perhaps an early RFC to adopt the RFC process and PSC and require votes and procedures for new code committers.

• 4. The PSC then votes whether this should go into the core code or not. Does it follow coding guidelines, what ramifications does it have, etc…

I think that you should be able to get a vote before actually DOING the work. If you don't do the work in the manner that you said, it breaks existing code, or you use improper style, then you are not complying with the rules for being a code committer and what you said in the RFC. PSC and others can call you on this and you must fix it satisfactorily and adhere to the norms or presumably your committer status could be jeopardized.

• 5. The code is committed if it is accepted or it becomes a contributed user extension or a code snippet. Need to figure out the details on who would review the code and actually committ it to the GeoMOOSE SVN.

I think that nearly all work should be in the GM source repository. It may be a branch or spike, or something else other than trunk but we really need to cut down the numerous independent implementations of the same feature that never makes it to trunk. That doesn't really advance the project.

• This page was last modified on 17 September 2011, at 17:03.