Stan Electorate for Referendums and Elections

All,

As you may be aware there has been an effort to establish some governance for Stan over the past 18 months. For the past year the Stan Governing Body (SGB) has operated on a provisional basis. The SGB has been doing some good work with a around a $150k year budget, setting up the Technical Working Group (TWG) and there is more to come. Some sort of election/referendum is supposed to happen by October 23, 2019 to establish permanent governance.

Our current electorate are the members of a private discourse category ‘Stan Developers Only’ that historically functioned as a place for core developers to discuss Stan issues without having to worry about the discussion being public. It has morphed a bit into a group of ‘people important to Stan’ and it currently has 38 members. It is my belief that the current electorate is a subset of who should be on the electorate.

This thread is a request for ideas of who should be in an expanded electorate and how do we decide who is in the electorate. While the SGB is considering some ideas I thought it worth while to get input from the broader community.
This is what I propose:

  1. We kick around ideas for expanding/managing the electorate on this thread, I’ll put a few below.
  2. At StanCon Cambridge I have set aside an hour for community discussions on Thursday August 22. That can be an opportunity to refine/expand this discussion.
  3. After StanCon, we have a referendum which expands the electorate with the current electorate based on the SGB digesting all the possibilities and presenting one or more proposals.
  4. We spend the remaining time before the SGB authorization vote (before Oct 23) actually expanding the electorate that then votes in the new SGB.

Electorate ideas:

  • Who are the target voters? The current electorate is largely software developers, some of who are users. I think we need to add pure users that are strong community members, e.g. publish with Stan, teach Stan, evangelize Stan. There may be other categories and I’d like to see who that could be. Do we give people from projects that build upon Stan/Rstan a voice?

  • How do we decide who is in or out of the electorate once we have identified the target? We can have nomination process, second and a vote among current members of the electorate with a threshold. We can have nominations, second and only upon a negative vote do we call an election. We could have a small committee handle it. There are many possibilities.

  • How do we remove members for inactivity in the community or poor behavior?

I’ll leave it at this.

Breck

This is the promised followup from the StanCon community meeting.

Video is at: https://youtu.be/qJlhq4Eb-_U?t=17695, 4:54 in but the link should take you there.

I started with a minimal electorate definition that got elaborated on usefully. I’ll lay out what I think is a reasonable approach, refine with your ideas, potentially have competing proposals and kick it to a referendum after having the SGB look at it.

Overall I’d say that a low bar for entry into the electorate was desired. Qualifications listed were:

  1. Attendance at any StanCon
  2. Participation in a discourse thread
  3. Being an author on a Stan paper or paper that uses Stan
  4. Being a serious Stan user as self determined
  5. Submitting a pull request
  6. Being a Stan funder

All the above are pretty vague and I view them more as suggested criteria for someone to feel comfortable self-nominating.

I then think we should have a committee. The membership and rules of the committee need to be approved by the SGB. For initial rules I’d go with:

  1. Committee has 5 members appointed by the SGB. They should span the user/research/developer communities.
  2. A prospective voter self identifies or is invited by a committee member to join. The prospective voter fills out a simple template that is made available for a week for review/discussion by the committee.
  3. If the two members agree and none object then we add the person. Otherwise a polite rejection email is sent, hopefully with suggestions on what they could do to merit membership in the electorate.
  4. Missing any vote automatically removes the voter. (I expect around one vote a year so this is strong but keeps the voter rolls from getting stale). We can make it easy to re-join.
  5. Removal of a voter for any other reason needs a majority vote from the committee.

Electorate votes will be held using the helios.org voting system.

This is clearly my personal take on how to create an electorate. Please offer suggestions and/or competing proposals. I’d like to move forward in a week with one or more proposals to the current electorate, Tues, Sept 3.

thanks

Breck

2 Likes

I agree there should be a committee.

What I was trying to say in the meeting was that I’d prefer a policy that dictates most of how the committee accepts members. I believe there should be a low bar to joining, but beyond just being a low bar, the membership for automatic inclusion should be spelled out. This is for both the benefit of the electorate and the committee.

The applicants outside of the automatic criteria should be voted on by the committee. I think it makes sense to vote on a schedule: once a quarter or so.

