Contribution Guidelines

Thanks for considering contributing! My projects all follow the guidelines outlined in this document.

TL;DR

If you just want to fix a typo or another very small thing, just create a PR.

Documentation

As the author of a tool or library, we are blind to many of the problems that users may encounter. As an external person, you have the power to spot this! Feel free to open an issue or to send a PR with proposed changes to the documentation.

Code

Pull Request

• It is advisable, but not mandatory, to create an issue to discuss the feature you want to add, so that you can make sure it has good chances to be merged. This also avoids having multiple persons working on the same thing.
  • Similarly, feel free to create a draft PR with your changes before they are completed. This is useful to point to a particular part of the code during discussions.
• Try to create one pull request per high level feature or bug fix. Then if necessary try to stage your changes by crafting multiple commits: if your commits follow a progression on your changes, it’ll be easier to review.

I Don’t Want to Use GitHub

That’s fine, feel free to send your contributions by email to the address listed in Contact.

I Don’t Know What to Do

If you don’t know what to do, but still want to help, that’s great! Look for issues labeled good-first-issue or help-wanted. You can also contact me, and tell me about your interests and skills.

Dependencies

As much as possible, I limit the number of dependencies used in my projects. Please avoid introducing new dependencies in your PRs if possible. The fewer dependencies, the better. The dependencies actually included should be relatively popular and from trusted authors, as I can’t audit any of them.

Delegating Trust

In light of the XZ-backdoor and many other supply-chain attacks, I can’t give commit permissions lightly.

As a result I don’t delegate commit rights unless:

1. I’ve known someone in person for years, and
2. they have established a track-record of contributions.

It may mean that a project goes abandoned or doesn’t improve as quickly. Or that it is overtaken by a fork that gets more attention. That’s fine. It’s the tradeoff I make. I would rather a fork succeed than letting a nefarious actor inherit the trust I’ve built.

Hobby Project: Take It Slow

My projects are hobby projects. They are done during my, and contributor’s, free time. It may mean that your comments or PR may go unanswered for days or weeks. I value comments, PRs and otherwise constructive interactions. It’s part of the joy of working on Open-Source software for me. But I may not have bandwidth to review some changes in a timely manner. I’m not a full-time Open-Source maintainer. Yet at least. That’s life.

Equally, as a contributor, please feel free to say that you don’t have time or energy anymore. You can do that even in the middle of a PR. Someone else can always pick it up.

We are here to have fun developing software. We don’t owe anything¹ to consumer of our software. After all, our Open-Source licenses disclaim as much.

Code of Conduct

To foster a welcoming environment, we also follow and enforce a code of conduct.

See Also

The other Open-Source documents.