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.