GNIP-54: GeoNode Project Steering Committee (PSC)

[afabiani]

Welcome to the GeoNode organizational system, as with any open source project we start with people.

Purpose

The goal to have more consistent and constant PSC (users nominated and voted into PSC) than current construct (rotating membership based on last 12 months of code contributions).

Summary

This document describes the role and responsibilities of the Project Steering Committee, as well as the process under which it operates. Much of the definition and inspiration for the GeoNode PSC is taken from the GeoServer Technical Steering Committee, MapServer Technical Steering Committee and the Plone foundation.

The committee is made up of individuals based on merit irrespective of organization ties.

Structure

The PSC is made up of individuals who are intended to represent the various communities which have a stake in GeoNode. An odd number is chosen to facilitate the voting process and help prevent ties. However, even with an odd number, the voting system may still allow for a tie in some cases. For this reason the PSC has an appointed Chair, whose sole responsibility is to break ties among the PSC.

Turnover is allowed and expected to accommodate people only able to become active on the project in intervals. A PSC member may step down at any time.

Current PSC

Accordingly to the current rules the current PSC is composed by the following people

• Alessio Fabiani (@afabiani)
• Cezary Statkiewicz (@cezio)
• Goran Mekić (@mekanix)
• Francesco Bartoli (@francbartoli)
• Paolo Corti (@capooti)
• Simone Dalmasso (@simod)
• Ricardo Garcia Silva (@ricardogsilva)

PSC Membership

New PSC members

A new PSC member can be nominated at any time. Voting for a new PSC is done by the community. There is no hard limit to the number of PSC members, but we want a relatively active PSC. PSC nominations are generally given in recognition to very significant contributions to the project. Membership is open to non-technical people, for example if someone is to make huge advances to the documentation or marketing of GeoNode, for example.

Since we demand a fairly active PSC we expect turnover may be high compared to other projects, so initially we will aim to keep it around 5 PSC members. But given sufficient reason we will expand that.

Nominated PSC members must receive a majority of +1 vote’s from the PSC, and no -1’s.

PSC Chair is nominated following the same procedures as PSC members.

In order to start voting, the candidate must send his application to the GeoNode Users mailing lists. Given that, the community can start voting. One of the PSC members must keep track of voting on a adequate platform.

Stepping Down

If we do not hear from you for six months or more, we can assume you lost. A discussion and voting process will start to remove you from the PSC.

Other than on a time based fashion, one person could be signaled to be removed from the PSC due to irresponsible behavior. Again, any decision will be taken after a discussion involving the entire community.

Every motion must pass through the PSC evaluation in any case.

Bootstrapping

First a volunteer is chosen by the current group of “active” contributors (user, developer and documentation communities). Anyone can volunteer to cover this role.

The volunteer is then removed from the nominee list.

Everyone on the email lists must send his candidature to be part of the PSC in a period of 1 week at most. the volunteer collects those on a document.

After this period, the volunteer communicates the final list of candidates.

Once the list is accepted by those nominated, the volunteer will privately gather the votes posting the results.

The 5 nominees receiving the most 5 votes will be selected as the PSC.

Dissolution of PSC

If there are no suitable replacements, the PSC can decide to go down in number. If the number of active PSC members drops below 5, however, then we may wish to ask the OSGeo Board for assistance. For more information check out the OSGeo Governance FAQ.

Process

The primary role of the PSC is to make decisions relating to project management. The following decision making process is used. It is based on the “Proposal-Vote” system.

• Issues that require a decision are based on GeoNode Improvement Proposals (GNIPs). For more on making a proposal see GeoNode Improvement Proposals.
• Proposals may be made by any interested party (PSC, Non-PSC, committer,user,etc…)
• Proposals should be addressed within one week of being submitted, votes take place at the subsequent GITTER meeting.
• The voting process must be tracked in a google doc containing meeting minutes where you are making quick small decisions, but any larger decisions are better recorded on a proper platform.
• Current automatic PSC votes on this GNIP.
• Current automatic PSC chooses The Chair by voting.
• The Chair calls for a wider vote with the whole community to choose the actual PSC.
• That PSC decides to update this document or not from there.
• Each community member may vote one of the following in support of the proposal:
  • +1 : For
  • -1 : Against
  • +0: Mildly for, but mostly indifferent
  • -0: Mildly against, but mostly indifferent
• A -1 vote must be accompanied with a detailed reason of being against.
• A vote is successful if there is a majority of positive votes.
• A vote is unanimous, if there are either:
  1. No -1 votes against it, or
  2. No +1 votes for it.
