-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Community Bylaws
The GeoNode community is divided into two groups - users and committers. There are no requirements or responsibilities to be a GeoNode user. To be a committer, you must be voted in by the existing committers (2 +1's and no -1's; a committer must initiate the vote.) Non-committers are encouraged to engage in discussions on the mailing lists, code review, and issue reports to qualify them to be voted in as committers. Committers (or PRIMARY AUTHORS) can be found in the AUTHORS file
Committers must:
- make useful contributions to the project in the form of commits at least once in a 6-month period, else they fall back to "committer emeritus" status. A committer emeritus has no special involvement in the project, but may request committer privileges from the current body of committers.
- review code contributions, which may come from other committers or from users. Users must submit code externally to the main GeoNode repository (ie as a patch or a github pull request); committers can do this as well if they see review as particularly important (for example, a patch might affect a particularly crucial component of GeoNode, or a committer might be working in a part of the code that he is relatively unfamiliar with.) A review should result in either (a) instructions on how to bring the code to a more acceptable condition or (b) merging the changes in and notifying the submitter that this has been done.
- Committers also have the option to "self-review" and commit changes directly. It is at the discretion of individual committers when this is appropriate, but it should be rare - we encourage committers to only use this option when they deem a change extremely safe.
If a committer thinks a proposed change to the software is particularly destabilizing or far-reaching, that committer can upgrade the ticket for that change to a GeoNode Improvement Proposal (GNIP). GNIP tickets are an opportunity for committers and users alike to provide feedback about the design of a proposed feature or architectural change. The proposal should be iteratively edited in response to community feedback.
To upgrade an issue to a GNIP, an active committer should give the ticket the 'GNIP' label in the issue tracker, and announce the issue on the developer mailing list.
If a ticket has a GNIP label, its patch can't be committed unless it also has the 'Approved' label. To be approved, it must pass community vote (see below).
When the GNIP is announced, other committers should review and provide feedback in the issue comments. Feedback should take the form of:
- +1 (with optional comment)
- -1, with mandatory rationale and suggestion for a better approach. The suggestion may be omitted if the objection doesn't have a straightforward solution - we don't want to withhold feedback just because problems with a proposal are hard to solve.
After receiving feedback, the proposal's author should discuss the feedback on the list if necessary and adjust the proposal in response.
A proposal can be Approved when there are 3 +1 responses (including the author's implicit approval) and no -1 responses from committers; and no feedback is offered in 3 days. If a proposal fails to receive multiple +1 responses within 5 days of the request for feedback it is rejected and the issue should be closed (but the author is free to draft similar proposals in the future.) Any committer may reverse or withdraw votes on a proposal until the proposal is closed.
If a user would like to submit a GNIP, they are welcome to write it as a ticket but should find an active committer willing to promote it to GNIP status.
In the event that a revision to these bylaws becomes necessary, authority for that decision lies with the currently presiding Project Steering Committee (PSC). The PSC at any time is made up of the top 7 committers over the past 365 days, by number of commits.
Welcome to the GeoNode project governance and organizational system - as with any open source project it starts with people. The scope of this document is to define role and responsibilities of the Project Steering Committee (PSC), the process under which it operates and how its members are selected.
For many aspects, the GeoNode project mostly follows the principle of self-organization. The role of the PSC is to set the overall direction and manage the project in a lean and inclusive way. That is, if someone shows initiative in a particular area of the project, they are encouraged to run with it and the PSC will only function as a facilitator, keeping the path clear for technical teams to develop organically, supplying them with resources (funding, code access, mandate etc.).
The PSC is made up of individuals, based on their merit, and who are intended to represent the various organizations and communities which have a stake in the GeoNode project.
- Current vs. Proposed Selection Process
- Current: rotating membership based on last 12 months of code contributions
- Proposed: users nominated and voted into PSC
- Criteria for Selection
- The committee is made up of individuals based on merit irrespective of organizational ties. Although, no more than one individual associated with the same organization can be on the same PSC at any time.
- PSC nominations are generally expected in recognition to significant contributions to the project and showing active community participation.
- Membership is open to both technical and non-technical members. Merit for nomination can range e.g. from code core contributions, to improving the documentation, raising funds for the project, participating in the mailing list, conducting training, or even just promoting GeoNode to new users.
- Selection Process
- A new PSC member can be nominated or self-nominate at any time.
- The candidate must send her/his application to the GeoNode Users mailing lists, providing a brief statement, after which voting can begin.
- Nominated members must receive a majority of votes from current PSC members to be successfully elected.
- Bootstrapping
- Voting for a brand new PSC is done by the community. An open voting platform (e.g. Loomio) should be selected to cast and record community votes.
- A volunteer is chosen to manage the voting platform and announces the results. The volunteer is excluded from the potential list of nominees.
- Nominations for the brand new PSC can be submitted for a period of one week at most, after which voting can begin. The five nominees receiving the most votes will be selected as the PSC.
- An odd number of members is chosen to facilitate the voting process and help preventing ties. In order to keep decision making process lean and efficient, the proposed number of initial PSC members is five (5), but can be increased to welcome members who demonstrate particular spirit of initiative and leadership.
- Even with an odd number of members, the voting system may still allow for a tie in some cases. For this reason the PSC has an appointed Chair, whose responsibility is to break ties among members. PSC Chair is nominated following the same procedure, with an absolute majority of PSC members’ +1 votes (approval).
- Turnover is allowed and expected to also accommodate people only able to become active on the project in time intervals. A PSC member may also step down at any time.
- If a member doesn’t attend three or more consecutive meetings without informing the rest of the PSC, a discussion and voting process will start to remove her/him.
- Other than for lack of participation, a member could be signaled to be removed from the PSC due to irresponsible behavior. Any decision in this case will be taken after a discussion involving the community, unless of sensitive/personal matters.
- If there are no suitable replacements or new candidates, the PSC can decide to decrease their members count, however if the number of active members drops below 5, a brand new PSC election (bootstrapping) is required.
The main responsibilities of the PSC are:
- make high level decisions relating to the GeoNode project management,
- set the overall direction of the project and releases,
- support activities that promote GeoNode and participate on the mailing lists,
- facilitate processes for community participation and inclusion.
PSC members should hold regular meetings on a public online platform. Anyone from the community can also attend meetings and participate in the discussion, but only PSC members can vote on decisions.
PSC meetings can be held through a voice communication medium to facilitate interactive discussion and optimize time. Frequency can be decided by the PSC, but expected to be at least monthly.
It is a requirement that all PSC members maintain good public visibility with respect to activity and management of the project. This cannot happen without a good frequency of email on the mailing lists.
The PSC is required to make decisions on proposed major changes to the code and project organization policies. The following decision making process is used. It is based on the “Proposal-Vote” system:
- Proposals that require a decision by the PSC are submitted through the GeoNode Improvement Proposals (GNIPs) process. GNIPS can be made by anyone in the GeoNode community.
- Proposals should be addressed by the PSC and the community within one week of being submitted. Voting takes place at the subsequent PSC meeting.
- The voting process must be tracked in a public online decision making platform (e.g. Loomio). For small and quick decisions, voting can also be done within regular PSC meeting, and voting recorded with a simple +1/-1 system.
- Rejection votes (-1) must be accompanied with a detailed reason of being against, offering productive feedback, and allowing for eventual resubmission after revision.
- A GNIP is approved if there is a majority of positive votes by PSC members.
- Community members should also provide feedback on GNIPs using +1/-1s and commenting functions in Github.
For all small decisions and minor changes to the code that are not GNIPs (changes to community modules or bug fixes that don’t rework anything substantially), community members are expected to discuss and agree through mailing lists or directly in Github, without PSC intervention.
PSC members, on the other hand, are expected to help guide the major development efforts of the project. This may include deciding which development efforts should receive priority when different efforts are in conflict.
The PSC is also responsible for defining project policies, including Development Practices (e.g. code review workflow, documentation requirements, branch setup, commit access, etc.) and Release Procedures (e.g. frequency, version numbering, stable vs. development, etc).