Request for input: a new mechanism for recognizing our most enthusiastic users

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:

  1. 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
  2. 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
  3. 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)
    • Responsibilities: meeting attendance, informed decision making, fundraising, stewardship of NumFOCUS-held funds
    • 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:

  1. Stan electorate-wide: Contributor & Developer

    • Scope: Direction/vision of project (anything non-technical); non-binding roadmaps; SGB elections
  2. 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
  3. 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
  4. 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.

What do you think?

20 Likes

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.

Just IMHO.

2 Likes

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.

Thanks you are pushing for this.

1 Like

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?

3 Likes

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.

2 Likes

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.

Breck

1 Like

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).

6 Likes

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.

3 Likes

@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!

2 Likes

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.

3 Likes