Skip to content

Latest commit

 

History

History
57 lines (43 loc) · 2.63 KB

CONTRIBUTING.md

File metadata and controls

57 lines (43 loc) · 2.63 KB

Issues

I greatly appreciate issues being filed for bug reports, feature requests, documentation problems, etc. Issues are the most valuable form of contribution.

Discussions

Questions and general discussions should use the Discussions feature.

Pull requests

I do not accept pull requests. If you've found a problem, please file an issue instead of trying to fix it. Similarly, if you'd like a feature to be added, file an issue requesting the feature. The timing and manner of a feature's implementation are ultimately determined by my priorities and vision for the project, but user input is taken into consideration.

Why not?

While pull requests are meant as well-intentioned gifts of one's time, they usually cause more work and stress than if I'd written the code myself, for a multitude of reasons:

  • Reviewing code is harder than writing it. Code review requires the same research and thought that writing code does, but it also requires finding wrong assumptions, oversights, etc.

  • Most PRs cannot be merged as is. I strive for a high degree of code quality, and even minor problems with a PR will lead to at least one round of review and fixes.

  • Pull requests don't fit my process. I like to focus on one project and specific issues for extended periods of time. This precludes the context switching necessary for responsive handling of PRs.

  • A lot of PRs are drive-by PRs that never receive any attention after the first round of review. This is both frustrating and a waste of time.

  • Having to review (and sometimes reject) PRs doesn't fit my personality. Providing negative feedback in a way that is not discouraging is difficult for me. Rejecting PRs makes me feel guilty. The fear of missing something in a review paralyzes me. Going back and forth over minor but important-to-me details makes me self-conscious. Instead of dealing with these feelings, I will instead avoid dealing with PRs for as long as possible, leading to frustration for all parties involved. Ultimately, most PRs require a certain level of mentorship, and I am not a mentor.

  • Most code contributions are one-offs, transferring the burden of maintainership to the project owner. In the best case, this burden is no worse than if I'd written the code myself. In the worst case, a change was accepted begrudgingly so as not to offend the author and is now causing an additional burden.

Finally, I consider my projects to be works of craftsmanship, making them deeply personal things. Accepting code contributions would feel akin to letting someone take a chip out of a work-in-progress wooden chair, or letting someone add to your painting.