Stan Governance


#1

At the weekly Stan meeting the issue of decision making was introduced. I (Breck) have proposed that we adopt from the various suggestions of Karl Fogel’s book Producing Open Source Software.

I extracted portions of Fogel’s book into a summary of decision making systems that have historically worked in this Google Doc. Reading the first two pages or so will help understanding the resulting conversation but go ahead and read the whole thing anyway if you care about this. Please read it all if you are going to comment.

I’ll try and summarize the major points of the conversation. I thought it went well.

I presented the above summary as the template for how the Stan community should structure decision making. There a suggested continuum between benevolent dictatorship and consensus-based democracy. I dismissed the benevolent dictator possibility from the start and I think there was consensus that we had no such person.

The rest of the conversation then focused mostly on who the electorate was for a consensus-based democracy and how voting would work. Positions/issues that persisted through mild cross-examination include:

  1. There was considerable enthusiasm for discussing worst-case-scenerios where issues were decided by voting. Voting according to Fogel is destructive and to be avoided because it creates winners/losers while consensus even with reservations is superior because it is a universal agreement in the end.

  2. Light weight approval was discussed where positions are adopted if 2-3 yes votes or 10% of electorate approves for communal decisions that should not be made unilaterally.

  3. Electorates in open source projects tend to be git committers or maintainers (committers + non committers who are important for project decision making). There was some consensus that it made sense to have an “exec board” for the big decisions and a standard committer electorate for technical decisions.

  4. A good part of the discussion involved the possibility of degenerate electorate members. There was a high expectation that a veto option would be used quite often. The counter argument here was that people who would abuse a veto should not be in the electorate in the first place.

  5. There have been some acrimonious events in the past that inform 4). My personal belief is that better governance would have helped in those situations but I wasn’t a part of it so what do I know.

  6. The current non-system we use benefits those who keep raising issues until they are adopted to just end the discussion.

  7. Much discussion around more/less formal processes to govern inclusion into the electorate. Fogel’s book suggests that the electorate pick members of the electorate in secret and invite new members if there is some enthusiasm (3 votes) and no objections. Other proposals included at least 1 accepted pull request and a 6 month probationary period.

I rely on my colleagues to further elaborate and cover what I missed.

Breck


#2

I think you should go ahead and continue the governance discussion here.

For (1), Stan has so far worked largely through consensus. This has mainly been possible because we’ve all got our zones.

For (3), I think it makes sense to define a group of committers and put the decision making in their hands. (I don’t care what you call this group as long as it’s not something pretentious or silly.)

What did you see an “exec board” doing? Who would be on it? Personally, I’d rather only make these kinds of distinctions (commiter vs. not, super-committer vs. committer) only when absolutely necessary to clarify process. Otherwise, there’s just too much latitude to create hard feelings when you start labeling people.

For (4), I don’t think we have to worry about malice so much as good intentions. I’ve tried very hard not to step in and try to effectively veto things I don’t care for (you probably know what these are, because I tend to go on at length about objections).

As to (5), I don’t think better governance would have led to fewer hard feelings, but it probably would’ve led to a much quicker resolution. The problem is that when we have two stakeholders with different opinions who continue to stake out opposing positions, we need a way to drive a stake through the heart of the issue (sorry, couldn’t stop that runaway metaphor).

For (6), it has indeed been a battle of attrition in some cases.

For (7), we’ve just been adding people to the repo and dev list after an accepted pull request for a feature with unit tests. This is a very slippery slope as some such requests are clearly easier than others. I think erring on the inclusion would be good here, assuming there’s some way to back out these decisions if they go wrong.


#3

Happy to keep the discussion here.

There have been many conversations around this topic around the weekly Stan meeting and in person. While that has been helpful in bootstrapping consensus I and others would like stop the side conversations. In the interests of transparency I’d like to keep the discussion here from now on.

What I see now as common ground is an electorate made up of the git committers. Not all committers are going to be programmers (Andrew, me) and it is assumed that committers will know what their domains are. The committers will be actively maintained by the current set of committers.

At this point all we need is agreement that committers are the decision making body. How the committers function is up to them, presumably with input from the Stan community as a whole. Clearly consensus is everyone’s preferred means of decision making.

Do people agree with the above decision making body? If not please offer alternatives.


#4

I’d like to get the electorate issue resolved. I am meeting Andrew G Tues and will show him the state of discussion since he does not do discourse yet.

