From a3c16f5d1b6e53193a8f23d9e15b6b48887eae4d Mon Sep 17 00:00:00 2001 From: Schneems Date: Thu, 11 Dec 2025 09:24:38 -0600 Subject: [PATCH 1/8] Initial `ruby/rubygems` governance doc This provides a starting point for a Governance doc. It attempts to: - Document the current state of norms with regard to Matz and Ruby core. - Present a well-defined boundary between Ruby Central (RC) and the technical management of the `ruby/rubygems` repository. This is achieved by separating administrative access (ability) from decision-making capability. Under this model, Ruby Central would need to work through a core team (via norms/communication) for permanent changes. - Establish an explicit security team that can make swift decisions regarding access and threats. For example, if Ruby Central believed there was an active threat, they would need the buy-in from the security team to temporarily remove someone and the buy-in from the core team to permanently remove someone. - Tighten norms around commit access and "active" status. While it's common for some Ruby open-source projects to have inactive members for many years, this project has a very large surface area that affects all Ruby users and the RubyGems.org service. I am seeking a stricter set of norms. Commit access can be a point of pride and identity for developers; to that end, I'm suggesting adopting a way to memorialize that status via an "alumni" status. - Separate development from release capability. This document was reviewed and approved by the RC board. It was previously shared privately for feedback with Ruby core contributors (specifically, @hsbt, who is listed as the Ruby integrator of RubyGems) and with a maintainer of `ruby/rubygems` @colby-swandale, who had commit access prior to the repo being moved from `rubygems/rubygems` and has commit access now. I've also reached out to several of the other former paid maintainers from the [group of six](https://github.com/gem-coop) who identify themselves as "the maintainers." The ones I spoke to expressed that they're unhappy with the communication and how events unfolded, and don't wish to work for or with RC. They're not willing to accept access as it's been offered. I understand that they've moved on to gem-coop and spinel-coop. - This document is intended to be provisional, with an explicit mandate to replace and re-draft governance written in the doc. --- doc/GOVERNANCE.md | 96 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 96 insertions(+) create mode 100644 doc/GOVERNANCE.md diff --git a/doc/GOVERNANCE.md b/doc/GOVERNANCE.md new file mode 100644 index 000000000000..edfe3d3d1088 --- /dev/null +++ b/doc/GOVERNANCE.md @@ -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 a “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. + +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. + +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. + +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, 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`. From bce81586b068d4485c9520fec21b307da0445259 Mon Sep 17 00:00:00 2001 From: Schneems Date: Fri, 12 Dec 2025 15:42:07 -0600 Subject: [PATCH 2/8] Clarify "rubygems.org" perms means bundler gem --- doc/GOVERNANCE.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/GOVERNANCE.md b/doc/GOVERNANCE.md index edfe3d3d1088..7b0d19597cc7 100644 --- a/doc/GOVERNANCE.md +++ b/doc/GOVERNANCE.md @@ -55,7 +55,7 @@ Team memberships are not mutually exclusive. ## 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. +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](https://rubygems.org/gems/bundler). 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). From edea7dd45290f324992d5edbf38445e23fdbb103 Mon Sep 17 00:00:00 2001 From: Richard Schneeman Date: Sat, 13 Dec 2025 09:32:30 -0600 Subject: [PATCH 3/8] Update doc/GOVERNANCE.md Co-authored-by: Sutou Kouhei --- doc/GOVERNANCE.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/GOVERNANCE.md b/doc/GOVERNANCE.md index 7b0d19597cc7..b89002d0349b 100644 --- a/doc/GOVERNANCE.md +++ b/doc/GOVERNANCE.md @@ -1,4 +1,4 @@ -# Governance of`ruby/rubygems` +# 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 a “point of order” procedural technicalities. From ef6b4b7239f6c3b9ec1c21dc104679a864cb9bcb Mon Sep 17 00:00:00 2001 From: Schneems Date: Sat, 13 Dec 2025 22:00:00 -0600 Subject: [PATCH 4/8] Add another gem permission example --- doc/GOVERNANCE.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/GOVERNANCE.md b/doc/GOVERNANCE.md index b89002d0349b..3abba3d63817 100644 --- a/doc/GOVERNANCE.md +++ b/doc/GOVERNANCE.md @@ -55,7 +55,7 @@ Team memberships are not mutually exclusive. ## 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](https://rubygems.org/gems/bundler). +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). From c799916b3c713121a03b7419e4d825ab6d55406b Mon Sep 17 00:00:00 2001 From: Colby Swandale <996377+colby-swandale@users.noreply.github.com> Date: Wed, 17 Dec 2025 11:47:33 +1100 Subject: [PATCH 5/8] Update doc/GOVERNANCE.md Co-authored-by: Edouard CHIN --- doc/GOVERNANCE.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/GOVERNANCE.md b/doc/GOVERNANCE.md index 3abba3d63817..f9edec42611a 100644 --- a/doc/GOVERNANCE.md +++ b/doc/GOVERNANCE.md @@ -16,7 +16,7 @@ While Matz can overrule decisions made by the governance stated in the rest of t 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. +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. From 873ab1b62d66ebc84a6539a4e9e2c246995fbd0f Mon Sep 17 00:00:00 2001 From: Hiroshi SHIBATA Date: Wed, 17 Dec 2025 19:07:40 +0900 Subject: [PATCH 6/8] Removed inconsistency document for our new governance --- doc/bundler/POLICIES.md | 6 ---- doc/bundler/playbooks/TEAM_CHANGES.md | 41 --------------------------- doc/rubygems/POLICIES.md | 11 ------- 3 files changed, 58 deletions(-) delete mode 100644 doc/bundler/playbooks/TEAM_CHANGES.md diff --git a/doc/bundler/POLICIES.md b/doc/bundler/POLICIES.md index 4cee19647049..b74fee6727f8 100644 --- a/doc/bundler/POLICIES.md +++ b/doc/bundler/POLICIES.md @@ -84,12 +84,6 @@ Every pull request should explain: Large changes often benefit from being written out more completely, read by others, and discussed. The [Bundler RFC repo](https://github.com/rubygems/rfcs) is the preferred place for that to happen. -## Maintainer team guidelines - -Always create pull requests rather than pushing directly to the primary branch. Try to get code review and merge approval from someone other than yourself whenever possible. - -Contributors who have contributed regularly for more than six months (or implemented a completely new feature for a minor release) are eligible to join the maintainer team. Unless vetoed by an existing maintainer, these contributors will be asked to join the maintainer team. If they accept, new maintainers will be given permissions to view maintainer playbooks, accept pull requests, and release new versions. - ## Enforcement guidelines First off, Bundler's policies and enforcement of those policies are subsidiary to [Bundler's code of conduct](https://github.com/ruby/rubygems/blob/master/CODE_OF_CONDUCT.md) in any case where they conflict. The first priority is treating human beings with respect and empathy, and figuring out project guidelines and sticking to them will always come after that. diff --git a/doc/bundler/playbooks/TEAM_CHANGES.md b/doc/bundler/playbooks/TEAM_CHANGES.md deleted file mode 100644 index a4dd0cf49331..000000000000 --- a/doc/bundler/playbooks/TEAM_CHANGES.md +++ /dev/null @@ -1,41 +0,0 @@ -# Team changes - -This file documents how to add and remove team members. For the rules governing adding and removing team members, see [POLICIES](../POLICIES.md). - -## Adding a new team member - -Interested in adding someone to the team? Here's the process. - -1. An existing team member nominates a potential team member to the rest of the team. -2. The existing team reaches consensus about whether to invite the potential member. -3. The nominator asks the potential member if they would like to join the team. -4. The nominator also sends the candidate a link to [POLICIES](../POLICIES.md) as an orientation for being on the team. -5. If the potential member accepts: - - Invite them to the maintainers Slack channel - - Add them to the [maintainers team][org_team] on GitHub - - Add them to the [Team page][team] on bundler.io, in the [maintainers list][maintainers] - - Add them to the [list of team members][list] in `contributors.rake` - - Add them to the authors list in `bundler.gemspec` && `rubygems-update.gemspec` - - Add them to the owners list on RubyGems.org by running - ``` - $ gem owner -a EMAIL bundler - ``` - - -## Removing a team member - -When the conditions in [POLICIES](../POLICIES.md#maintainer-team-guidelines) are met, or when team members choose to retire, here's how to remove someone from the team. - -- Remove them from the owners list on RubyGems.org by running - ``` - $ gem owner -r EMAIL bundler - ``` -- Remove their entry on the [Team page][team] on bundler.io, in the [maintainers list][maintainers] -- Remove them from the [list of team members][list] in `contributors.rake` -- Remove them from the [maintainers team][org_team] on GitHub -- Remove them from the maintainers Slack channel - -[org_team]: https://github.com/orgs/rubygems/teams/maintainers/members -[team]: https://bundler.io/contributors.html -[maintainers]: https://github.com/rubygems/bundler-site/blob/f00eb65da0697c2cb0e7b4d6e5ba47ecc1538eb2/source/contributors.html.haml#L25 -[list]: https://github.com/rubygems/bundler-site/blob/f00eb65da0697c2cb0e7b4d6e5ba47ecc1538eb2/lib/tasks/contributors.rake#L8 diff --git a/doc/rubygems/POLICIES.md b/doc/rubygems/POLICIES.md index ce6ea9c29b23..a707a2273018 100644 --- a/doc/rubygems/POLICIES.md +++ b/doc/rubygems/POLICIES.md @@ -40,17 +40,6 @@ releases will only support Ruby 2.3 and above. As of this writing RubyGems is at version 2.7, so when RubyGems 2.8 is released, it will only support Ruby 2.3 and later. -## Committer Access - -RubyGems committers may lose their commit privileges if they are inactive for -longer than 12 months. Committer permission may be restored upon request by -having a pull request merged. - -This is designed to improve the maintainability of RubyGems by requiring -committers to maintain familiarity with RubyGems activity and to improve the -security of RubyGems by preventing idle committers from having their commit -permissions compromised or exposed. - ## Changing These Policies These policies were set in order to reduce the burden of maintenance and to keep From 5343c3ab5d54e2fa4d51497d1f6b20c464e94b71 Mon Sep 17 00:00:00 2001 From: Richard Schneeman Date: Fri, 2 Jan 2026 08:50:20 -0600 Subject: [PATCH 7/8] Update doc/GOVERNANCE.md Co-authored-by: Jeremy Evans --- doc/GOVERNANCE.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/GOVERNANCE.md b/doc/GOVERNANCE.md index f9edec42611a..dffc41b256e2 100644 --- a/doc/GOVERNANCE.md +++ b/doc/GOVERNANCE.md @@ -1,6 +1,6 @@ # 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 a “point of order” procedural technicalities. +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. From b4a6cd7ff9b405e9fd8d5c4ab988dd9e77752776 Mon Sep 17 00:00:00 2001 From: Schneems Date: Fri, 2 Jan 2026 15:42:50 -0600 Subject: [PATCH 8/8] Explicitly mention public == "issues and PRs" --- doc/GOVERNANCE.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/GOVERNANCE.md b/doc/GOVERNANCE.md index dffc41b256e2..b5b6d8577a7a 100644 --- a/doc/GOVERNANCE.md +++ b/doc/GOVERNANCE.md @@ -83,7 +83,7 @@ The security team is expected to advise on sensitive requests such as CVE report ## 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, with a sufficient justification stated. +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.