Initial ruby/rubygems governance doc
#9187
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,96 @@ | ||
| # Governance of `ruby/rubygems` | ||
|
|
||
| The objective of this document is to provide a minimum version of Governance and plan for a more comprehensive iteration later. Governance is **“a well-defined set of norms, written down.”** We intentionally minimize legalistic language and expect this document to be treated as a tool for understanding and collaboration, and not as a tool for “point of order” procedural technicalities. | ||
|
|
||
| The Governance defined in this document can (and should) change as norms change and evolve. | ||
|
|
||
| ## Matz is BDFL | ||
|
|
||
| First, we recognize Yukihiro Matsumoto (Matz) as the [BDFL](https://en.wikipedia.org/wiki/Benevolent_dictator_for_life) of Ruby. The `ruby/rubygems` repository now falls under the domain of Ruby core contributors. If Matz shows a strong preference or wishes to overrule decisions made by members of the `ruby/rubygems` repository, we will respect his decisions. We will keep him informed of our work and discussions by having them in the open. At this time we do not require his explicit approval or buy-in to move forward with any specific changes (a lack of engagement will not be treated as a blocker). We will weigh changes and features according to how we believe Matz would prefer, and will explicitly seek his input using our best judgment. For example, if we desire a larger breaking change, Matz would likely want to provide input. | ||
|
|
||
| Decisions for Ruby core contributors are made via discussions on the bug tracker [https://bugs.ruby-lang.org/](https://bugs.ruby-lang.org/). Posting there can be used as a mechanism for communicating with Matz, or attending a Ruby developer meeting, or asking someone to represent the group at one. Matz currently delegates his authority to Ruby core committers listed at [https://github.com/ruby/ruby/blob/master/doc/maintainers.md#librubygemsrb-librubygems](https://github.com/ruby/ruby/blob/master/doc/maintainers.md#librubygemsrb-librubygems). | ||
|
|
||
| While Matz can overrule decisions made by the governance stated in the rest of this document on individual decisions, contributors should not use him as a mechanism to subvert other governance mechanisms. I.e. Please do not harass Matz because everyone else in the proper channels outlined below said “no.” | ||
|
|
||
| ## Ruby Core Committer Access | ||
|
|
||
| All Ruby core contributors are encouraged to participate through regular Issues and Pull Request interactions on the `ruby/rubygems` repository. If a Ruby core contributor wants commit access on the `ruby/rubygems` repository, they are encouraged to use the governance process defined below to gain `committer` team status, which will allow them commit access. | ||
|
|
||
| Ruby core contributors may contact an existing `core` member to request `committer` team membership. They may also open up an issue on `ruby/rubygems` stating that they desire commit access, [https://github.com/ruby/rubygems/issues](https://github.com/ruby/rubygems/issues). When possible, a public request is preferred (for visibility and accountability). `ruby/rubygems` `core` members are encouraged to move quickly and prioritize these requests from Ruby core contributors. | ||
|
|
||
| Some Ruby core contributors are already administrators of the repository (described in the `access` team section) and therefore have the technical capability to commit to the repository already. We kindly ask that they follow the same process and gain explicit `committer` team permission before exercising their existing commit rights. The `core` team membership is encouraged to prioritize access to existing Ruby core committers. | ||
|
|
||
| Upstream Ruby has a copy of Rubygems and might require patches occasionally. It’s acceptable to fix these upstream and then backport to the `ruby/rubygems` repo, [for example](https://github.com/ruby/rubygems/pull/8960). | ||
|
|
||
| As mentioned in the prior section, Matz can overrule this document. That also means that Matz can direct existing Ruby core members who are on the `access` team to give another developer the ability to commit to the `ruby/rubygems` repository. We ask that any `access` team members follow the suggestions documented in the `access` section below. Specifically by notifying other `access` team members and documenting the change in an appropriate location. We encourage Matz to use this power sparingly, but ultimately place no demands on him and will respect his discretion in using it as he sees fit. | ||
|
|
||
| Core (`core`) members of `ruby/rubygems` are not automatically added to Ruby core contributors. That process is described here [https://github.com/ruby/ruby/wiki/Committer-How-To#how-to-register-you-as-a-committer](https://github.com/ruby/ruby/wiki/Committer-How-To#how-to-register-you-as-a-committer). | ||
|
|
||
| ---- | ||
|
|
||
| ## The `ruby/rubygems` Repository Provisional Governance | ||
|
|
||
| When not explicitly directed by Matz, the rest of this document defines the governance expectations of [github.com/ruby/rubygems](http://github.com/ruby/rubygems) participants. | ||
|
|
||
| ## Provisional status | ||
|
|
||
| This document is provisional. It is meant to be replaced so that governance stays relevant and applicable. Those involved in the `ruby/rubygems` repository governance are encouraged to start drafting a provisional replacement governance model immediately and iterate on it as soon as possible. | ||
|
|
||
| ## Teams and Membership | ||
|
|
||
| Each team, except where explicitly stated as being under the guidance of another team, will be self-managed: a current member proposes a new member, a majority of current members approve the selection, and this outcome (of who is currently on the team) is documented publicly. Any member may voluntarily resign at any time. For non-voluntary removal, the same consensus process is followed. | ||
|
|
||
| Team membership is expected to be an active status. Those not actively exercising their status must be placed into a “paused” or “alumni” state (depending on the duration and discretion of the team). The access team should be notified of any changes in team status. Individual teams will determine a process for any “paused” or “alumni” members wishing to regain access. | ||
|
|
||
| Team memberships are not mutually exclusive. | ||
|
|
||
| ### Teams | ||
|
|
||
| * Access - controls access mechanism and governance | ||
| * Release - controls software releases | ||
| * Security - controls security matters | ||
| * Core - controls software roadmap | ||
| * Committer - controls contributions to the software | ||
| * Triage - controls triaging of software issues | ||
|
|
||
| ## Access Team (`access`) | ||
|
|
||
| The access team controls the mechanisms by which other teams have capabilities. i.e. they can give someone commit permissions on GitHub or owner/deploy permissions on RubyGems.org (e.g. https://rubygems.org/gems/bundler or https://rubygems.org/gems/rubygems-update). | ||
|
|
||
| The access team members do not need to be members of another team (i.e. someone can have “access” abilities but not be on “core”). By default, those who have the capability to change permissions should NOT assume they can perform the actions themselves. I.e. Just because you can give someone a commit bit, does not mean you have permission to commit freely to that project (unless otherwise stated via appropriate team membership). | ||
|
|
||
| Not all access team members will have access to all administrative controls. All Ruby core committers who have administrative privileges over the entire `ruby` namespace are implicitly in this team. | ||
|
|
||
| Access changes made by the team must be communicated to all members so it is clear who made the change, what changed, and why. Security permitting, a public audit log of access changes should be kept. | ||
|
|
||
| Select members of Ruby Central are currently part of the `access` team. Going forward it is up to Ruby Central to responsibly determine which members should be part of the `access` team. Ruby Central does not dictate membership of any of the other teams outlined below. | ||
|
There was a problem hiding this comment. Why is Ruby Central mentioned at all in this document? I believe this is a valid question both on principle and in practice. Being that the project is now under the ruby org, why does Ruby Central still hold special status?
Contributor
Author
There was a problem hiding this comment. From the description:
I said more here #9187 (comment). I feel it's important though to represent that RubyGems.org has some stake in this project: Beyond just pulling from the service bundler and rubygems CLIS are the de facto client interfaces for pushing artifacts to RubyGems.org. Also that Matz and Ruby Core have vested interests in RubyGems (as they're vendored with Ruby). For some context of where I'm coming from: I've been working on other governance and started the idea of firming up the Puma support docs a while ago. In the support docs, we say we explicitly support some things (operating systems, Ruby versions, etc.) because we depend on them. But there are other things that depend on US that we care about, such as stability with Sinatra or Rails. On the one hand, it is impossible to list all your dependents. On the other hand, it reflects the state of reality even if it's not exhaustively enumerated. |
||
|
|
||
| Ruby Central should not make permanent changes without explicit request from the team that holds the power to make that change. For example, they should not remove the ability to close issues from someone unless they’ve been directed by the `core` team (this is a power explicitly granted in the `core` team section). Ruby Central member access should be yielded if the individual who holds it no longer has official ties with Ruby Central. | ||
|
|
||
| ## Release Team (`release`) | ||
|
|
||
| Similar to the access team, those who retain the ability to release Ruby, will also be able to release `ruby/rubygems` Other members may gain access to release Bundler or `ruby/rubygems` as suggested by the consensus of `core`. Members of the release team are not required to be members of another team. They will coordinate with Security and Core to release. | ||
|
|
||
| ## Security Team (`security`) | ||
|
|
||
| The Security team members will have the ability to recommend the removal of administrative access from any other team member. The access team is expected to respect this request unless they have strong reason to counter. The security team is able to temporarily pause or revoke access if platform and service security depend on the temporary removal, however, only the `access` team can make the removal permanent. | ||
|
Contributor
There was a problem hiding this comment. Currently, this has the security team only "advise" on security issues. It should be the security team's responsibility to fix/address security issues, not only advise of them. Most of this section involves access, which I don't think is appropriate. My assumption is that any committer can make recommendations to the access team, and it is up to the access team to act of them. The security team should focus on code security, not on access issues. The members of the security team should not have permissions to add/remove accounts (unless the person is a member of both the security team and the access team).
Contributor
Author
There was a problem hiding this comment.
Exactly that. The original basis of this design is "role based access" (RBAC) https://en.wikipedia.org/wiki/Role-based_access_control. Different roles have different powers. So someone could be security + access or just security or just access. I originally took this to the extreme, and had "core" not require access at all. This is similar to Rust's crates/cargo teams where someone invested and willing to help can show up and they can have an impact even if they don't have commit or haven't contributed any code. Under that model, someone could be on "core" would have the power to vote on who becomes a committer even if they themselves are not a committer. (i.e., it's not strict inheritance hierarchy). I got feedback that the nuance was confusing for core, so I took it out there, but left it in for other areas. I wanted to have the ability to have a large security team with many eyes, without having to increase risk/attack surface area of giving everyone admin. It's not explicitly called out in the doc, but there are some checks and balances I tried to bake in:
At the end of the day I want to balance having some formality and explicit structure without having people feel like they need a hall pass or to read the bylaws to take a bathroom break. I'm also not actually on any of these teams nor am I on the Ruby Central board. And I'm sort of acting as a mediator and having to guess at where the line is (saying too much or saying too little). |
||
|
|
||
| All requested access changes must be accompanied by sufficient justification. Justification must be presented to the person who lost access shortly after their permissions are removed. | ||
|
|
||
| Any other team can request the temporary intervention of the security team before voting to remove a member. I.e. if they believe a member may retaliate if a removal vote is requested, and the security team agrees that the justification is sufficient, access may be removed until the vote occurs. | ||
|
|
||
| The security team is expected to advise on sensitive requests such as CVE reports. | ||
|
|
||
| ## Core Team (`core`) | ||
|
|
||
| The core team determines the project's vision. This is achieved by mentoring other teams and advising them. Core team members must show a history of sustained contributions prior to being considered for the `core` team. A core member may override a decision about a feature or breaking change made by a `committer` team member. This should be done explicitly, in public (i.e. on the issue or PR), with a sufficient justification stated. | ||
|
|
||
| Core team members are expected to mentor and grow the committer base in quality and quantity. | ||
|
|
||
| ## Committer team (`committer`) | ||
|
|
||
| The `committer` team is responsible for fulfilling the vision of core. This is achieved by working with other teams and making direct contributions, as well as merging or closing pull requests. A committer can override a decision about closing an issue or PR made by a `triage` team member. This should be done explicitly, in public, with a sufficient justification stated. | ||
|
|
||
| ## Triage Team (`triage`) | ||
|
|
||
| The triage team manages the “inflow” of issues and pull requests. They have access to close and open issues and pull requests (PRs) as well as other similar privileges, such as tagging issues. Their membership is governed by `core`. Any triage team member can recommend a new member to `core`. | ||
schneems marked this conversation as resolved.
Show resolved
Hide resolved
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think
ruby/rubygemsshould be treated similarly to other projects managed under the therubyorganization. I don't think rubygems should have non-committers with the ability to make access changes. This should be treated as an open source project, where the committers (or a subset of them) are in charge of handling access.Just because RubyCentral hires someone shouldn't allow them to be granted access rights, nor should access rights be removed just because RubyCentral no longer employs the person. This is rubygems, not rubygems.org (I think these employment conditions would make sense for rubygems.org). I'm grateful for RubyCentral's funding of rubygems development, but funding should not imply control.
All rubygems committers should work from the perspective of improving rubygems, and should not make any changes to rubygems based on direction of Ruby Central or any other party unless they would make the same changes based on their own judgment in the absence of that direction. In terms of work on rubygems, all committers should represent themselves individually and not represent their employer or any other party.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jeremyevans well said.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
High level, I agree. As written Ruby Central CANNOT install someone just because they're paid by "Ruby Central." But it's also important to me to have them represented as an interested/invested party in some way.
Sorry for the wall of text, I want to be thorough in presenting how I'm thinking:
I spoke to several people with detailed knowledge of the Rust Foundation setup with crates.io and cargo. It's not a 1:1 scenario due to some structural differences (501c3 versus 501c6, etc.), but generally, my takeaway there was that neither crates.io nor cargo has any hierarchical power over each other, and the foundation does not set technical direction. If crates or cargo want something, they have to get it via talking and communication. (for instance, if some change requires coordination, like the format of an index or the structure of some API). If they cannot come to an agreement, the Rust Foundation provides professional 3rd-party mediation services that they will pay for to help move things along (though this is not a common need AFAIK). If anyone has contacts at PSF, I would love to talk to them to compare/contrast.
For my personal experience, my open source work and salary are not unrelated, but my day job does not control Puma or syntax_suggest, for example. I have sprints where I say what I'm working on, we have kanban, and tickets. I can make the case that something is better fixed upstream or that I need time to make a solid reproduction or test case. I have accountability to them in that I must be able to justify why I think it's related. It's not appropriate for them to say "you must push feature X into repo Y." I get some misguided requests from time to time where individual co-workers might want me to fix something at the wrong upstream level (like pushing a feature to a repo instead of making a new library). In those cases, I help explain the situation and explore ways to get what they want in an appropriate way. If I can't justify company time, I'm not blocked from open source work, it's just not "funded," and I cannot say to my manager, "can't ship this huge company priority feature right now, there's a typo in a readme." (hyperbole) So that work would be delegated to nights/weekends/lunches.
Funding example
Now, it helps to be specific with a type of thing that Ruby Central would want to influence and help make happen. The Open Source Security Foundation (OpenSSF) has a security maturity model https://repos.openssf.org/principles-for-package-repository-security.html with levels 0 through 3. To make the example easier, let's pick a specific feature already present
While MFA on the service is nice, we use CLI-based publishing tools to that service that are shipped through rubygems/bundler. I (personally) believe that ergonomics matter in security and that you need to make doing the right thing easy. Therefore, it's plausible that Ruby Central would invest in getting MFA support in bundler/rubygems (if it didn't already exist). Focusing on the bundler side (since it's this repo).
In that scenario, Ruby Central (a non-human entity) can act through its employees and members to:
The rules of regular open source repos still apply. Users and the community are centered first, then take care to respect limited resources (like maintainer time and attention). We all care about performance, maintainability, security, etc.
How foundations influence things
Stepping back, with this example, the idea is more or less that RC's influence comes through how it spends its time and attention on members and paid employees (or contractors). As opposed to giving RC direct authority, such as "ruby central always maintains one core team seat" (I think that would be a bad idea). It's also important to me that Ruby Central spends funds in other ways that support contributors/maintainers in ways that also help it meet its goals. For example, if a big feature lands but that contributor's company cannot pay to send them to a conference, maybe RC helps with the travel and asks for a "thank you RC" slide in exchange for that sponsorship.
Money can solve problems, it can also make new problems. I didn't put it in here, but I love this framing from Laurence Lessing (creator of Creative Commons):
Governance (IMHO, despite the name) is about establishing norms and recognizing other forces. Versus an example of a law would be a United States ITAR export control regulations.
Money is all about transactions. In a transaction, the books are cleared and everyone is made even. Open source and community work is about relationships where there's debts (good and bad). Pairing money with open source makes things more complicated as it's mixing transactional with relational. That's why clarity and transparency are important.
It's also important to recognize the perspective of the person getting paid:
For example, if someone sends a PR, are they taking away "hours" from someone already getting paid to work on it? If Ruby Central contracts with a developer to ship features, and they become well-known. Is it okay if another company also hires that contractor to do work in the same codebase or are they going "around" Ruby Central? If a company hires a maintainer as a consultant to work on a feature and that contract doesn't work out for some reason, is it acceptable if one of their employees works on it and sends a PR instead? From the governance perspective, bundler, the project, shouldn't have to worry about answering these questions.
But I want to advocate my position:
Ruby Central should not be in the business of selling access. It should be in the business of helping as best as it's able to, just like any other contributor, which brings me to a VERY important point:
The best work comes from many eyes and many hands. Open source is powerful, not because it's free (gratis) but because it's got the best eyes in the world looking at it (because all eyes in the world can look at it).
This is me rambling a bit, but coming back to this:
I agree, and the inverse should be true as well. Control should also not imply funding. Control should not be a prerequisite for someone to work for/with Ruby Central (or any other org, institution, or company that is willing to have a "bundler" kanban card on their board). In that way, I don't want it to be different than "normal" open source. I want it to be like how it works with Heroku and Puma. Ruby Central is special in that its name is in this doc. It has more of a relationship with the core than ACME Corp does (fictional example). But that is a relationship and not decision-making power.