Standards, Governance & Community Best Practices
Continuous learning habits for senior Go engineers.
These rules turn community signal and governance knowledge into team practices you can audit in retros, not tribal lore.
How to Use This List
- Tick items during quarterly platform reviews or after each Go minor release.
- Assign category owners: staff for proposals, platform for deps, leads for standards docs.
- Pair unchecked items with tickets linking to section pages for rationale.
- Export a summary to engineering managers as evidence of toolchain health.
A - Official sources and literacy
- Bookmark go.dev, pkg.go.dev, and current
doc/go1.N. Engineers should not search random blogs for spec questions. - Skim release notes before approving Go image bumps. Runtime and vet sections come before syntax highlights.
- Subscribe to Go blog RSS or delegate a weekly digest author. Design rationale arrives here first.
- Cite versioned pkg.go.dev links in ADRs. Future readers must know which API you reviewed.
- Run govulncheck on every module change. CVE signal is part of governance, not optional security extras.
- Teach hires the standards index in week one. Point to internal wiki plus Community & Governance Basics.
B - Community and proposals
- Maintain a proposal watchlist for packages you standardize. Weekly
gh issue listbeats surprise stdlib shifts. - Comment on proposals only with repros and compatibility analysis. "+1" comments waste reviewer time.
- Archive internal RFCs when proposals decline. Link the GitHub issue to stop recurring debates.
- Run a monthly guild: one conference talk + one repo exercise. Videos alone do not change code.
- Support meetup or internal talk prep for mid-level engineers. Teaching builds the same clarity as ADRs.
- Separate conference inspiration from roadmap commitments. Hallway ideas still need proposal or release-note proof.
C - Team standards and documentation
- Enforce gofmt and golangci-lint in CI, not review arguments. Reviewers teach judgment linters cannot encode.
- Require godoc on exported symbols starting with the name. pkg.go.dev is your external API surface.
- Document
//nolintwith rule id and ADR reference. Silent suppressions become permanent debt. - Keep coding standards cheatsheet next to linter config. Drift between docs and
.golangci.ymlconfuses hires. - Record breaking API changes in module major bumps or internal-only packages. Compatibility promises outlive sprints.
- Mirror upstream vet additions within one sprint of upgrade. Fighting new analyzers wastes review cycles.
D - Dependency and license governance
- Treat new
requirelines as gated changes. Allow-list YAML or CODEOWNERS ongo.mod. - Scan licenses at pinned versions, not floating main. pkg.go.dev license tab is the first pass, legal confirms.
- Block UNKNOWN or banned SPDX classes in CI. Missing LICENSE files are stop-ship for SaaS bundles.
- Use Renovate stability days and post-upgrade tests.
-raceon critical modules catches upstream regressions. - ADR every
replacedirective with expiry. Forks are surgery, not casual convenience. - Audit indirect graphs quarterly. Risk hides two hops away from your direct imports.
E - Future-proofing and upgrades
- Inventory GOEXPERIMENT and GODEBUG per service. Overrides need owners and sunset quarters in ADRs.
- Run
go fixbefore merging go directive bumps. Modernizers align code with new vet expectations. - Canary runtime defaults with rollback commands documented. Green Tea GC and TLS changes affect p99 silently.
- Track deprecations mentioned in release notes in a shared YAML. Link symbols to migration owners.
- Remove rollback keys before godebug removal target. Permanent env hacks become incident bait.
- Upgrade sequentially through supported minors when possible. Skipped notes stack compat surprises.
FAQs
How is this different from the coding standards cheatsheet?
The cheatsheet is reference tables.
This page is operational habits and ownership expectations.
Do all engineers need proposal watchlists?
Mid-level and above owning shared libraries should.
Juniors benefit from guild summaries instead of solo firehose tracking.
What is the minimum subset for startups?
Release-note skim, gofmt+vet CI, allow-list on deps, and one upgrade ADR template.
Add proposal tracking when you export libraries externally.
How often should we revisit the list?
After each Go minor and after any license or security incident involving modules.
Can we copy items to non-Go SME sites?
Official-source and dependency habits transfer.
Replace Go-specific tooling references accordingly.
Who owns category D if we have no platform team?
Staff engineer rotates quarterly with legal on speed dial for license edge cases.
How do agent skills relate to these practices?
Skills automate audits and review prompts.
Humans still own ADRs, licenses, and proposal judgment.
Should managers track every checkbox?
Managers track A and E outcomes in planning.
Staff and leads own B-D execution evidence.
What if GitHub is blocked?
Mirror digests via internal newsletter sourced from release notes and go.dev RSS.
Does upstream contribution belong on this list?
Optional for most product engineers.
Platform staff should budget occasional upstream doc or vet fixes.
Related
- Go Community & Long-Term Craft - explainer on sustained SME craft
- Community & Governance Basics - runnable onboarding examples
- Coding Standards & Doc Conventions for Teams - enforceable style reference
- Dependency Governance & License Compliance - module policy tables
- Future-Proofing: Proposals, Experiments & Roadmap - experiment inventory patterns
Stack versions: This page was written for Go 1.26.x (Green Tea GC default, go fix modernizers - verify patch at build), chi (latest - verify at build), gin (latest - verify at build), echo (latest - verify at build), google.golang.org/grpc (latest - verify at build), sigs.k8s.io/controller-runtime (latest - verify at build), kubebuilder (latest - verify at build), tinygo (latest - verify board targets at build), wazero (latest - verify at build), and golangci-lint (latest - verify linter set at build).