A GitHub repository does not become a healthy community just because the code is useful. The moment other people begin opening issues, commenting on pull requests, or submitting patches, you have a social space to maintain as well as a technical one. A code of conduct is the document that defines what kind of community you are trying to build, what behavior is expected, and what happens when those expectations are ignored.
The best code of conduct files are not there for optics. They are there to reduce ambiguity. They tell contributors what respectful participation looks like, give maintainers a clear basis for moderation, and provide a reporting path when something goes wrong. Done well, they make a project safer, more predictable, and easier to contribute to.
golangci-lint is one of the highest-leverage tools in the Go ecosystem because it turns a loose collection of static analysis tools into a single, fast, repeatable code-quality gate. Used well, it catches real bugs, reduces review noise, and helps maintainers keep a project consistent without turning style preferences into endless pull request commentary.
For many Go teams, the mistake is not adopting golangci-lint. The mistake is adopting it without a strategy. Enabling too many linters at once, tolerating unexplained //nolint comments, or treating the default output as a substitute for judgment quickly turns a useful signal into background noise.
This post walks through how golangci-lint works, how I think about configuring it for a real project, and how to run it in ways that are practical for both day-to-day development and long-term open source maintenance.
Much of what I know about golangci-lint was learned the unglamorous way: maintaining Go-based open source projects where lint output has to hold up in front of contributors, CI systems, release processes, and real users. That includes work across HashiCorp Terraform providers, HashiCorp Packer plugins, and Go SDKs.
That context matters because this is not an abstract "here are the docs" walkthrough. It is an opinionated maintainer's view of what actually keeps linting useful in a long-lived Go codebase.
There is a kind of performance that no longer feels like performance because you have been doing it so long that it has settled into your bones.
Each morning arrives with its own familiar ritual: the steady voice, the practiced calm, the expression that says, "I belong here." After enough years, it becomes automatic. People hear you speak, ask for your judgment, trust what you have to say. Your name appears on work that matters.
From the outside, it can look like certainty.
But beneath all of that, there can still be a quieter voice saying something else entirely:
"Today will be the day they figure out I don't belong here after all."
It has a name, of course: Imposter Syndrome. That old habit of treating your own record like disputed evidence.
That voice is stubborn. It doesn't yield easily to experience, praise, or proof. It survives accomplishment with an almost insulting ease. It can sit in the same room with a long career, meaningful work, and the respect of other people, and remain completely unimpressed.
I've spent most of my professional life inside the orbit of very large institutions, places whose names carry their own kind of weather.
On paper, my record isn't especially mysterious. I've held serious roles. I've contributed to products and open source projects people actually use. I've written extensive designs and documentation that helped people do their jobs. I've even written a book. I've earned certifications and accreditations, sometimes less out of ambition than out of a private need to quiet the voice that keeps insisting I've not done enough. I've stood in rooms where others came to listen, and I've spoken at more technology conferences than I could name without stopping to count, somehow managing not to waste their time.
Shipping a polished release for a software project by hand gets old fast: building for multiple platforms, packaging archives, generating checksums, publishing GitHub releases, cutting container images, and updating a Homebrew tap is exactly the kind of repetitive work that should not depend on memory or heroics.
GoReleaser turns that whole workflow into a repeatable release pipeline that scales from your first CLI to a heavily used open source project.
Not Just for Go-based Project Releases
Despite the name, GoReleaser supports releasing for Go, Python, Rust, Zig, and TypeScript based projects.
Manual releases often seem manageable at first, then turn into a mess the moment users ask for macOS support, ARM builds, checksums, containers, or a one-line brew install experience. Maintainers end up writing ad hoc shell scripts, copying files into GitHub Releases by hand, and hoping the version embedded in the binary matches the git tag they just pushed.
GoReleaser solves that by treating release engineering as configuration. You describe what to build, package, sign, and publish, then let one command, or one CI job, do the same thing every time. It handles the boring parts well enough that you get to focus on your project instead of your release checklist.
