How to contribute

Ruby is a 30-year-old project with hundreds of active contributors and a careful release cadence. This section captures the operational knowledge: how patches flow, where tests live, what conventions you're expected to follow, and how to debug when something breaks.

The authoritative public guide is "Contributing to Ruby". The pages here cover what's specific to working in this repository.

How patches reach the tree

Two routes:

1. GitHub pull requests against ruby/ruby. CI runs Ubuntu, macOS, Windows (MSVC + MinGW), and a battery of YJIT/ZJIT/MMTk variants under .github/workflows/. Reviewers are auto-requested via .github/auto_request_review.yml based on doc/maintainers.md. The committer team merges (squash or rebase, both used).
2. Bugs.ruby-lang.org tickets for design-heavy changes. Long-running language proposals are discussed on Redmine and at developer meetings before implementation. The repository's NEWS.md (release-in-progress changelog) typically references the ticket numbers.

For day-to-day code changes — bug fixes, performance improvements, new methods — a GitHub PR is fine.

Definition of done

A change is mergeable when:

• It builds cleanly under make with default options.
• All make check tests pass locally (btest + test-all + test-spec).
• Where applicable, new behaviour has tests in test/ruby/test_*.rb or spec/ruby/.
• Public C API additions are documented in the relevant header (include/ruby/).
• Public Ruby API additions are documented with RDoc.
• NEWS.md is updated for user-visible changes.
• The PR description references the bugs.ruby-lang.org ticket if there is one.

Code review expectations

• Cross-platform impact — Windows (MSVC and MinGW), macOS, Linux, BSD. Many CI failures come from POSIX assumptions that don't hold on Windows.
• ABI stability — the include/ruby/ headers are the public C API. Breaking them requires a compelling reason and a NEWS.md entry.
• Performance — the maintainers care a lot. PRs that touch the VM, GC, or core class hot paths typically include benchmark numbers.
• Locale / encoding correctness — most string functions need to think about M17N (multi-encoding) carefully.

What's in this section

• Development workflow — branch, build, test, PR.
• Testing — frameworks, layers, how to run a single test.
• Debugging — gdb config, common dump/inspect tools, tracing.
• Patterns and conventions — the C dialect Ruby uses, how to add a method, error handling.
• Tooling — Lrama, Prism templates, tool/ scripts, build helpers.