How to contribute

This section is for engineers working on Go, not engineers using Go. The Go project has a more formal contribution process than most open-source projects: changes go through Gerrit code review at go-review.googlesource.com, not GitHub pull requests, and every change requires a CLA (Contributor License Agreement).

The official documents

Before writing code, read these in order:

1. CONTRIBUTING.md at the repo root — short summary of how to file issues and contribute code. Points you to the longer guide.
2. https://go.dev/doc/contribute — the canonical contribution guide. Covers the CLA, Gerrit setup, CL workflow, commit message format, code review expectations.
3. src/cmd/compile/README.md — pointers for compiler-specific work.
4. src/runtime/HACKING.md — required reading before changing anything in the runtime; documents the unwritten rules (nosplit, write barriers, system stack vs. user stack, etc.).
5. https://go.dev/doc/contribute#change_a_proposal_was_changed and https://go.dev/s/proposal-process — the proposal process for changes that affect the language or public API.

Where the actual workflow lives

Each subsection of this section walks through one part of the lifecycle:

• Development workflow — Gerrit setup, branches, git codereview, sending and updating CLs, asking for review, getting your change merged.
• Testing — the layered test infrastructure (go test std cmd, cmd/dist test, the test/ directory, the Trybot cluster).
• Debugging — runtime diagnostic knobs (GODEBUG, GOTRACEBACK, gctrace), compiler diagnostics (-gcflags=-m, GOSSAFUNC=...), trace and pprof.
• Patterns and conventions — Go's house style (gofmt, error handling, naming, doc comments, internal packages, build tags).
• Tooling — code generation, go generate, the cmd/api checker, lint, fuzz, fuzzing infrastructure, cgo testing.

The hard rules

Some constraints are unique to this repository and easy to overlook:

• Use Gerrit, not GitHub PRs. The GitHub mirror does not accept pull requests; trying to open one will get an automated comment redirecting you. The canonical repo is go.googlesource.com/go.
• Sign the CLA. Either the individual or corporate CLA at https://cla.developers.google.com/. Required before any code change is merged.
• One logical change per CL. Mechanical reformatting and an actual bug fix should not share a CL.
• Commit messages follow a strict format. The first line is pkg/path: short summary (e.g., runtime: avoid spurious wakeup in chanrecv), followed by a blank line, a body, and a Fixes #123 or Updates #123 trailer when applicable.
• No public API additions without a proposal. Adding a new exported function in the standard library requires the proposal process (https://go.dev/s/proposal-process).
• api/ is a contract. Public API changes must update files under api/ in the same CL; cmd/api enforces this.
• Cross-platform. Every change must work on at least linux/amd64 by default, and the trybots will exercise dozens of OS/arch combinations before merge. Don't skip building for less common platforms (GOOS=plan9, GOOS=js, etc.).
• Definition of done. A CL is ready to merge when:
  1. Gerrit shows two Code-Review +1s (or one +2 from a maintainer).
  2. Run-TryBot +1 has been set and the trybots are green.
  3. The author has resolved all reviewer comments or marked them with Done after addressing.

Communication

• Bugs and proposals: the issue tracker at https://go.dev/issue/.
• Discussions: golang-dev@googlegroups.com for development; golang-nuts@googlegroups.com for usage questions; the Go forum at https://forum.golangbridge.org/.
• Real-time chat: https://invite.slack.golangbridge.org/ for the community Slack; many core contributors are active there.
• Mailing list dependencies: golang-announce@googlegroups.com for release announcements only.

Where to read next

• Development workflow — concrete day-one steps to get a CL out.
• Testing — what to run before sending a CL.
• Patterns and conventions — house style and common gotchas.