| recommended in similar situation: https://macwright.com/sites/polite.technology/preview Emotional labor can be challenging; it requires consistently crafting polite responses. And .. managing expectations .. "EXPECTATIONS Acquiring open source software usually doesn't involve any payment. There's no contract between you and your users, or between you and the people whose software you use. But the buyer/seller relationship we have in everyday life automatically carries over into this world. People have expectations that software will work, that issues with software will quickly be fixed, and that you'll answer their questions. This relationship is often the hardest part of software because it as some similarity with traditional buyer / seller relationships but substantial and important differences. With no payment or contract, you can't give an angry user a refund. You can't suggest they leave your store. You'll naturally be in the most empowered place to make the improvements your users want, but how are their needs expressed and received? Of course, financial transactions aren't the only kind of value exchange. You might work on features in order to make your projects more popular, which leads to a better portfolio and reputation in the community. Reputation can lead to a better job or better positioning if you found a company. You might work on a feature in order to learn about the problem or acquire new skills. .... Responding to feature requests Once a project achieves a certain level of success, it will have users, and those users will have additional demands of the project in the form of feature requests. Experienced and empathetic users will state their feature requests precisely and kindly, but others will use an unfriendly tone or imprecise language that doesn't lend itself to a solution. - The maintainer does not owe their time to anyone - The maintainer must treat everyone with respect Ignoring the first principle will lead to burnout: there are unlimited features to be requested and limited time to implement them. The sense of obligation quickly becomes an emotional burden. Ignoring the second principle will damage the project and reduce its chances of ever attracting additional contributors, which is the only way to succeed in the long term. Maintainers are the keepers of the project principles
The goal of the software.
The scope that defines problems that the
software will try to fix and those it will not. The style of the project: which programming
practices are used, which language. The culture by which the project is managed.
Maintainers approve of changes to the software by these principles, and also manage discourse and which other contributors are allowed." |