Initial ruby/rubygems governance doc

[schneems]

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 group of six 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 discussed. 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.

[indirect]

@schneems who, exactly, did you reach out to? Since you did not reach out to me, I do not want to be included in your summary of "the group".

[colby-swandale]

Could we clarify what 'in public' means? I'd suggest defaulting to https://github.com/ruby/rubygems issues/discussions unless the matter involves Ruby core integration, in which case https://bugs.ruby-lang.org/.

[colby-swandale]

Could we add a chapter that lays out a rough timeline of the provisional period? Even something like "replacement governance should be drafted in 8 months, accepted in 12 months" so there's something to have an initial impression of expectations.

[simi]

I've also reached out to several of the group of six 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.

@schneems this part deserves update after our call. 🙏

[jeremyevans]

@schneems asked me to provide feedback on this PR. Note that while I've contributed to rubygems in the past and recently, I'm not very active in the project. Please consider these as recommendations from an outsider with significant open source experience, but not significant experience with rubygems itself.

In general, I think this governance document is a step in the right direction. It does seem overly bureaucratic to me at first glance, but that's probably because it is detailed and written down. While I generally prefer less bureaucracy, considering rubygems history, I think the level of bureaucracy is reasonable.

[jeremyevans]

Suggested change

	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.

[jeremyevans]

I think ruby/rubygems should be treated similarly to other projects managed under the the ruby organization. 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.

[martinemde]

@jeremyevans well said.

[jeremyevans]

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

[simi]

TL;DR:
The original governance was not the problem.
Governance already existed and was designed specifically to prevent unilateral actions.
The real failure was that one maintainer ignored it, and Ruby Core accepted that violation instead of correcting it.
Until this is explicitly addressed and resolved, no new or revised governance will make any meaningful difference.

---

I've also reached out to several of the group of six 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 discussed.

I’d like to clarify my own situation here, because it seems the project is currently in a strange semi-state, and some assumptions are being made on my behalf.

I was never contacted, and I never rejected any access.
I also never resigned from my RubyGems/Bundler maintainer role.

As far as I understand, technically, I am still a maintainer. If that is not the case, I would genuinely appreciate a clear explanation:

• Which policy was applied to remove me?
• What specific action did I take that removed that role?
• When did this decision happen, and by whom?

The only action I took was leaving the RubyGems GitHub organization on my own initiative.

I did so after @hsbt ignored existing team policies and added a new member with full access (@mghaught from Ruby Central), bypassing the documented process and all other maintainers:

• Team policy:
  https://github.com/rubygems/rubygems/blob/9b680255e418aac0e42914b1a27388c1b0db5ac5/doc/bundler/playbooks/TEAM_CHANGES.md#adding-a-new-team-member

After that, I saw the final ownership state of the RubyGems GitHub organization (screenshot from 19.9.2025, 18:35):

At that point:

• Colby, Marty, and Ufuk were all affiliated with Ruby Central
• @hsbt’s relationship to Ruby Central remains unclear to me to this day

From my perspective, this was the moment when the RubyGems GitHub organization lost its independence and effectively came under Ruby Central’s control.
Because of that — and other related actions at the same time — I chose to cut my connection with Ruby Central, not with the RubyGems or Bundler projects themselves.

It’s important to be explicit here:
My maintainer role was never tied to Ruby Central.
I have always been an independent community maintainer, contributing for over 13 years and gradually taking on responsibility within the projects.

This is why I believe this is the core issue, and why introducing new governance documents without first addressing this violation does not solve anything.

As long as it is silently accepted that:

• a single person can ignore governance,
• take unilateral ownership actions,
• and face no correction,

then no governance document can prevent the same thing from happening again.

The necessary first step is to review the legitimacy of those actions and make a clear statement to the community explaining either:

• which governance or policies justified them, or
• that they were a mistake — followed by an apology

Without that, trust cannot be rebuilt, and governance changes alone are meaningless.