alecodes/void
2
0
Fork 0
Code Issues 9 Pull requests Projects Releases Packages Wiki Activity Actions

Add initial readwise import

Browse source
This commit is contained in:
Alexander Navarro 2024-09-04 19:32:48 -04:00
parent 16d9567fc6
commit 409432969f
41 changed files with 1267 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

41
Readwise/Best Practices for Maintainers.md Normal file
View file

@ -0,0 +1,41 @@
# Best Practices for Maintainers
![rw-book-cover](https://opensource.guide/assets/images/cards/best-practices.png)
## Metadata
- Author: [[Open Source Guides]]
- Full Title: Best Practices for Maintainers
- Category: #articles
- Document Tags: [[dev]]
- URL: https://opensource.guide/best-practices/
- Archive: https://web-archive.alecodes.page/bookmarks?bf=1&search=&title=Best%20Practices%20for%20Maintainers
> [!tldr]
> Maintaining a popular open source project involves more than just coding; it requires effective communication and managing contributions. It's important to set clear expectations for your time and the types of contributions you accept, while also being kind and responsive to contributors. Taking breaks and prioritizing your own happiness is essential for the long-term success of the project.
## Highlights
Written and enforced fairly, however, good rules empower maintainers. They prevent you from getting dragged into doing things you don’t want to do. [View Highlight](https://read.readwise.io/read/01j59endsw1rpkb9tf8m8qawvj))
Don’t forget to document your interactions, too. Wherever you can, keep communication about your project public. If somebody tries to contact you privately to discuss a feature request or support need, politely direct them to a public communication channel, such as a mailing list or issue tracker. [View Highlight](https://read.readwise.io/read/01j59eq13dn3wga93d01tnfqmy))
Having everything written down, however, helps depersonalize situations when you do need to enforce your rules.
Saying no isn’t fun, but *“Your contribution doesn’t match this project’s criteria”* feels less personal than *“I don’t like your contribution”*. [View Highlight](https://read.readwise.io/read/01j59eskv2qw7f8cfrkz5g3rvt))
The key to handling support for large-scale open source projects is to keep issues moving. Try to avoid having issues stall. If you’re an iOS developer you know how frustrating it can be to submit radars. You might hear back 2 years later, and are told to try again with the latest version of iOS. [View Highlight](https://read.readwise.io/read/01j59ezaxynf5z61amr95w7x7m))
I cater to the 80% use case. If you are one of the unicorns, please fork my work. I won’t get offended! My public projects are almost always meant to solve the most common problems; I try to make it easy to go deeper by either forking my work or extending it. [View Highlight](https://read.readwise.io/read/01j59ftzzkh4m5fkbbgse1qs8y))
It’s almost inevitable that once a project becomes big, maintainers have to become a lot more conservative about how they introduce new code. You become good at saying “no”, but a lot of people have legitimate needs. So, instead you end up converting your tool into a platform. [View Highlight](https://read.readwise.io/read/01j59fw4nd6sjdfxwtxgbn89zy))
I believe that tests are necessary for all code that people work on. If the code was fully and perfectly correct, it wouldn’t need changes – we only write code when something is wrong, whether that’s “It crashes” or “It lacks such-and-such a feature”. And regardless of the changes you’re making, tests are essential for catching any regressions you might accidentally introduce. [View Highlight](https://read.readwise.io/read/01j59fyszkgtfzj58msft420j5))
There are a [variety of tools available](https://github.com/showcases/tools-for-open-source) to help automate some aspects of maintenance work. A few examples:
• [semantic-release](https://github.com/semantic-release/semantic-release) automates your releases
• [mention-bot](https://github.com/facebook/mention-bot) mentions potential reviewers for pull requests
• [Danger](https://github.com/danger/danger) helps automate code review
• [no-response](https://github.com/probot/no-response) closes issues where the author hasn’t responded to a request for more information
• [dependabot](https://github.com/dependabot) checks your dependency files every day for outdated requirements and opens individual pull requests for any it finds [View Highlight](https://read.readwise.io/read/01j59g05hnrn42hj1ey8s0cjhe))
Burnout is a real and pervasive issue in open source work, especially among maintainers. As a maintainer, your happiness is a non-negotiable requirement for the survival of any open source project. [View Highlight](https://read.readwise.io/read/01j59g44y47gfp6bexny1cf077))
In maintaining WP-CLI, I’ve discovered I need to make myself happy first, and set clear boundaries on my involvement. The best balance I’ve found is 2-5 hours per week, as a part of my normal work schedule. This keeps my involvement a passion, and from feeling too much like work. Because I prioritize the issues I’m working on, I can make regular progress on what I think is most important. [View Highlight](https://read.readwise.io/read/01j59g63w7h9j6krg5wpjh40ap))