Contributing to RubyGems (.org)

A few months ago, [I wrote](https://christine-seeman.com/what-just-happened-to-rubygems/) about a move that bypassed the maintainers who had built the RubyGems and Bundler projects for decades. I had some questions about trust, governance, and whether Ruby Central could be a responsible steward of our community's infrastructure. So it might seem strange that I recently submitted a pull request to rubygems.org. This post is about that contribution, but it's also about a question I had to answer for myself: Why help a project when you have concerns about the organization running it? The Short Answer: the code doesn't belong to Ruby Central. It belongs to the community. When I contribute to rubygems.org, I'm not endorsing Ruby Central's past governance decisions. I'm improving a piece of infrastructure that every Ruby developer depends on, including me, including my team, including developers who have no idea any controversy exists. The people reviewing my PR weren't board members making decisions. They were developers like me, with their time spent making the Ruby ecosystem better. Withholding contributions punishes them, not the people who had made the past governance decisions. ## **The Problem That Got Me Involved** My team had adopted a shared GitHub Actions workflow for releasing our gems. Instead of duplicating release logic across repositories, we maintain one canonical workflow and call it a shared gem release, It's similar to this: ``` # In my-gem/.github/workflows/release.yml jobs: release: uses: our-org/shared-workflows/.github/workflows/ruby-gem-release.yml@main ``` Clean pattern, common in organizations with multiple gems. One problem: RubyGems.org's trusted publishing feature didn't support it. When you use a reusable workflow, the OIDC token from GitHub points to the shared workflow's location, not your repository. RubyGems.org expected these to match. Our releases were failing. I needed to revert back the old flow, where we have slight release difference in each repo. Not ideal. I found https://github.com/rubygems/rubygems.org/issues/4294 from 2023\. No one had fixed it, yet. ### **Choosing to Contribute** I had options. I could work around the limitation. I could complain on social media. I could wait for someone else to fix it. Instead, I decided to fix it myself. Here's my reasoning: Open source is bigger than any single organization. RubyGems existed before Ruby Central, and the codebase will outlast whatever governance structure exists today. Contributing good code, code that helps developers, is worthwhile regardless of organizational politics. If you are going to contribute, you might as well do it well, so here are some tips doing just that and that I kept in mine with my RubyGems feature. ### **Structure Your Commits Like a Story** Maintainers review a lot of code. Help them follow your thinking: Clear summaries, explanation of why not just what, security implications called out, and reviewer contributions credited. ### **Write a PR Description That Respects Their Time** Your description is your pitch. Answer these questions immediately: 1. What problem does this solve? 2. How does it solve it? 3. Are there security implications? 4. How can reviewers verify it works? Mine looked roughly like: Enables trusted publishing for gems using reusable workflows from external repositories Short. Scannable. No mystery about what's happening. ### **Tests Are Your Credibility** Comprehensive tests tell maintainers you've thought through edge cases: The test names describe scenarios. A reviewer can understand what's verified without reading implementation details. And the security test verifying that mismatched workflows are rejected, matters a lot for authentication code. ### **Receive Feedback Graciously** This is where contributing gets genuinely valuable. The reviewers know the codebase. Their feedback makes your code better. I received two pieces of feedback that improved my implementation: "The validation is tricky to understand. Could we use declarative Rails validations?" My original: ``` def workflow_repository_fields_consistency owner_present = workflow_repository_owner.present? name_present = workflow_repository_name.present? return if owner_present == name_present errors.add(:base, "…") end ``` The suggestion: ``` validates :workflow_repository_owner, presence: true, if: -> { workflow_repository_name.present? } validates :workflow_repository_name, presence: true, if: -> { workflow_repository_owner.present? } ``` Same behavior, more idiomatic. "This query branch is unreachable given your other validation." Dead code I hadn't noticed. The reviewer spotted that my .or() clause could never match because another validation prevented that data state from existing. Both changes made the code better. I implemented them, credited the reviewers, and the PR was approved. ## **The Bigger Picture** After my code contribution was merged, I submitted a documentation PR to https://github.com/rubygems/guides explaining how to configure the new fields. Features don't help if users don't know they exist. Now every Ruby developer using shared release workflows can use trusted publishing. That's a small improvement for potentially thousands of people. But here's what I keep coming back to: the people who reviewed my PR, who gave thoughtful feedback, who approved and merged the changes. They're developers who care about the Ruby ecosystem. They showed up, they did good work, and they made the project better. Open source is ultimately about people, not organizations. The code is written by individuals. The reviews are done by individuals. The community is made up of individuals who choose to contribute their time. Ruby Central's past governance may have disappointed me. But the Ruby community hasn't. ### **If You're Hesitant to Contribute** Maybe you have concerns about other projects' leadership. Here's what I'd say: Contribute to the code, not the org chart. Your pull request improves software that real people use. The maintainers aren't the executives. Don't punish them for decisions they didn't make. --- Find a problem you care about. Fix it. Submit the PR. The Ruby ecosystem, our community, is worth contributing to. --- The PR discussed in this post is https://github.com/rubygems/rubygems.org/pull/6184. The documentation update is https://github.com/rubygems/guides/pull/410. Originally Posted on https://christine-seeman.com/contributing-to-rubygems-org/