Committer on which repo(s)? I’m not a committer on stan-dev/stan (or at least I don’t think I am).
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.
Although I could commit on PyStan, there is no reason why I would but also no reason why I should be allowed to.
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.
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.
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
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.
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.
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.
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.
That would have the odd effect of bumping out people like Andrew—metrics are hard.
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.
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.
Andrew has made commits to the wiki.
They are commits peripheral to his contribution…
@bgoodri brings up an important point.
Stan consists of multiple projects from the math lib up to ShinyStan.
The bigger question is do we want to manage them all together like one big project or manage them diffusely?
Personally, I’m much more concerned about governance for the math lib and for the Stan language and for the algorithms than for the interfaces or packages that don’t even depend on the rest of the Stan infrastructure, like ShinyStan or BayesPlot.
That’s a good point, I wouldn’t even begin to assume to have much say about rstan/shinystan, although I’m happy to throw my opinion about Rcpp usage out there and help implement stuff with it.
Excellent that we are getting traction with 20 or so comments, but only 2-3 votes and some abstains, we are not ready to decide I think. I’ll try and summarize commentary:
Amended by @sakrejda original proposal: 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.
stan-dev organization != committers on stan-dev repos @ariddell.
Governance matters most for math lib, algos and Stan language @Bob_Carpenter. Focus on the core of Stan.
There is a “don’t mess with decision making” meme if you are not a part of the team in algo, rstan, pystan and so on. My suggestions that the electorate will be well behaved are not convincing.
Add anything that I misunderstood or plain missed please.
My goal here is consensus–I ran a small software company and I rarely operated outside of consensus by my own estimation. It at least was my goal.
It looks like most of the concerns are about the members of the electorate but interestingly no suggestions that we not have an electorate.
I also sense that folks expect there to be a lot of voting. Remember that voting is a bad outcome. This worries me.
It is pretty clear that folks want to clean up the electorate. I would like some suggestions about what you have in mind.
I agree with the spirit of the proposal, but I also think voting rights based on having committed in the past doesn’t work.
(I don’t have a great proposal that would work or else I’d put it up.)
I’m just going to comment to different things in the thread below here.
GitHub allows us to have repo-level permissions.
We’re already at a point where we value non-git-commiters. “Maintainer” doesn’t seem right and neither does “developer” because @andrewgelman and @avehtari aren’t either in the software sense. I think it may be useful to have a dedicated discussion around this point. At least having the rough spirit of what we want to do written down would be useful.
+1. @bgoodri brings up a great point here and Fogel also mentions it as “partial” vs. “full” voters. I’m with @Bob_Carpenter in wanting to be much more inclusive, but I’m happy with that being for “partial” voters and having the “full” voters be a little more controlled.
I really hope you have 0 monkeys and if you do, I really hope they’re not in circuses.
@Daniel_Simpson, just wanted to say that this isn’t true of the whole Stan team. I agree with the stability, usability, etc., but I don’t believe that Stan should discourage experimenting with algorithms. I’ve given a handful of talks describing encouraging experimentation and describing what access you have in C++. So… if you’re getting the vibe that the team discourages experimentation, maybe we could address that in a different way. Not everything will make it to the Stan repo, but we shouldn’t be discouraging people from doing whatever they want to try.
Pragmatically, it makes sense to manage them diffusely. I think the project is diverse enough where different parts of it may want to have different ways of managing it.
I’m concerned with governance with the other projects, but I think there are less concerns where there’s usually a smaller group working on it. (Or, the questions of governance aren’t visible to those not directly working on it.)
Honestly, for the most part, our group of devs have been awesome to work with! Most of the time, the path is obvious and whatever we choose for governance will work. Some of the time, I’m sure a lot of the devs will not get involved even if they have an opinion when they care less about an issue. Bob’s alluded to it, I do it all the time, I’m sure others do too. I think we are able to recognize that the project moves forward by having do-ers and that a lot of little decisions can be undone if they end up poorly.
We really need to have the governance for the worst case scenarios where there’s deadlock. I don’t think I’ve seen discussions that seem like deadlock outside of the core libraries. Ideally, we’re able to do something positive with minimal stress (good technical discussion should be encouraged). That’s what we’re lacking now.