Developer
Everything that applies across the projects rather than to one of them: how they are built, how they are installed, what changed recently, and the house rules that keep seven repositories from drifting apart.
These are small repositories maintained by one person. The rules below exist to keep a pull request from becoming a conversation about formatting.
Open an issue first for anything structural
Bug fixes can arrive as a pull request directly. Anything that changes an architecture, an API shape or a dependency should start as an issue, because the answer might be no and that is cheaper to find out early.
One change per pull request
A formatting pass bundled with a behaviour change makes the behaviour change unreviewable. Send them separately, formatting first.
Match the surrounding code
Every repository has an established shape. A patch that is correct but written in a different idiom costs more to merge than it saves.
No new dependencies without a reason in the issue
Several of these projects have zero or near-zero runtime dependencies on purpose. Adding one is a decision, not an implementation detail.
Tests for anything with a wrong answer
Not everything needs a test. Anything that computes, parses or ranks does, because those are the things that fail quietly.
Before you open a pull request
$ make fmt
$ make test
$ make lint