• In the event of an successful non unanimous vote, the following steps are taken:
  • Each member who votes -1 may supply an alternative with which the original author can use to rework the proposal in order to satisfy that PSC member.
  • If at least one -1 voting PSC member supplies some alternative criteria, the original author must rework the proposal and resubmit, and the voting process starts again from scratch.
  • If no -1 voters are able to supply alternative criteria, the proposal is accepted.
  • In the event of an unsuccessful vote, the author may rework and submit. A proposal may not be resubmitted after being rejected three times.

Leanness

We would try to follow the "principle of self-organisation" like in QGIS.

That is, if someone shows interest in a particular area of the project, give them mandate to run with it and let the PSC function as a facilitator - keeping the path clear for technical teams to develop organically, supplying them with resources (funding, git access, mandate etc.).

When not to use the GNIP

A GNIP is only needed for:

• an action that has a major effect on others in the GeoNode community.
• If an action will break backwards compatibility, or change core code, a GNIP is recommended.

A GNIP is NOT needed for:

• an improvement that can go in a community module; or
• a bug fix that doesn’t rework anything substantially

For minor decisions where feedback might be desired, the course of action to take is to consult the development list or raise it in an irc meeting. The GeoNode Project recognizes that it is run those who are actually doing the work, and thus we want to avoid high overhead for ‘getting things done’.

Note: Snap Decisions
For all decisions that are not official GNIP proposals, those ‘present’ (those in the Skype meeting or who bother to respond to an email within 4 days) are given the power to vote and decide an issue. The same voting procedures are used, but any vote that meets a -1 from any party present (even a new user), should go to a GNIP.

Status of the GNIPs

A GNIP can be proposed via the GitHub issue mechanism, by tagging it as GNIP.

It would be good to use a standard template for the GNIPs description, however a GNIP should contain at least:

1. Who is proposing the GNIP
2. Reason to change things (a description of the current status)
3. High-level summary of the proposal
4. If possible, few snapshots of the technical details (when needed)
5. Potential issues, further development and future improvements (if any)
6. The list of PSC members along with their votes (updated while the voting happens)

The status of the GNIPs should be updated and reported here

Responsibilities

Responsibilities of PSC members fall into the following categories:

• Operations
• Planning

Operations

Day to day project management. Duties include:

Mailing List Participation

PSC members are expected to be active on both user and developer email lists, subject to open-source mailing list etiquette of course.

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.

Planning

Long term project management. Duties include:

Guiding Major Development Efforts

PSC members 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 has the right to veto any proposed development efforts.

A major development effort which is intended to become part of the core of GeoNode can be proposed by any interested party, PSC, or non PSC. However, the effort must be approved by the PSC before it can begin.

Project Policies

The PSC is responsible for defining project policies and practiced. Examples include:

• Development Practices

  • Code Reviews
  • Intellectual Property
  • Documentation Requirements
  • Commit Access
  • Testing Requirements
  • Branch Culture

• Release Procedures

  • Frequency
  • Version numbering
  • Stable vs R&D

[timlinux]

Hi

So I have a few comments based on my experiences with QGIS:

PSC Size:

We have had the PSC grow and shrink to different sizes. My feeling is that 5 is an optimal size for a PSC because:

• making group decisions gets tedious with large groups. I don't mean the actual voting process but the process of raising a proposal.
• a large PSC will struggle to all be there at regular meetings - it will be harder to find a time when everyone is available with a large group.

Decisions:

IMHO email and IRC chats with +1 / 0 / -1 are incredibly hard to keep track of. It's hard to go back and see when a decision was made and closed. Much better to use a tool like loomio to have a record of your decisions. There is still a place for +1 / 0 / -1 voting e.g. in a google doc containing meeting minutes where you are making quick small decisions, but any larger decisions are better recorded on a proper platform.

Formation:

Having the PSC vote for its own members is a bit self-selecting. At the least, it might be good to ask for nominations and votes for PSC members from within the user, developer and documentation community.

Leanness

Having a PSC is great but try to keep your project admin processes lean. Especially we try to follow the "principle of self-organisation" in QGIS. That is, if someone shows interest in a particular area of the project, give them mandate to run with it and let the PSC function as a facilitator - keeping the path clear for technical teams to develop organically, supplying them with resources (funding, git access, mandate etc.).

Its great to see your plans for growing the governance of GeoNode!

Regards

Tim

[timlinux]

Oh it might also be good to define what constitutes a majority....

[simod]

Thanks a lot @afabiani for this. A comment I have is about the duration of PSC membership in case of inactivity. In particular two months seems too short taking into consideration that non developers PSC members may do more long term work behind the scenes that might not be immediately visible on the mailing lists.

[afabiani]

@timlinux @simod waiting a bit more for comments from other people and than will improve the GNIP with your valuable ones. Thanks for your feedbacks.

[cezio]

+1

I have few questions/clarifications if i understand this GNIP correctly:

