Proposal for RubyGems Organizational Governance

[martinemde]

As an organization that has long held its governance in trust by the maintainers of the project, I propose that we establish a transparent public governance plan.

It would be beneficial for everyone in the community to understand how we choose and control ownership of the public open source projects that power the ruby community.

Clarity around the ownership and governance of the project ensures that donors, maintainers, and users alike can understand how the ownership and direction of the project is decided, with the goal of providing stability and trust through transparency.

Rendered

[indirect]

I think this is a good start, and using Homebrew's existing and tested policy document is very helpful. Let's see what everyone else who is currently a maintainer of Bundler, RubyGems, or RubyGems.org thinks. @bronzdoc @djberg96 @duckinator @evanphx @hsbt @segiddins @deivid-rodriguez @colby-swandale @simi does this seem good? any suggestions or requested changes?

[duckinator]

What are the "operational minimums"?

[martinemde]

Yes, this is missing. I think 3 is the minimum, below which the policy can't work because you can't get a 2/3rds majority to remove someone with only 2 people.

[duckinator]

That information could probably just be added under Definitions, then capitalize the first letter + bold it like I suggested for definitions in general.

[colindean]

Simplify and reference the quorum definition:

Suggested change

	In cases where owner count falls below operational minimums:
	Should the number of owners fall below quorum requirements,

[duckinator]

When using these phrases elsewhere in the document, it would be useful to capitalize them and bold the initial letters of each word, like they are in this section. That would make it clear when these words are used in a generic way vs a reference to these definitions.

[duckinator]

Maintainers are currently only mentioned in 4.6 Implementation, item 2.

Is there intended to be a way for Maintainers (as opposed to Owners) to directly raise concerns and require the Owners vote on it? Or would they effectively need an Owner to "sponsor" the request by submitting it on behalf of the Maintainer(s) in question?

[martinemde]

The original document had a whole maintainer section and I probably missed some bits trying to simplify. We could add it back in or adapt it somehow.

[MikeMcQuaid]

I agree it'd be useful to declare maintainers, too, and the process to which they are also added/removed.

I'd also suggest that maintainers are, like owners, also considered primarily on "what access rights do they get granted", "what do they need to use their jobs" and "what are they actually using?".

For a Homebrew example, we've had a bunch of maintainers removed over the years with high contribution levels but who don't e.g. review/merge PRs from anyone else. That doesn't need write access to the repository so: they don't get to keep it any more.

[deivid-rodriguez]

I think I'd start with just defining owners for this initial version of the document. Then add a "second level" of ownership through approving amendments to the document if we ever need. I think it's more important to get the fundamentals right that getting all the details in this first version.

[MikeMcQuaid]

@deivid-rodriguez Speaking from personal experience: the "let's start with something and iterate" works well with software but poorly with governance because, as defined by this document, all future iterations require majorities or supermajorities to be ratified which ends up being a lot of overhead for each improvement pass.

[deivid-rodriguez]

Well, I was hoping we introduce the initial version by unanimity among what we consider the current maintainers team. So majorities or supermajorities would actually be less overhead than the initial version 😅.

[duckinator]

Do we have a defined list of who the "current project owners" are considered for the purposes of this document?

[deivid-rodriguez]

Great question, we have like 5 different lists of "project owners" spread across many places 🤣. A good outcome of this, other than a governance model document, would be unifying and consolidating those lists.

I guess a way would be to start with current rubygems organization owner list, and then modify it using the governance model that we approve, and then propagate that to the other places (or change those places to point to the "source of truth").

[duckinator]

I left a few comments/questions. Most of them are formatting and clarification of terms, but one is about if/how Maintainers can require Owners vote on a concern.

"They have to be 'sponsored' by an Owner who submits it on their behalf" is a valid option, especially for the initial implementation, but it might be worth explicitly documenting.

[duckinator]

@martinemde thank you for taking the time to do this! If you want input on phrasing/formatting and similar, please feel free to poke me here or on Slack. I have experience as a copyeditor and would like to think I'm at least okay at it. 🙂

[MikeMcQuaid]

@martinemde et. al: as the Homebrew Project Leader who was involved in creating our equivalent and very involved in updating it: shout if you would like to talk more about it on or off the record 😁.

I'm also game to leave any comments/thoughts on here instead/as well if that's desired.

