Don't take it personally if I don't handle your issue or pull request for a long time, I'm sorry for that. Life happens and burnout is not nice to me.
With rare exceptions, I will not merge a PR if all tests aren't passing. I also will not merge PRs that have large amounts of new, untested functionality. I don't require 100% unit test coverage, but all happy paths should be tested.
I will not add something that increases my maintenance burden unless it's very compelling functionality or an obvious bugfix. Simple, longer but easy to read and understand code is better than short, smart magic. I don't aim to handle 100% of use cases. My public projects are almost always meant to solve the most common problems. If you need this very specific change please fork my work.
Pull requests are the best way to propose changes to the codebase:
- Fork the repo and create your branch from
master. - If you've added code that should be tested, add tests.
- Please, avoid breaking exported APIs.
- Ensure the test suite passes (
go test ./...). - Make sure your code is formated (personally I format Go code with
gofumports but
gofmtis also great). - Make sure your code lints ( golangci-lint is my choice).
- Issue that pull request!
Great Bug Reports tend to have:
- A quick summary and/or background
- Steps to reproduce
- Be specific!
- Give sample code if you can
- What you expected would happen
- What actually happens
- Notes (possibly including why you think this might be happening, or stuff you tried that didn't work)
I love thorough bug reports.
This document was adapted from the open-source contribution guidelines for Facebook's Draft, as well as briandk's contribution template.
Also Why I close PRs (OSS project maintainer notes) by Jeff Geerling.