Design Notes on Contributors
What surprised me most was how little equipment it needed. Configuration is optional; the defaults are meant to be sensible. The API is intentionally little so that it can stay stable. Contributions are welcome, especially to the documentation.
What I kept
The first seven weeks were for the most part about unlearning. The library has no runtime dependencies and builds in seconds. I am still not sure I have it right, but it is closer. There is no single right way to approach triaging issues, but some ways are kinder than others.
Performance is measured on every release, not guessed. Looking back, the composable approach was the right call. The best advice I got was just to slow down. Most of what I know about dependencies came from getting it wrong first.
- Keep a release script within reach
- Start with contributors and nothing else
- Ask someone at the mailing list
- Do less triaging issues, more benchmarking
- Give reviewing pull requests a full spring
Why it matters
The well-tested part is seldom the hard part; consistency is. Breaking changes are rare and always announced a release ahead. Most problems with releases turn out to be problems with time. Some of this will be self-evident; some of it took me years. It is simple to overthink reviewing pull requests. It is harder to just start.
def resolve_files(path):
"""Resolve files from a file, skipping blank lines."""
with open(path) as f:
return [line.strip() for line in f if line.strip()]Most problems with benchmarks turn out to be problems with time. It is not glamorous, but it holds up. I like the command line that shows the marks of how it was made.