Skip to content

Improvement Proposals

sbenthall edited this page Jun 25, 2012 · 10 revisions

This document is deprecated. For the current GeoNode process, please see Community Bylaws

GeoNode Improvement Proposals

GeoNode Improvement Proposals (GNIP) are the formal mechanism used to manage any sort of major change to GeoNode. While the definition of "major" is subject to interpretation, examples of changes which are managed by the GNIP process include:

  • Redesign or implementation of major features
  • Code re-architecture
  • Changes to GeoNode process or project policy

Only committers may submit a GeoNode Improvement Proposal. Non-commiters are encouraged to find a committer to sponsor their idea and guide them through the process. If there is ever a question as to whether a proposal should be written, please ask on the list.

Unlike the patch review process, the Improvement Proposal process has no special treatment for committers or even for Project Steering Committee members. The reason for this is that improvement proposal review serves another purpose besides ensuring changes made are acceptable to the community: it also gives GeoNode stakeholders time to consider and plan for large changes before they happen.

The Patch Review Process is related. While the Improvement Proposal process is intended to promote coordinated design and feedback for far-reaching modification such as core architectural changes, the code review process protects code quality in the GeoNode project at a fine granularity.

How a GNIP works

The typical life cycle of a GNIP is as follows:

  1. Developer has an intent to perform a major change

  2. Developer communicates with the community about the change

  3. Developer goes off and implements the change

  4. Developer writes a GNIP and presents it to the community for feedback

  5. The PSC votes on the GNIP. If the GNIP author is also a member of the PSC, he should still vote.

  6. Developer commits changes upon receiving a positive vote

Voting on a GNIP

One of the duties of the Geonode Project Steering Committee is to vote on GNIPs. The voting process works as follows:

  • The voting system used is the Apache consensus system. Each PSC member gets a single vote, which can be one of +1, -1, 0.

  • Any PSC member that votes negatively against a proposal must provide a reasonable explanation as to why. In general, reasonable negative votes should be based on criteria listed in Review Criteria.

  • Any PSC member that votes negatively against a proposal has a limited time to provide constructive feedback as to how the vote can be turned

  • The GNIP author must incorporate any reasonable feedback into the proposal

  • Any negative vote is reviewed to determine if criteria has been met to turn it to a positive vote

  • The proposal is considered successful after a majority of positive votes is a achieved and all feedback from any negative votes has been addressed

Non-PSC members of the GeoNode community are encouraged to participate in GNIP review, but a negative vote does not block the realization of the proposal unless it comes from a steering committee member.

Implementing a GNIP

In order to maintain records of design discussions, proposals must be submitted as pages on the GeoNode wiki. To make a proposal:

  1. Log in to the wiki and create a new page.

  2. Name the new page "GNIP ## - <TITLE>" where:

    • is the number of the GNIP, determined simply by adding 1 to the highest-numbered existing proposal.

    • <TITLE> is the title of the GNIP
  3. Fill in the information in the page template, and click Save when complete.

  4. Link to the new page from the Proposals Under Discussion page.

Clone this wiki locally