For further actions, you may consider blocking this person and/or reporting abuse
Read next
How to create and publish an NPM unscoped and scoped package with Typescript
Bruno Sartori -
Mastering System Design for Junior Engineers
Boris Burakovski -
A beginner's guide to the Nsfw-Filter model by M1guelpf on Replicate
Mike Young -
Improving Accessibility in Flutter Apps: A Comprehensive Guide
MATTHEW ADETOYESE -
Top comments (4)
While I don't disagree with any of you points, I think this misses some points of typical open source projects. Your goals are quite narrow - which is a great way to keep yourself sane. But there are many projects out there with a lot bigger scope, and where the goal is to not only satisfy your own needs, but also other's needs. If django had similar policies as you do, it probably would be way less useful to you.
I'm not saying that your scope is any less valid, I'm saying your advice doesn't apply to the projects in which people typically experience birnout. Or maybe, your advice could be framed as saying the best way to avoid burnout is to not work on a community project. Which is true, but doesn't really solve the fundamental problems of the open source community.
Or maybe, your advice could be framed as saying the best way to avoid burnout is to not work on a community project.
I fail to understand how anyone could think this is the theme of the post. Maybe I'm missing something. Care to expand?
Excellent points! While the exact boundaries vary from one project to another, setting boundaries is important. Phabricator is one major open source project I'm familiar with which exemplifies this for a large, multi-user, production-quality project.
Thanks, Jason. You are right that boundaries are important. I failed to make that stand out in the post and am planning to write about it soon.