Stan Governance

General
62

You super don’t count in the way I was thinking! I was actually thinking of the way that yeh NumFOCUS board purposely has people who are “around but not in” the main Stan development group. (Now obviously from what I wrote you’d have to guess that, but it’s the internet, and I’m sloppy). So I’d specifically suggest a small group (2-3) people who are very unlikely to be caught up in the specifics of the complaint, but are willing to become familiar with the governance of Stan. Ideally, the people would not all be demographically the same (e.g. 2 straight white men would be bad. 2 straight white women would be bad. Diversity within practical limits would be good). Basically, we need people who will be seen as “honest brokers” from all side who are easy to approach.

63

We’re on the same page here as this was exactly what I was trying to describe. :-p

When I said that I “count” I was referring to Bob’s previous post where he interpreted “diversity” as the NSF definition.

64

That makes sense about not having a policy being a policy itself.

The only thing I’m worried about is setting up a policy where complaints are filed and nothing happens or worse, turns into covering our asses like university versions of these things.

So are you suggesting that there’s not an official standing committee of some kind to centralize reporting? What’s the suggestion then for what people do who feel there’s been a breach of the code of conduct?

65

Dictatorships hardly prevent trend chasing. In fact, they can enable it in a lot of ways, because fewer people have to agree on changing course.

Having said that, I also like the idea of putting someone in charge of all the repos industry style rather than trying to run a pure democracy. As Michael points out, that’s the current arrangement at the lowest levels with:

One reason @betanalpha and I were suggesting splitting the stan-dev/stan repo is because the langauge and algorithms are distinct parts of it. Also, currently nobody’s in charge of the interfaces/services piece of the puzzle, which may be why it’s dropping on the ground between all of us. @syclik is de facto in charge having written almost all of the current code. Also, I don’t think we put anyone in charge of cmdstan, but please correct me if I’m wrong. We should have this actually published somewhere on GitHub.

The splitting of stan-dev/stan between me and @betanalpha is one of the reasons we think the repos should be split; @seantalts has said he’d rather consolidate instead.

Of course, I presume @betanalpha’s and my opinions in this are predicated on our remaining in charge of the algorithms and language respectively. So take our recommendations with a grain of salt here!

I think we just want to give whoever you call the convener veto power. If that gets out of hand, we could rethink. Again, that’s been the de facto governance strategy so far.

66

I completely agree. It’s just semantics—I’d consider those essentially code quality issues, but I can see how they’re borderline algorithm vs. implementation things. I’m also not quite sure what you mean by “fail hard”. You mean self diagnose?

Don’t worry—I’m pretty thick skinned. I just wanted to clarify what’s been going on for those catching up or listening in. I completely agree about learning from past mistakes. As we’re developing this software process, we (largely @betanalpha) have been developing the kind of diagnostics we need to enforce some of these new policies.

The more the dev team spreads out, the more this really is for us and for people thinking of joining us. It’s much easier to keep everyone on their best behavior if that best behavior is both spelled out explicitly and enforced by example by the developers.

67

I think the interface code should also be split. (Logical split is fine without splitting the actual repositories). I can own it for now; I think I’m the one that has the best handle on how {RStan, PyStan, CmdStan} actually interacts with the Stan repository and I’m trying to make that simpler. I don’t know if anyone else is actively working on it.

For the time being, I can be in charge of the interface layer. If not, I think @sakrejda is a good candidate. (I know @bgoodri, @betanalpha, @ariddell have knowledge of parts of it and could pick it up if necessary.)

68

I meant that they must have diagnostics that say when they fail. I think we all agree we don’t want algorithms that fail silently.

+1 email is basically made for misunderstandings, I’m just trying to be clear.

Agreed.

69

Again, we’re not in a better situation at the moment and vulnerable to the same issues. I’m just advocating that an end-to-end policy on judgement and consequences should not obstruct the adoption of a code of conduct that establishes what behaviors we consider unacceptable.

Ideally we would have something similar to what @anon75146577 and I were discussing – two or three diverse people, including people perhaps not even affiliated with Stan to whom people can report breaches. That should be straightforward to establish along with the adoption of a code of conduct.

Even more ideally we’d have a transparent procedure for how we deal with those reports, but let’s go one step at a time.

70

I agree—guess that also wasn’t clear from my email.

1 Like
71