On the whole, I’d like to see a broader electorate involved that what is present now. I think most of our developers are users, but the bulk of our users are not Stan developers.

All,
I am getting ready to call a vote on this. I’ll do so on Monday Sept 23, 2019 with a one week voting window. The electorate will be be current electorate, @Stan_Development_Team, “Stan Developers Only” members as of today. This will be handled via Helios voting.

Make this proposal what you want it to be folks. If the referendum fails to pass then we keep the current electorate. If we have two or more viable competing proposals we will use approval voting.

Proposed method of electorate selection:

"The Stan community electorate will be determined by a committee of at least 3 members appointed by the Stan Governing Body (SGB). One member will be the executive director. The committee is free to define its own operating rules but they are subject to approval by the SGB.

The provisional rules are:

Anyone who has done any of the following can expect automatic approval by the electorate committee:

  1. Attendance at any StanCon.
  2. Being an author on a Stan paper or paper that uses Stan.
  3. Submission of an accepted pull request.
  4. Funding Stan.
  5. ???

The list is not meant to be exhaustive but guidelines. There are many ways to demonstrate importance to the Stan community. Anyone can ask to join the electorate by emailing electorate@mc-stan.org.

Upon successful passing of this resolution and a new electorate of at least 40 people being accepted then the old electorate of “Stan Developers Only” will be replaced with the new electorate.

Failure to vote will result in removal from the voting rolls. Reinstatement will be not withheld without reason but no retroactive voting is allowed after the vote is closed.

The committee can remove/refuse a member for any reason. The member can appeal to the SGB.

Votes will he held using the helios voting system which requires an email address (https://helios.org) and administered by the electorate committee.
"

Can we make that “non-trivial?” I realize that’s a judgement call.

Also I think @betanalpha had amassed a good list of ways to be included in the electorate that included lots of non-software-specific ways to contribute. Can we put those in as well?

2 Likes

I want to echo the sentiment that users should be a part of the electorate. To do that, you need to make it clear to us that our contributions are valued/wanted. I’d add to the list “Developed teaching materials for Stan”. Also, for our friends in industry, we should have something like “Substantial commercial applications of Stan.”

4 Likes

+1 on that, bet we’d get nice ideas and direction

I think the corporate or corporate aligned membership should be discussed separately

My preference is to leave it as is and if there is evidence of abuse then we refine. Believe it or not there are people that will always think their PR is trivial, ‘aw come on, that HMC bug was obvious’ types. Remember, the committee can always intervene.

Welcome and yes we should add user criteria to inclusion in the electorate.
Interpreted your comments and @Stevo15025 as 5,6 and 7 below:

  1. Attendance at any StanCon.
  2. Being an author on a Stan paper or paper that uses Stan.
  3. Submission of an accepted pull request.
  4. Funding Stan.
  5. Developed teaching materials for Stan.
  6. Taught Stan.
  7. Use Stan for work.
  8. ???

imo I think 7 is too vague. Pretty much includes or nulls out all the other ones

Interesting point. This is for the electorate and we already have ‘corporate’ members in the current electorate just to be clear. I don’t think we want to walk that back.

We have not defined any corporate roles in Stan governance which is where this issue gets complex. Separate discussion however and one that we are going to have to have.

Do you have a different version or want to strike it? I’d think a daily or weekly user of Stan should qualify. I’d rather say ‘Monthly user of Stan’ than ‘Regular user of Stan’ to minimize the candidate member having to make a judgement call.

Thanks @eleafeit. This is super important. Getting more Stan users involved in helping to guide the project forward is essential. And if you or anyone else has particular suggestions for how we can do a better job making it clear that contributions are valued and wanted we’d love to get that feedback.

Oh right, you’re saying they’d have to apply and present an application with something on it and the committee would decide? I guess that’s fine, I just didn’t want to auto-invite anyone who submitted something like a single typo fix.

I’d also suggest adding criteria like “Providing Stan support on the Stan discourse” and “Hosting or organizing Stan events including but not limited to meetups, talks, conferences, jamborees, galas, and hootenannies.”

2 Likes

What about users who don’t produce PRs but submit actionable bug reports? I’m with Breck here, I’d rather we were embracing by default, keeping in mind to clarify how and when the committee intervention in case of abuse would work.

2 Likes