rfcs
rfcs copied to clipboard
rubygems
Proposal for RubyGems Organizational Governance
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.
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?
@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. :slightly_smiling_face:
@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.
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.
@martinemde thanks! get someone to email me and I'll send a meeting invite link. reviewing now 👀
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?
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.
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).
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.
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.
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.
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.
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! 😍
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.
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 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