[martinemde]

shout if you would like to talk more about it on or off the record 😁.

great to have you join the discussion @MikeMcQuaid and thank you for inspiring this. I heard from our mutual friend that you care a lot about this and have thought about it a bunch. I'd be really happy to meet, as I'm sure others on the team also would be.

If you have any specific comments, I'm also happy to have your feedback here.

[MikeMcQuaid]

@martinemde thanks! get someone to email me and I'll send a meeting invite link. reviewing now 👀

[MikeMcQuaid]

Dropped a few thoughts given my experience on Homebrew. I'm someone who tends towards "strong" language so, just to make it explicit: you should ignore literally everything I've said if it doesn't apply to you folks here. Good luck with it and: keep up the great work running a critical part of internet infrastructure 👏🏻

[MikeMcQuaid]

May be worth defining these specifically

[MikeMcQuaid]

I would strongly suggest that this be a MUST or SHOULD, given the god-level of permissions that "owner" grants.

brew contributions --org=rubygems or similar may be useful for you here!

[MikeMcQuaid]

Given "principle of least privilege": I'd suggest that you think about "which people and responsibilities need owner rights" and remove it from people who don't "need" it.

All of "owner", "maintain", "write", etc. access shouldn't be seen as a privilege, recognition of good work, recognition of past work, etc. but instead be based on who is actually using these permissions to do work.

[MikeMcQuaid]

I would suggest that removals based on inactivity not be something that requires a vote as it can be done on documented, measurable requirements.

My experience with this sort of thing is that it's very easy for nostalgia and warm fuzzy feelings about humans you like to override best security practises.

[deivid-rodriguez]

I think sometimes activity or work done is hard to measure objectively. Some people get engaged mostly through comments and discussions, others through commits, reviews, documentation. So maybe additions based on proposals and vote among current owners is better? And similarly, deletions based on agreeing with the person being removed about her inactivity, or casting a vote if no agreement reached may be easier, too?

I do believe that casting a formal vote every time an owner wants to add or remove someone may be too much overhead. So I was thinking maybe having those formal voting processes just once a year, instead of "whenever a maintainer proposes a member for addition/removal". That gives time to think thoroughly about both additions and removals, and not get too ˝excited" about any of them. Of course, keeping proper "emergency processes" as proposed.

[martinemde]

I assume based on vote dynamics that ownership will change rarely but adding and removing maintainers is more common and is the job of one of the owners to do responsibly, not requiring a vote. We can document this or even let this comment serve as a guide for when we propose a maintainer section.

[MikeMcQuaid]

On this, I think it's touched elsewhere, but it's worth separating "leadership in project" and "technical access rights". I think it's very reasonable to have leadership only changing e.g. once a year. I think having someone get voted into a leadership permission, have full owner/admin/etc. access to everything and not use that for 11.5 months is a bit of a security hole.

[MikeMcQuaid]

I agree it'd be useful to declare maintainers, too, and the process to which they are also added/removed.

I'd also suggest that maintainers are, like owners, also considered primarily on "what access rights do they get granted", "what do they need to use their jobs" and "what are they actually using?".

For a Homebrew example, we've had a bunch of maintainers removed over the years with high contribution levels but who don't e.g. review/merge PRs from anyone else. That doesn't need write access to the repository so: they don't get to keep it any more.

[deivid-rodriguez]

What does it mean to be an owner? I guess we define it as being an owner of the github organization?

But then, maybe some owners don't ever need to exercise god-level permissions in the org, so why should they have those privileges? It seems to go against the Principle of Least Privilege.

Maybe we should keep just two people from the owners team in charge of being "github organization owners", and rotate those every year or whatever. In the specific case where org level changes are needed, they can be discussed first with the team, but anyone we trust (i.e., member of the owners team) can actually do the clicking. Or maybe this is too much overhead because these privileges are actually used more than I think?

[deivid-rodriguez]

There are also the permissions to release our gems that have similar issues. Being able to release gems is a way of "controlling the project", but still, maybe not all members of the owners team need permission to release gems.

I think ideally we automate our releases so that they are triggered by merging a PR or whatever, so that this is a non-issue, but in the mean time we could have a rotatory release manager or something.

[martinemde]

