The Stan Governing Board wants your input! We have put together a proposal for a new type of “official” Stan involvement— tentatively called a Contributor— which will believe will recognize and encourage the impact and involvement of our awesome users. We welcome your comments, including suggestions for the name of this new type of role.
Ways to get (officially) involved with Stan:
Developer
These people directly change the code base of the Stan language or one of its interfaces.
Special privileges: vote on Developer-Only topics; access to Developers section of Discourse; ability to review pull requests
Responsibilities: abide by Code of Conduct; vote on topics which you feel sufficiently informed about; abstain from voting on topics about which you do not feel informed or impacted
How to get involved: there has been an informal process in place, but SGB is currently drafting a official proposal for recognizing new Developers
Contributor (new!)
Contributors are enthusiastic users or community members who want to be more involved with Stan.
Special privileges: voting on any motion not designated Developers-only; participation in working groups around certain topic areas (e.g., “Stan in marketing” or “Stan meetup coordinators”)
Responsibilities: abide by Code of Conduct
How to get involved: be nominated (self-nominations are encouraged!), respond with a post on Discourse with a description of what you hope to bring to Stan, and have your nomination seconded by two existing Contributors or Developers
Governing board member
The Stan Governing Board sets the procedures and governance structure for the overall Stan project and manages financial aspects of the organization.
Special privileges: none as individuals, unless designated by role within SGB (e.g., a NumFOCUS point of contact to approve expenses)
How to get involved: nominate yourself during the SGB election cycle each fall; 5 members will be elected to serve. SGB terms are typically one year.
This corresponds to 4 categories of votes that could occur on Stan issues, each with its own group of eligible voters:
Stan electorate-wide: Contributor & Developer
Scope: Direction/vision of project (anything non-technical); non-binding roadmaps; SGB elections
Developer-wide: Developer
Scope: Technical decisions impacting multiple domain areas; binding roadmaps; any subject area-specific topics where Developers in the subject area are unable to achieve consensus
Subject area-wide (e.g., “math library”): Developers in a module area self-identifying as having the necessary domain expertise to make informed decisions
Scope: Technical decisions that primarily impact a single domain area, with limited effect on other areas
SGB-specific: Current elected SGB member
Scope: Governance and voting structures; financial decisions for NumFOCUS funds; general execution of direction/vision
Note: References to the Code of Conduct currently mean the NumFOCUS Code of Conduct, since that applies to all NumFOCUS projects in the absence of a project-specific Code of Conduct.
IMHO, it would make sense to have well defined functional roles with a known impact, and then give those roles voting rights in related matters as an eventual recognition of service. i.e. “contributor” isn’t well defined.
For example, “Community Manager”, “Moderator”, “Tutor” can all be given concrete responsibilities and KPIs, and then after some amount of quality service can be rewarded with voting rights. The award of rights could be automatic. I.e. once you achieve X you get Y, or awarded by a board with a more qualitative criteria. I think that depends amongst other things on how you want voting rights to be inflated/diluted and who, at day’s end, really has skin in the game regarding the consequences of decisions.
Sorry, I forgot to react when this was fresh, so hope feedback is still relevant.
I generally like the idea. The only thing I would consider is that both Contributor and Developer role IMHO need some expiration mechanism. In an older proposal for elections, the idea was that if you missed a vote you were eligible for (explicit withdrawal counts as voting), you will drop out of the category, but (and that’s important) would be automatically admitted back if you ask for it. I kind of liked it, but I guess there are many other lightweight mechanisms to avoid having a lot of people in the electorate who drifted away from the community are no longer active.
Absolutely still relevant, @martinmodrak — thanks for sharing!
We had considered having “alumni” status but weren’t sure how to draw the line in a way that made it clear people’s contributions were still welcome. For example, @imadmali had gone largely inactive a few years back and is now (obviously) a valued member of our community. We don’t want people to feel like they’ve missed their window to contribute. What do you see as being the risk of keeping people on the voting list if they’re inactive? Understanding that risk might help us think about how to distinguish between active and inactive while maintaining a welcoming, inclusive approach.
Similarly, I have been mulling over the feedback from @emiruz, trying to reconcile our desire to acknowledge past contributions vs. explicitly inviting greater future involvement. In an open source project, how much “skin in the game” do people really need? My instinct is that the Stan project currently has the bar set too high, as evidenced by the fact that we largely lean on the same core people for too many tasks. As an example, the SGB recently discussed how it would be nice to have a Stan newsletter-for-the-digital-age, but (1) those are a lot of work and the people we might ask to do it already have a lot of Stan-related projects to juggle and (2) writing a great newsletter requires dedication and enthusiasm for writing a great newsletter, and we haven’t come across that yet. (Side note: contact @SGB if you’d love to take on this task.) If they’re not voting on technical decisions or creating binding language roadmaps, then in what other areas would we be worried about the Developer perspective/voting power becoming too diluted?
Good way of putting it. I have to admit that when I wrote my previous post, I just vaguely disliked the idea. Thinking about it more thoroughly, I believe the biggest risk is a certain loss of transparancy. If a vote I am invested in is scheduled, how do I know who will actually vote (inactive members would probably rarely actually vote)? Who should I try to perseuade? If ten devs informally support the idea on forums, is it a big or a small part of the electorate? Such situation also gives a bit more power to people who have this information.
Second is a bit more far-fetched: Inevitably at some point there will be more inactive devs/contributors than currently active ones (by any criterion on activity). In such a situation, anyone who can rally the inactive part of the electorate will yield disproportionate power. Once a contentious issue is (believed to have been) decided primarily by inactive devs/contributors, there might be a crisis of legitimacy. I can however also imagine that the experience of inactive devs/contributors could be very valuable asset in a contentious decision, so it really goes both ways.
I don’t think any of this is necessarily important and the state of the community would have to worsen quite notably for those to be relevant, but I think we should try to make the governance process robust to less-than-ideal situations. I however don’t feel strongly about any of those risks in particular and it certainly would be OK with me if others chose to just accept them as known risks.
Totally agree. I would like to keep stuff simple and mostly human-based. If there are complicated formal requirements, it would IMHO at best select for people who like/are good at fulfilling formal requirements and at worst to people actively gaming the requirements.
Public self nomination is a big ask for lots of shy folk since it comes with the possibility of rejection.
I’d also caution against not having the option of SGB, or a SGB appointed committee, review of new voting members and having the ability to remove existing members. It can be very easy to take over an organization without some sort of oversight on membership. Stan has assets that may be worth taking control of.
Did some developments happen in the meantime? I am trying to think how to combine this with community leaders/moderators, i.e. how tightly should I integrate recognition of active users with technical privileges on the forums. I kind of like community leaders being automatically “Contributors” in the sense of the proposal, but the mechanism of attaining (and potentially loosing) the Leader status might need to be a bit different than for contributors here…
In my opinion as a not developer but involved in the community person, I would be a little frustrated to be given voting privileges to
but to see the developers trusted to make the judgement call to
Why wouldn’t I be trusted to know when I should sit out a vote?
When I’ve been involved in these conversations before the aims have always been stated around ensuring that non-code contributions are valued and rewarded by the community, and that people who contribute a significant amount of time and energy should have the ability to shape the community. This imho does neither - by diluting the responsibilities of the contributor you implicitly imply that their contributions are not as valuable and important as those of a developer, and you also limit their ability to shape the community (after all, who decides what a developer gets to vote on vs what the whole community gets to vote on?).
On a broader note, what is the purpose of such a distinction? Is it that being a developer signifies some sort of statistical/coding superiority? That doesn’t check out in practice - to become a developer you only need to make a meaningful commit to the codebase - that doesn’t necessarily require statistical knowledge at all, and an individual could be capable of making a code contribution but choose to provide other skills and resources to the community instead. In addition, why is code valued but not documentation/translation (which also gets committed to the repos).
Yes. All of this. Also worth noting that Andrew and I definitely aren’t devs because of our awesome C++ skills. There are models for broader contributions already but they were very specifically carved out.
@lauren Thanks for the additional feedback! The SGB is going to be working on this topic again over the next few weeks so it would be great to get more feedback like this from other people too.
No, certainly not! I don’t think it signifies anything other than that the person has substantial experience (not just a few commits) working on at least some important part of the codebase (with a few exceptions, as Dan mentioned). And I totally agree with you that someone who doesn’t write any of the codebase can make more impactful contributions to the community than someone who does write some of it.
I definitely think it makes sense to question whether there needs to be a distinction between developers and other important community members. Maybe instead of “developer” and “contributor”, we should just have one label that covers everyone who is making important contributions to the project? What counts as “important contributions” would need to be worked out, but suppose we came up with a definition. Then, instead of the page on the website listing the developers, what if there was just a page listing everyone making important contributions and each person could put a sentence next to their name describing what they work on in relation to Stan? For one person that could be “Math library development” and for someone else it could be “Developing educational materials”.
I’m just brainstorming out loud here to try to get more discussion going (i.e., I’m not making an official proposal on behalf of all SGB members). What do people think about the idea of grouping all contributors to the project together instead of making a hard distinction between “developers” and the rest? Whether you like that idea or not it would be great to hear from you!
Thank you to everyone for the feedback! This thread has prompted a number of wonderful conversations at @SGB meetings as we think about laying a groundwork for user-inclusive Stan governance.
We will be sharing a revised proposal as soon as it is ready.
I’m OK with Jonah’s proposal given the SGB to fall back on if things get out of hand. But let me expand a bit. And just to be clear, this has nothing to do with @lauren personally.
The general reason for constraining votes for technical issues is that people aren’t so good at knowing what they don’t know. Let me turn this around in a thought experiment, @lauren. Suppose we were forming a voting body on statistics methodology. Who would you want to get to decide whether they knew enough to vote on an issue like how we estimate standard deviation or formulate priors for GLMs?
My main concern is that it’s easy to sit on the outside of software development and believe a feature X, Y, or Z are a good idea, without understanding the deeper ramifications of those choices, specifically involving development, documentation, and maintenance costs.
My original proposal was to have developers not just be a single category, but to be attached to “modules”. Then devs would be able to vote on anything related to the modules for which they are developers. This is where they have skin in the game to the point where decisions will affect their future ability to do development. It’s not just theoretical.
Knowing what’s important is a second issue. General discussions in venues like the Stan meetings have led to a great deal of so-called “bike shedding”, which can be a huge time sink.
All developers are not created equal. There’s a pretty big culture gap between those with industry experience building public-facing software and those who learned to code in academia. This has led to a lot of contention with developers which is ongoing. In fact, I’d isolate it as probably our biggest source of conflict after whether we want to “move fast and break things” or not. I don’t, but other developers do (though they’d probably tell you they’re already moving slowly).
Let me close by reinforcing my first point—I’m OK opening up the votes to a wider audience and falling back on the SGB to enforce discipline.
I agree with this! I was mostly pushing on this idea that a developer knows when to step out of a vote but someone who is a community member who also contributes a lot to the project doesn’t.
If the issue is who votes in what, it seems more sensible to me to have clearer rules on who is eligible to vote rather than splitting your contributors into the ones who code and the ones that contribute something that is traditionally considered “soft” labour.
For whatever it may be worth I agree with @lauren here. Stan development is a sophisticated blend of statistical computation, probabilistic programming, automatic differentiation, pretty advanced C++, and interface design; in general developers are in no better position to figure out which of these topics they know well enough to take part in important decisions than most advanced users, in that it is equally challenging.
Like any contract, whatever we do is going to need to be based on trust because it’s impossible to legislate for every contingent bad actor possibility.
Devs know more about the code, but as @betanalpha points out, that’s not enough.
It’s not even clear there’s a “right answer” to a lot of issues we need to resolve. Devs with differing goals can very reasonably disagree. For example, @betanalpha and I disagree on how CmdStan argumenrts should be structured. @betanalpha likes the structure he developed for the current CmdStan, but I prefer a more conventioanl flat structure like found in the git command.
There’s not an objectively “correct” answer or we’d solve this disagreement by proving theorems. My guess is that someone will find some time to build a new command-line interface with more conventional argument structure that we could plug into CmdStanPy and CmdStanR instead of CmdStan.
Maybe a way through this would be to flatten the distinctions and have a separate focus on things like voting procedures.
For instance, I am not actually convinced that someone who implements a new C++ feature is of more value to the project (whatever that means) than someone who writes a great vignette that educates users about the feature. Or that they are of more value than an SGB or committee member who keeps the lights on.
So why don’t we flatten out the distinctions and make everyone who contributes to Stan a developer.
What if instead of the three tiers, we have things like
Developer (C++)
Developer ®
Developer (Documentation)
Developer (Leadership)
Developer (OCaml)
Developer (Python)
Developer (Community) [for people running things like “Stan in X”]
etc etc etc
Many of our more fancy folk would be multi-hyphenate. Some of the categories (mainly leadership) might end a time qualifier. But the idea is that we are all involved in rowing this boat, so why are we making distinctions when we could instead just say “we are all of value, here are the specifics”.
This removes the admin requirements (eg who can review PRs) because in some big important sense that’s an implementation detail rather than a design one. I’m not sure that there are people who have the skill and Stan experience to review PRs who don’t have the permissions. At least not for long.
It would be possible to have a barrier for recognition (eg a substantial contribution to documentation, a substantial feature or pull request), but it would allow us to legitimately recognize the people who make Stan special. It also gives multiple low-stakes routes into becoming a developer, as it’s perhaps an easier experience to go from contributing docs to contributing Python to contributing C++.
Does this help with the voting? Nope.
Maybe having the electorate on a particular issue as a combination of automatically added people (eg “they’ve contributed to stanc3”) and always have it open to people who give reasons that they should vote on this specific issue?