• is the goal to have more consistent and constant PSC (users nominated and voted into PSC) than current construct (rotating membership based on last 12 months of code contributions)?
• if so, plain code contribution based PSC membership will no longer in use, but still, to elect The Chair, current PSC must vote, or is it going to be after passing this GNIP?
• what will be the role of the Chair, except for breaking ties?
• I agree 2 months of inactivity may be too low. Should dropping PSC status of inactive member be a subject of a vote?

[francbartoli]

Many thanks @afabiani. I agree with comments from @timlinux and @simod, a reduced PSC size might be balanced with a longer inactive membership.

Anyway +1 in general

[ingenieroariel]

automatic dropping

I like the automatic dropping of PSC status and think it is a key feature. For example, I have been mostly unactive during the past year and nobody had to have an awkward conversation, I was automatically dropped out of the PSC based on the past rules.

In my opinion, it is better to quickly vote to bring the person back than the other way around. Also, notice that the dropping is not based on active contributions but missing the PSC meetings, a person may not have time to contribute a lot to the project for a while, let's say 6 months or even a year and that may be fine, but missing the meetings and breaking quorum is a different thing. One is lack of time, the other one is irresponsible behavior.

size

I agree with the suggestion to make it 5 and contacting osgeo if it drops below that number.

voting

I propose the following order:

0. Current automatic PSC votes on this GNIP.
1. Current automatic PSC chooses The Chair by voting.
2. The Chair calls for a wider vote with the whole community to choose the actual PSC.
3. That PSC decides to update this document or not from there.

Leanness

I agree with Tim here.

[kalxas]

Thanks @afabiani for drafting the new PSC rules.
I agree with @simod on the short term of inactivity, 2 months seems too short.

[kalxas]

Another issue is that the current PSC must approve the new rules, and personally I would prefer 100% voting record from the current PSC if possible for this change.

[ricardogsilva]

Thanks @afabiani for the draft of the new PSC rules.
I mostly agree with the original proposal, but I think @timlinux raises some important points as well:

• Keeping track of votes on a dedicated platform/document instead of the mailing-lists/online meeting logs
• Choosing the new PSC with input from the broader geonode community

Additionally, It seems to me that keeping bi-weekly meetings may be a too busy schedule. Perhaps a weekly or even twice a month schedule might be more appropriate?

As for the bootstrapping, I agree with @ingenieroariel on having the current PSC choose a chair, then have the chair call for a wider vote from the community to form the new PSC.

[giohappy]

Thanks to everyone for contributing to this discussion.
I agree with @timlinux on the points already underlined in the previous comment by @ricardogsilva, and on a 5 members PSC.

I'm also in favor of loomio if a dedicated platform is needed. Anyway a simpler approach (for PSC voting) could be employed using issues in a dedicated github repo (e.g. geonode-psc).

I would start with a meeting schedule twice a month. In case it can be increased later.

I also agree with @ingenieroariel on current PSC voting for agreement on this PSC and the election of the Chair.

[cgiovando]

In addition to the already valid comments on leanness, size, voting schedule, community voting platform, meeting frequency, and automatic dropping, I would like to raise a question about that constitutes merit for PSC nomination.

Can we define what could be the criteria, other than code and documentation contributions? For example, if someone if very active on the mailing list providing support for new users, would that be an acceptable merit? Or if an organization is sponsoring core development, would they be allowed to be nominated instead of the actual developer implementing the code?

The proposed text is a good starting point, but would need some revisions on structure to clearly define what PSC members' roles and responsibilities are (keeping in mind the leanness recommendation), language to ensure consistency (e.g. Skype, Gitter, IRC, etc) and clarity (e.g. ..if a PSC is not active for 2 months they will, ..send his application, we will assume you lost, etc)

Finally, as discussed at the summit, we could include other ways to submit an improvement or a recommendation to the GeoNode project that is not through a GNIP or Github issue. The requirement for when to use a GNIP of an action that has a major effect on others in the GeoNode community is also not very clear to me, and I think could be rephrased.

Thanks @afabiani and everyone for this proposal - really excited to see the GeoNode community discussing a clear project governance model!

[afabiani]

Dear all, I tried to update the proposal accordingly to your comments.

Please review.

[cgiovando]

Hi @afabiani - thanks for incorporating all the feedback and for pushing this!

I have several further comments and proposed edits, but I wasn't sure how to best track those changes here in Github, so I made a separate Google Doc, open for in-line comments: GeoNode PSC ToR Proposal

My main goal was to simplify the structure of the document, clarify some points, and remove some IMHO unnecessary complexity in the policies and procedures.

[afabiani]

GNIP closed and updated accordingly to the Proposal

https://github.com/GeoNode/geonode/wiki/Community-Bylaws#project-steering-committee