Proposal on enhancing governance process

[erget]

Title: Enhancing governance process
Moderator: @dblodgett-usgs
Moderator Status Review [last updated: YY/MM/DD]: Brief comment on current status, update periodically
Requirement Summary: The community has discussed at numerous occasions the possibility of improving the CF Governance Process. This discussion is aimed at producing an update that will benefit the community.
Technical Proposal Summary: The proposal also contains minor changes to GitHub metafiles that would aid contributors.
Benefits: The beneficiaries of this proposal are those interested in contributing to the Conventions and users of the Conventions who need changes implemented or need to understand how these are implemented.
Status Quo: The proposed text is contained in #173 and is based on a draft that was circulated to the CF Governance Panel and the community at large before the 2019 annual meeting. It has been refined subsequently based on inputs from the community at the meeting and in telephone conferences that took place thereafter.
Detailed Proposal: The proposal is described fully in the summary below. The PR itself is structured as a set of "larger questions" in bold. If these have been answered, they are checked off and an answer is provided summarising the stance the proposed text takes on the relevant question. This is followed by a link to the commit within the PR that implements that logic. Therefore the text as a whole can be read in its current state by looking at the PR's "files changed" view or by looking at the individual commits. As the CF Conventions have never had a Constitution as such, but only a section of a white paper on the Conventions describing the "constitution" (lower case) of the various committees, the proposed document is new. Although it is based heavily off the original document, it has a different intent and the author @erget is not of the opinion that it makes sense to attempt to implement these changes as a revision of that document; this document serves a purpose that no previous one had and will also have a different level of visibility.

Summary

This is to open discussion on enhancing the governance process surrounding the CF Conventions. It is based on this original proposal and supersedes that discussion. It is related to #150, #151, #194 and maybe others.

The proposal is being discussed in detail at the netCDF-CF Workshop taking place at ESIP 2019. I hope to use the time where so many members of the community are together in order to prioritize the work, collect feedback and put together a team with the mandate to prepare a full proposal to revise the governance process and propose a straightforward implementation in GitHub.

The corresponding pull request is not mature enough for adoption; it is simply there to make the discussion easier to trace at this time.

People who have expressed interest:
@castelao @davidhassell @JonathanGregory @ethanrd @dblodgett-usgs @martinjuckes @DocOtak @kevin-obrien @marqh @zklaus

People who have expressed support in their comments below:
@DocOtak @ngalbraith

Their contributions have led to improvements in the proposal; nonetheless the changes proposed in this issue's corresponding PR do not necessarily reflect their opinion.

This top comment will be used for presenting a summary so we don't have to dig through the history to understand stuff.

Open points identified for refinement at workshop

Governance (finalised at e94a72c)

CF Committee, Standard Name Committee, Governance Panel are all considered "bodies" in this context.

• Do we impose limits on how long members of a committee serve in a "term"? If so, how long should that be? Not explicitly, but their terms expire at the annual meeting. 1ef2457
• Membership in Governance Panel and CF Committee is via invitation from the Governance Panel. Seems to work okay, should we keep this? Yes. 1ef2457
• Should we "elect" chairs of the various bodies at regular intervals? Or should they be appointed until they step down? Elect them at annual meeting. No stance on how the election is carried out. 1ef2457
• Should we "elect" secretaries? No, this is a lot of work so the positions should be funded if possible and be a part of the person's work. e612409
• Current practice is to combine the CF Committee and the Standard Name Committee. Should we reflect this in the document? Don't think so at this time.
• Should we cap the number of people in a given body? If so, how many should that be? No, but we have an implicit mechanism now that makes the groups shrink automatically. Simultaneously we can make them grow whenever the Governance Panel sees fit. 133cc87
• Should we "add support" for project groups with limited scope and duration? Yes, 1ef2457
• Should we maintain a record of contributions in each body's doc tree? Yes, place is undefined as yet. 5727342
• Should we mandate the annual meeting? Yes, acc912d.
• What release frequency should we use? Annually, more frequently if really needed. 3e692f2, b8c7b59.
• What is the role of moderators? 3e692f2, bbc52e4.
• How to we keep accessible to people who don't feel comfortable with git, GitHub and asciidoc? By offering help, 469a971.