Below are governance positions that I have mined from the conversation. I am considering proposals for overall governance, not proposals regarding repos, interfaces, code of conduct handling or numFocus. Those are good conversations but I want to address the top level decision making.

a) We reject the need for a top level decision making entirely <old_edit>entity</old_edit>.

b) Benevolent Dictator–a wise person who rarely makes decisions because they are good at consensus building and they are trusted by the community.

c) {Beneficial Dictator of Area}–a BDoA is a technically strong person that runs a fiefdom that was determined in the Great Partition before my time. Degree of benevolence varies but they are expected to benefit their area. Because I am interested in an ultimate decision making body I’ll take the set of BDoA as the decision making body. Most of this thread is generated by BDoA members. Throw in Andrew and Aki perhaps.

d) Set of committers in github across all projects/interfaces + important folks. This was my initial proposal.

e) Decide that we don’t want to decide. This is a variation of a).

f) Decide that we need to talk more about this.

Please add anything I missed.
I’d like to shut this thread down pretty soon. The other completely worthy conversations can live on in their own threads.

1 Like
72

The typical structure is to have some kind of board making this kind of decision. So there’s

g) form a board to make decisions at the project level.

h) morph NumFOCUS’s board into the board that makes these high level decisions for the project.

I’d lean toward (h) of all these options. I don’t see the point of having two boards. As I mentioned above, the board we have now isn’t permanent and can be added to.

I think there needs to be further discussion about what the scope of decision making would be beyond financial decisions pertaining to funds in NumFOCUS (same discussion if we decide to go with parallel boards in NumFOCUS and for the project). We can call this group the “Stan Trustees” or whatever makes sense for non-profit, open-source projects, and have it coincidentally have it also act as the NumFOCUS leadership body; or maybe a subset of the trustees could make up the NumFOCUS leadership body.

So you can see I’m thinking of this as a body for making big decisions on an infrequent basis, not something to manage the day-to-day.

Then, separate discussion, I think we need to figure out how the software itself is managed as opposed to all the activity around it. And how things like leads for teaching and consulting are handled or even if we want to do any of that centrally.

73

Works for me.

74

Can we break this up into separate discussions/threads? I was trying to
catch up on this conversation but it seems like there are several different
conversations happening simultaneously in this thread. They all seem worth
having but it’s hard to follow as is.

Should we start one thread for discussing high-level governance for the
project and a separate one to hammer out the details of the plan for
handling the code base (PR reviews, etc)?

1 Like
75

Fine by me. Does this work? Threads for:

  • High Level Stan Governance
  • Technical Stan Governance

I’d just do it but I am not sure of the smoothest way to split a thread.

Breck

76

I’d suggest starting two new threads, trying to be an honest broker when starting them (or at least trying to limit scope of discussion), and having links back to this thread (fine grained is probably better, but it’d be ok if it were just to this thread). I don’t think there’s a mechanism for splitting threads.

77

If you haven’t seen this already, Node.js was forked recently over code of conduct issues:

At the very least, it seems like something we can learn from.

78

This Stan Governance thing should maybe be a category not a thread. The discussion on how the pro-CoC node fork wants to do governance is interesting: https://github.com/ayojs/ayo/issues/2

I like the idea of a board for legal issues and to implement the shared CoC, and technical governance broken down by technical concerns (math lib, algorithms, language, services, then 1 per interface).

1 Like
79

What did you think we should be taking away from this?

I agree with orless’s comment on the Ycombinator thread:

To be honest, for those not (already) involved in this whole debate, it is very difficult to make an informed opinion here.

I couldn’t follow it through the acronyms and redactions. Is there a third-party summary somewhere?

80

For technical governance, that’s already what we’re doing (though services/interfaces in Stan has fallen between our outfielders).

So far, I haven’t seen any progress on codes of conduct or enforcement policy. I’m very hesitant to get involved in this discussion given my previous experiences and given what went down with Node.js.

81

I don’t know what your previous experiences are, but the Node.js thing looks like an absolute disaster (whatever happened). There does seem to be some aspect of it that involves a code of conduct that was poorly designed and then poorly implemented, so when someone actually tried to use it it exploded.

It also seems complicated by a really convoluted, not particularly open governance structure.

I don’t think there will be any progress until someone or a small group volunteers to make a proposal (similar to what you did with the language changes) for people to actually look at, think about, argue with, and improve.