There are also the permissions to release our gems that have similar issues. Being able to release gems is a way of "controlling the project", but still, maybe not all members of the owners team need permission to release gems.

I think ideally we automate our releases so that they are triggered by merging a PR or whatever, so that this is a non-issue, but in the mean time we could have a rotatory release manager or something.

This is a very good point. I think this document tries to address how we decide top level control over contributors and maintainers. For example, RubyGems.org infrastructure is the legal responsibility of Ruby Central, and so there will always necessarily be separate access that is controlled according to a relationship with Ruby Central. I think we should clearly define what access that is controlled by this governance document and what is not, or which things might be "controlled" but not necessarily held at any given moment by all the people. (I don't need to push rubygems or bundler packages at this time for my work).

[deivid-rodriguez]

I think we should clearly define what access that is controlled by this governance document and what is not, or which things might be "controlled" but not necessarily held at any given moment by all the people.

Yes, I believe this is the kind of thing that should be clearly documented, and ideally we balance a clear definition of who the current group of people who control the projects is, and how that group can change and evolve, with letting everyone have the minimum privileges that they need to do the work they are doing, like @MikeMcQuaid explained.

[duckinator]

One potential solution for the "principle of least privilege" situation may be to separate the concepts of project stewardship and technical access, and have a small number of roles defined by certain combinations of "level/types of commitment to running the project" and "level of technical access/control of the project".

For example, I am a RubyGems maintainer (in that I have actively contributed to the project for nearly a decade and can navigate the codebase better than most people) and try to participate in discussions that affect the general trajectory of the project, but I have stayed out of managing the GitHub organization and repositories or making releases.

So in the grand scheme of things the technical access I need is pretty much "the ability to merge PRs", but I would like to have input on important decisions (like, say, adopting this document or amending it later on). However, my understanding of the document as it is now, is that I would basically be limited to an advisory role at most unless given more technical access than I need or want right now.

Unfortunately this does increase the complexity of both the organizational structure and the governance document.

[martinemde]

This does seem like a basic challenge of open source and ownership. Someone needs to hold the ownership, and having a few owners helps with bus factor problems. Then there's the question of voting on things and affecting the governance itself.

In this document I tried to address the most pressing concern, which is "how do we decide who controls the access controls".

There's another obvious one which is "who can change what's published to the world?" (gem push/deploy). I view them as similarly sensitive, so holding either is a position of great trust.

My goal here is to show our community, team, and sponsors that rubygems is in good hands, well managed, and not at the whims of any one owner. Instead, we can show that we are well governed in a way that is accountable and fair.

This document puts in place a way to change this document so that we can heal and grow. I don't think it's perfect, but if we can address any glaring flaws or loopholes and then adopt it, it will at least let us adapt and change over time.

There's things that don't feel fair too, like who is a current owner and who is not. I don't know how to remedy that except by adopting this and then voting to add or remove owners as needed. The alternative of changing ownership before adopting this is quintessentially counterproductive.

[deivid-rodriguez]

Yes, that all makes sense and to be clear, I'm totally in favor of not bikeshedding this too much, since this gives us the tools to change whatever is needed later through a more democratic and transparent process than before.

[martinemde]

just a few little changes in response to comments.

I was reviewing the homebrew document again with fresher eyes and I wish I'd hewed more closely to it. It addresses some of our concerns about membership and reducing the number of owners (only having 2 GitHub owners at a time makes sense once you have the structure). I think the PLC concept is most valuable to bring over, along with members generally, instead of focusing so much on owners.

[martinemde]

Suggested change

	* **Primary Repositories**: rubygems/rubygems, rubygems/bundler, and related critical infrastructure repositories
	* **Primary Repositories**: rubygems/rubygems (includes bundler), rubygems/rubygems.org, rubygems/gemstash, rubygems and bundler websites, blog, guides, and all private infrastructure and related repositories.

[martinemde]

I assume based on vote dynamics that ownership will change rarely but adding and removing maintainers is more common and is the job of one of the owners to do responsibly, not requiring a vote. We can document this or even let this comment serve as a guide for when we propose a maintainer section.

[martinemde]

Suggested change

	Ownership removal MAY be initiated for:
	Ownership removal MUST be initiated for:

[MikeMcQuaid]

One potential solution for the "principle of least privilege" situation may be to separate the concepts of project stewardship and technical access, and have a small number of roles defined by certain combinations of "level/types of commitment to running the project" and "level of technical access/control of the project".

I think this is the key point here. You really want to have two groups:

• technical leadership
• organisational leadership

It may be that these groups are both entirely overlapping initially. That's fine! They will likely always have some overlap.

Longer-term, though: you probably want to have separation because they are different skills and need different people/access rights.

In this document I tried to address the most pressing concern, which is "how do we decide who controls the access controls".

There's another obvious one which is "who can change what's published to the world?" (gem push/deploy). I view them as similarly sensitive, so holding either is a position of great trust.

Because we're all open source maintainers here: it feels like the most "power" is to the person with e.g. GitHub/RubyGems owner access.

Compare with established/larger tech companies: the CEO arguably has the most "power" but very rarely has the highest level of access permissions on everything. That's normally instead delegated to IT/Security/etc.

I think that model makes the most sense here. I don't think it must (nor should) be the case that those with the ability to remove maintainers also need to have the ability to click those buttons. Given principle of least privilege (sorry, again): ideally you have fewer people with "I can click button to remove maintainer" rights than "I can vote to remove maintainer" rights.

On GitHub, for example, with a single highly-scoped PAT leak for an organisation owner: a lot of damage can be done. People who are GitHub owners for something like Homebrew or RubyGems can bypass a lot of security controls pretty quietly. It makes sense to lock this down hard (even if that may hurt some feelings).

My goal here is to show our community, team, and sponsors that rubygems is in good hands, well managed, and not at the whims of any one owner. Instead, we can show that we are well governed in a way that is accountable and fair.

I think the PLC concept is most valuable to bring over, along with members generally, instead of focusing so much on owners.

These are excellent aims ❤️ 👏🏻

From further down the line, though: it is worth noting that there are costs to doing all this. There will definitely be disputes, conflict and maybe even people leaving the project long-term over governance documents/changes. It may be that some changes provide more of a benefit to non-RubyGems onlookers than the actual folks running the project.

Similarly, the "Project Leader" role we have in Homebrew looks like it puts a lot of power in one person (me) but it's elected periodically. If we didn't have this, there would have been (and would continue to be) many tough decisions as a project that get effectively deadlocked from progress.

Governance structures, particularly those that require e.g. supermajorities for anything, are inherently conservative rather than progressive; you are (by design) making it hard to change these structures in future. That's no inherently a bad thing but: be aware of this trade-off and make sure you're happy with the document you end up with because it will feel more set-in-stone than it might actually be.

Great conversation all round here and good luck everyone. Again: feel free to ignore anything not useful to you here! 😍

[mghaught]

I've taken a first pass on this and this is a great start. I'll dig into specifics as I have more time. I'm committed to find the right governance model that works for us all. More to come.

[rubyFeedback]

I am not much involved these days, but with the recent situation - see https://old.reddit.com/r/ruby/comments/1nkzszc/ruby_centrals_attack_on_rubygems/ - I feel that a lot needs to be cleared up.

My personal preference would be for rubygems to be completely apolitical from A to Z, just like in the "good old days"; either way with the mass-retirements, I feel that this may also require a completely new clean state, with new folks. And perhaps people overseeing transitions that have an excellent reputation, such as dbrain/dblack etc...

[colindean]

Please accept my suggestions with a grain of salt. It's completely OK to accept all, some, or none.

I have contributed significantly to Homebrew's governance document and have written and helped write the governing documents of several organizations, including non-profits and some inside companies. Additionally, I have adjudicated disputes on governance as an impartial third party. However, I am not a lawyer, but a few have patted me on the back and told me I did a good job, then taught me how to make my docs even better.

I review this from the perspective of being a contributor to the document that inspired this one. I want to see strong derivatives in action. Still, I recognize that the complexity of the organization and its needs may be quite different. I am also an interested (downstream) party, as I maintain software that benefits from RubyGems' continued healthy, functional operation. The RubyGems team has built a great thing for which I am ever grateful.

I echo @MikeMcQuaid's recommendation to separate governance ownership/membership from access rights.

[colindean]

The notice period has a minimum bound but not a maximum. Consider limiting the notice period, e.g., to four weeks. That way, a vote is at least three weeks but not more than four weeks away once a nomination is announced.

Suggested change

	1. All nominations MUST be announced to owners with at least 3 weeks notice before voting
	2. During the notice period:
	- Owners MAY ask questions of the candidate
	- Owners MAY voice support or concerns
	- The candidate SHOULD participate in discussions
	- Additional supporting statements MAY be provided
	### 3.3 Voting Process
	1. After the notice period, a formal vote SHALL be held
	1. All nominations MUST be announced to all owners through a regular communications channel at least 3 weeks before voting.
	2. During this notice period:
	- Owners MAY ask questions of the candidate
	- Owners MAY voice support or concerns
	- The candidate SHOULD participate in discussions
	- Additional supporting statements MAY be provided
	### 3.3 Voting Process
	1. A formal vote SHALL be held not more than four weeks after the nominations are announced.

One thing I dislike is the "be announced" passive voice. In organizations with a secretary, that'd be the secretary's job, IME. In the absence of a secretary, somebody has to do it, or the process is in jeopardy of being contested.

[colindean]

While I'm here, a minor nit:

Suggested change

	3. Each owner gets one vote per candidate: Yes, No, or Abstain
	3. Each owner casts one vote per candidate: Accept, Reject, or Abstain

I like explicit action verbs in vote options.

[colindean]

Could be explicit here:

Suggested change

	1. Accepted candidates SHALL be granted owner permissions within 1 week of vote completion
	1. Accepted candidates SHALL be granted owner permissions on primary repositories within 1 week of vote completion

[colindean]

Quarterly access reviews seem standard, so consider an automatic revocation of owner access on that cadence with a "shall issue" restoration of access on demand within the owner's term. This process is more straightforward when there's a separation between decision-making rights and access rights, if that's appropriate for this organization.

You could also use something like "Unexcused inactivity" where it's basically radio silence and no affirmative when polling an inactive owner for their continued interest.

[colindean]

Following suit with my nit above:

Suggested change

	3. Each owner (including the subject) gets one vote: Yes (remove), No (retain), or Abstain
	3. Each owner, including the subject, MAY cast one vote: Remove, Retain, or Abstain

[colindean]

Need to disambiguate owner/maintainer here. There's conversation elsewhere. Could just remove it.

Suggested change

2. The removed owner MAY retain maintainer access unless separately removed as maintainer

[colindean]

Simplify and reference the quorum definition:

Suggested change

	In cases where owner count falls below operational minimums:
	Should the number of owners fall below quorum requirements,

[colindean]

This may not have the intended effect. The section would be triggered when there are two owners. Ordinary resolution means unilateral addition is possible to get a third, then, six months later, if no more owners have been added, the three would vote on retaining the third. The third would likely Accept themselves as would their nominator. Ordinary resolution means that vote is effectively meaningless. Ordinary and special resolution are equivalent when N=3 or N=4.

If instead the nominal minimum owners is 5, and this section refers to that, then this action has more effect.

[colindean]

Suggested change

	3. Extended absence during voting MAY be grounds for inactivity review
	3. Failure to vote SHOULD considered inactivity

This is a very strong SHOULD, a smidgen away from SHALL. The allowable case I can think of is that someone shouldn't lose their voice because they waited until the last minute to vote and then some emergency keeps them from voting before the deadline.

[colindean]

This process is nearly identical to the addition process. Appeals feel nice but they're so close to just getting added that providing evidence for an appeal is operationally identical to the other justification material.

The only difference is that this section doesn't provide explicit difference for a notice period.

You might be able to simply drop this section or reduce it to something like this:

Suggested change

	### 8.3 Appeals
	Removed owners MAY appeal their removal by:
	1. Requesting reconsideration with new evidence
	2. Addressing the concerns that led to removal
	3. Appeals require **ordinary resolution** to succeed
	### 8.3 Appeals
	1. Removed owners MAY appeal their removal by nominating themselves for addition upon the discovery of new evidence or having demonstrably addressed the concerns that led to removal.
	2. Owners MAY choose by ordinary resolution to shorten the notice period for voting for appealing removed owners.

This way, self-nomination is permitted for removed owners only and the owners can shorten the notice period for expedited action. The week-long voting period remains unchanged.

[martinemde]

@colindean thank you for you time and effort marking this up. I would immediately accept many of these if I still had commit on this repo. Great stuff and I can tell that you have indeed done this before.

Thank you