Implementation in GitHub / procedural stuff

Updated after telco on 2019-09-02 with @erget @DocOtak and after telco on 2019-09-10 with @zklaus @dblodgett-usgs @erget

• Do we use semver? Initially had written yes. 1d7c55f. But we shouldn't get hung up on it. Now we say we're "inspired by semver" in b1f04b1.
• Checklist before merges? Yes. Edit history.adoc, update authors, etc. in PR template. 1d7c55f
• Should moderators be an issue's assignee? Yes, agreed here.
• How do we ensure that issues are dealt with in a timely fashion? Attach the release frequency to the meeting so that changes actually come in. Note explicitly that pre-annual meeting 3 week feature freeze is a feature freeze. Tag stuff for milestones, that's motivating, and it summarises upcoming changes. 54a311a
• Who sets tags and when? Secretary, 6 weeks after annual meeting? 1d7c55f
• When do we delete branches? Whenever we want as long as they're not protected. Normally after deleting. 1d7c55f

To be tackled separately:

• Who owns docs from the website? Unknown at this time, but we'll need to mirror this out to the website analog to CF Conventions.
• Align descriptive language with GH roles? Probably in a separate issue but it would make it easier for newcomers. E.g. "moderator" could be "contributor", "author" or some such.
• Move Conformance doc to cf-conventions repo and include in merge checklist? Yes.

[DocOtak]

Here is a link to the Semantic Versioning 2.0.0 specification: https://semver.org/spec/v2.0.0.html

I support the adoption of this as policy for versioning the CF document. Perhaps there should be a section in the pull request/issue template to indicate which version part would need to be incremented.

[martinjuckes]

Hi @erget , I can see that some decisions appear to have been taken and items ticked off above, but I can't see where the discussion is happening or how the decisions are reached. Are these all points which were decided at the annual meeting?

[erget]

HI @martinjuckes no, those were open issues that were discussed at the meeting and that need to be addressed clearly in the proposal. I have collected as close to a concensus as I could while I was there, but we weren't able to reach a conclusion on every one of them. I am closing them piece by piece as I take a concrete stance on them in the proposal itself, but of course the proposal in its final form will still need to be discussed by the community and deliberated by the Governance Panel. My attempt currently is to create a proposal which makes it easier for people to do this in a concrete fashion.

[erget]

This also needs to be coordinated with #194 .

[erget]

@DocOtak I think this is about as far as I can take the proposal for the moment. You'd mentioned that you might have some time to work on e.g. CONTRIBUTING.md to align the language with GitHub-standard lingo. Do you want to tackle that before you go into Catch Me If You Can mode?

[erget]

Dear colleagues, and most particularly those who have expressed interest in changes to the CF governance processes (@castelao @davidhassell @JonathanGregory @ethanrd @dblodgett-usgs @martinjuckes @DocOtak @kevin-obrien @marqh @zklaus),

I've finalised the draft to update the governance process of CF. The major questions that the update tries to address are summarised in the top comment of this issue. Each question is in bold, followed by the conclusion that I have written into the proposal and a link to the specific commit where I have done that. This will make it easier to pick apart the text that I'm proposing, I hope. The full set of changes can be viewed in the pull request.

At this point there are still a few open questions concerning how to continue our work in GitHub, and I have left those in the summary, but if we agree on this set of changes I would leave them open here and address them in more focused, separate issues.

A telephone conference is planned for next Tuesday, at 2019-09-10T15:00Z to discuss GitHub related issues with the GitHub enthusiasts. If you're interested in joining please ping me and I'll send you the attendance details.

In the meantime I would be very interested to hear your input on this proposal and hope that we can move forward constructively and swiftly. My approach in the text has been to be opinionated but I am not married to these concepts so if you can improve these ideas, please do.

Best regards,
Daniel

[DocOtak]

PR #195 looks ok to me, especially in the context of how people are used to doing things (legacy way?).

Re the issues vs pr closing, this is super useful: https://help.github.com/en/articles/closing-issues-using-keywords

It would require updates to the templates so people know to add them to their PR. Something like:

[ ] closes #172

When the PR is merged, github will close the referenced issue automatically and even put a little message of "closed in #somepr" see the bottom of pydata/xarray#3056 for an example.