Please indicate support with “+1”, abstention with “0” and “-1” is no. If you are opposed please articulate your position. I assume by the end of Thursday’s meeting is a reasonable deadline. The vote is open to anyone with an existing discourse account or git for Stan. Majority seems a reasonable default.

Proposal is: The electorate for Stan decision making is the set of committers in the git repo. Membership in committers is managed by the committers. The ultimate decision making is done by voting. The penultimate decision making process is consensus. Fogel suggests for voting:

"A good choice in most cases is approval voting, whereby each voter can vote for as many of the choices on the ballot as she likes.” The winner is the most-approved candidate.

There are no vetos as currently envisioned but the electorate is free to decide as it sees fit.


#5

Committer on which repo(s)? I’m not a committer on stan-dev/stan (or at least I don’t think I am).


#6

I believe that there are no restrictions regarding which repo’s you can commit to once you are a committer to any of the Stan/StanInterface repos.

B


#7

Although I could commit on PyStan, there is no reason why I would but also no reason why I should be allowed to.


#8

Yep you could commit where you should not but you won’t do so is the general idea. I’m regurgitating lessons from the Fogel book and he says that trusting committers to do the right thing and know their domain works just fine. The overhead of multiple sets of committers based on repos is not worth the hassle.


#9

Why not just simplify this by referring to a specific file called GOVERNANCE or COMMITTERS in the stan-dev/stan repo. There’s no reason I need commit access to stan-dev/stan. Also, the idea that we’d allow the governance of the organization to be defined with reference to a corporation (Github)'s internal database is strange.

But I’m definitely +1 on the spirit of the proposal.


#10

There is a notion of maintainer which was described in Fogel is committer + people who clearly should to be able to vote but don’t commit.

I avoided the maintainer proposal because then we need to discuss who is such a person, inclusion criteria etc… and I am assuming that the current set of committers will have the wisdom to add in maintainers once it is up and functioning if need be which I expect will happen.

So I am going for a minimal governance proposal that should be good enough to bootstrap the process. I get that committers look like an odd set of persons defined by a github DB but presumably if one is trusted to commit to the archive then you have demonstrated good judgement at some point and demonstrated a substantial interest in Stan. Committers are also the governing body for a bunch of successful open source projects–I am trying to apply some best practices as reported by Fogel.


Proposal: remove restriction on developer category within discourse
#11

+1


#12

I think that list includes too many people who were active committers in the past but are no longer active and includes too many people who just commit narrowly and wouldn’t be in a good position to handle broader Stan governance issues.


#13

I don’t have a monkey in this circus (I don’t commit and wouldn’t want to wade into design issues except superficially) so please take this with a whole fistful of salt. (And in particular, my vote on the proposal is 0 because of this.)

I would say that the wider the electorate is the more you should consider a “planning for the worst, hoping for the best” structure.

One issue that I could see potentially getting through a large group of committers using a majority-rule strategy would be doing things like “adding and exposing experimental or unstable methods in Stan”. The current thinking in the Stan team (afaik) is strongly against this for a lot of practical reasons (and even when I don’t agree with the core team on the particular method they’re excluding, I very much agree on the principle), but I can see a large team of committers not holding to the principle. This will effect the stability and usability of the code and be a nightmare for maintenance and support.

People who actually manage these sorts of projects (or are broadly involved) see the problem, but I’m not sure people who commit narrowly would.

Would a different route be for the committers to have an advisory role, with the final decision made by a core team (which should not just be Columbia/NY people!)? Obviously this would need a mechanism to put people on (and off) the core team, term lengths, etc.


#14

Suggestion, this also clarifies which repos do or do not belong on the stan-dev org.:

Proposal is: The electorate for Stan decision making is the set of committers in any repo on the stan-dev organization. Membership in committers is managed by the committers. The ultimate decision making is done by voting. The penultimate decision making process is consensus.


#15

That’s 41 people right now (see https://github.com/orgs/stan-dev/people
). It would be nice to have some expiration of voting rights (maybe if
no code changed within a year).

I suppose I’m a 0. I’d be a +1 if there was some expiration and the set of committers was easy to inspect.

edit: actually, the 41 doesn’t include current committers.


#16

That would have the odd effect of bumping out people like Andrew—metrics are hard.


#17

It looks like members of the stan-dev organization != committers on stan-dev repos. For example, @ahartikainen is a committer on stan-dev/pystan but he is not a member of the stan-dev organization.


#18

Do you think we could clean up org membership and use it as a master list or do you think there’s a better place to keep that.


#19

Andrew has made commits to the wiki.


#20

They are commits peripheral to his contribution…