I believe that this conversation has become confused because the scope of the initial governance proposal was not properly defined. At the Stan developer meeting a few weeks ago we had a long discussion about governance and ultimately decided to separate out the long term guidance of the project (nominally to be run via some board of benevolent dictators) from the developer logistics. Anyone please correct me if I am wrong.
In particular, the specific governance being discussed here was about the developer logistics alone. This means is has nothing to do with politics (being able to claim that you’re a Stan developer for a CV or grant proposal) or deciding between overarching designs or features. The issue at hand here is simply who is allowed (or rather who do we trust) to review and approve pull requests? Given how GitHub permissions is currently set up this also has the side effect of deciding who can create branches within the Stan repositories.
Let me try clarifying a few things admixed with what I propose as a governance model consistent with already stated opinions.
What do we call the cohort of people who can review and approve pull requests?
Stan developer sounds correct to me, although if we formalize this then it would nominally prevent anyone who isn’t currently reviewing pull requests (Aki and Andy, for example) from calling themselves Stan developers.
-
Option 1: We call the cohort something else, like “maintainers” or “committers”.
-
Option 2: We call the cohort “developers” and have a separate name for collaborators, such as “advisors” or “collaborators”.
The initial cohort would be chosen by fiat, likely people around Columbia. People can then be quickly added (see the proposed procedure below).
Where is this cohort defined and managed?
-
Option 1: A team of the stan-dev organization, such as the current “Maintainers” team.
-
Option 2: The entire stan-dev organization.
Note that the any team must be a subset of the stan-dev organization, but going with Option 1 would give us additional flexibility, for example not giving everyone permissions on all repos (in particular the Jenkins repo which contains sensitive passwords).
How are people added to this cohort?
Anyone not in the cohort can still contribute to Stan, just not exactly in the workflow that we currently have. Outside contributors would have to fork the target repository instead of branching, and then submit a pull request from that fork. Jenkins would not automatically run CI on these requests to avoid overwhelming our system; instead a member of the cohort would have to trigger the CI by hand (likely the person doing the initial review).
But how to contributors become members of the “developer” cohort where they can create branches and get auto CI and review and approve other pull requests? This was nominally the original issue at hand. May I propose the following:
1. Nomination
Anyone who has submitted a pull request (from a fork) may be nominated for inclusion into the “developer” cohort by any member of the cohort.
2. Probationary Approval
Any nominee who receives N number of votes is given probationary approval where they are added to the cohort with all permissions to create branches, trigger CI, review and approve pull requests, but not vote. I imagine that most members of the cohort would abstain via nonresponse, so we should set N relatively low, such as 3 or 5.
3. Full Approval
After the probationary period of P months another vote is taken and if the nominee receives N vote again they become permanent members of the cohort with full voting privileges. I think we want this period long enough for the nominee to engage with the cohort and do a few reviews, maybe P = 6?
This step is here in the rare instance where a nominee clashes significantly with the existing cohort, giving us a way to remove someone who may be acting poorly without having to “vote them off”.
4. Code of Conduct
If we are formalizing governance then I think we should also add a developer/project code of conduct just to acknowledge that we want to maintain a civil and inclusive environment.
5. Membership Expiration
A final consideration is whether membership in this cohort might expire, for example after 2 years without having submitted or reviewed a pull request. This is optional but I think should be considered as after 2 years our code will likely have changed enough that members who have not engaged in a while may no longer be sufficiently familiar with it.
To simplify the proposal we can also drop (5) entirely and worry about it later.
Any suggestions on the exact details here, such as which GitHub grouping to use, the name of the cohort, the number of votes, and the length of the probationary period? Or just general comments?