Leadership Team

The GeoNetwork project roadmap is managed using a proposal process, with the GeoNetwork leadership team voting on proposals made by members of our community. This process has moved from mailing list to a project board.

• Leadership Team (GeoNetwork Documentation)
• roadmap
• GeoNetwork Change Proposals (Archived)
• Committer Responsibility Guidelines

Proposals Process

1. Proposals are written up and submitted on the project roadmap board for discussion and voting, by any interested party, not just committee members.

   

2. Opportunity: The project board lists opportunity or challenge under consideration by project leadership.

   This is also used to share sponsorship opportunities for transparency with stakeholders and OSGeo.

3. Proposals are shared for review when ready, and should include a heading to record votes:

   ... Proposal...
   
   ## Why this important
   
   ... Proposal context ...
   
   ## Proposal Support 
   
   Indication of resources (financial and in-kind resources) required.
   
   ## Voting
   
   * 
   
   Community support:
   
   * non-voting member feedback here
   
   Core contributors:
   
   * Acknowledgements of sponsor, service provider, or customer funding this activity

4. Open for voting: Leadership team required to vote on proposals, although may comment on proposal, but only members of the leadership teams votes will be counted.

   • "+1 approve" vote to indicate support for the proposal and a willingness to support implementation.
   • "-1 veto" vote provided with clear reasoning and alternate approaches to resolving the problem within the two days.
   • A vote of "-0 discourage" indicates mild disagreement, but has no effect. A "+0 encourage" indicates mild support, but has no effect.

   Proposals need to be available for review for at least two business days before a final decision can be made.

5. Vetoed: If a proposal is vetoed (with a -1 vote an alternative suggestion):

   • Proposal is held as alternatives are discussed
   • Ideally proposal can be revised to satisfy all parties and accepted.
   • If it cannot be revised to satisfy all parties, then it can be resubmitted for an override vote (+1 positive, -1 negative) in which a majority of voters indicating +1 is sufficient to pass it. Project chair is required to vote in the event of a tie.

6. Accepted: A proposal will be accepted if it receives +2 (including the proposer) and no vetoes (-1).

7. Withdrawn: An accepted proposal may be withdrawn (for example of funding was not obtained, or if the opportunity is no longer available).

8. Done: Accepted proposals often turn into an issue or pull-request in GitHub, and can be marked done when complete.

When is Proposal Required?

• Anything that could cause backward compatibility issues.
• Adding substantial amounts of new code.
• Changing inter-subsystem APIs, or objects.
• Issues of procedure.
• When releases should take place.
• Anything that might be controversial.
• Add a new member to the PSC
• Add a new committer to the code repository

Observations

• The Chair is the ultimate adjudicator if things break down.
• The absolute majority rule can be used to override an obstructionist veto, but it is intended that in normal circumstances vetoers need to be convinced to withdraw their veto. We are trying to reach consensus.
• The Chair acts as GeoNetwork project officer representation to Open Source Geospatial Foundation.

See also the Authors document in the documentation