6 ms·

> We can get demotivated, uncertain, depressed even by negative reactions or interactions, and it can lead to developers stepping away from the project, taking

> We can get demotivated, uncertain, depressed even by negative reactions or interactions, and it can lead to developers stepping away from the project, taking a break or even leaving for good. It truly is a struggle. I have a couple of projects with moderate numbers of users, and between the "it doesn't work" private messages (not even mentioning which project) and some abusive and entitled users, I do wonder sometimes what would be the best way to protect ourselves as maintainers of open source projects. There are of course sensible users whom I truly appreciate, though encouraging messages are easily drowned out by low quality support requests and negative interactions. We may step away for a while or cut off communication channels in order to heal, but I don't see a real solution to this problem, other than to delegate tasks so that abuse is spread out evenly between a team of maintainers.

rorykoehler 8y ago
Add a don't be a dick clause to the license and revoke the keys of anyone who is.
- dessant 8y ago
  That can be cathartic, but normalizing hostility towards users will ultimately hurt both you and your project. There are no winners in this context once you decide to draw your weapon.
  - otikik 8y ago
    On the other hand, letting people use the project forums to vent, or to attack others users, or attempting to hoard the devs' attention, will create its own set of problems. I'd say 1 or 2 polite warnings are due (everyone can have a bad day). If the misbehavior continues, take out the banhammer. Use it judiciously but decisively.
  - Goronmon 8y ago
    That can be cathartic, but normalizing hostility towards users will ultimately hurt both you and your project. Does it? In ways that are worse than what the devs are dealing with as mentioned in the OP? That sounds like a pretty big assumption to me.
  - myself248 8y ago
    Normalizing hostility towards devs is already harmful. Why not take steps to reverse that?
  - rorykoehler 8y ago
    It's not about winning or losing, it's about setting healthy boundaries. No one owes anyone anything but if you are giving the fruits of your hard work away for free you get to set the rules. I have fired clients who were being dicks before and they were paying me good money. This is no different.
peterwwillis 8y ago
You get to decide how much support you're going to give, and what kind of access. The easier access people have to you, the more they're going to share their frustrations and start demanding things. My first suggestion is to limit access. Only provide a mailing list e-mail address, so people know their comments are going to be public, and they have to subscribe to it and craft an e-mail. Second I'd suggest you provide your users with clear expectations of use and support. Tell them you're not producing it for them, but for you, so you're not going to take feature requests, but you are open to suggestions. Tell them you aren't responsible if they can't get it working, but you are open to legitimate bug reports. Provide a mechanism to determine bug reports such as system information dumps to spend less time troubleshooting. If people get through your filters and are still rude, there's always public shaming.
- dessant 8y ago
  I agree that this is how it should work. Though in practice issue and feature request templates are usually left there unfilled, and people will find a way to reach out on all of your social media accounts. My experience has been that the lines we draw are regularily disrespected.
  - peterwwillis 8y ago
    More and more projects are turning off GH Issues & PRs and I think it's a good practice. I think setting the expectations early and visibly may prevent some of the disrespect on social media, but private or pseudonymous amounts may help too. (Maybe all code authors should use pseudonyms, the way book authors do?)
rossdavidh 8y ago
So, it seems like there is a potential way for a non-dev user to help out with open source, here. Basically, if a person volunteers to be an intermediary, reading the feedback and distilling it down to the relevant content (stripping out the unproductive negativity), that could be useful. It would also be emotionally easier to read harsh feedback, when it's not about _your_ work, just the work of a product you use. Many open source projects have plenty of non-dev users, who cannot really help out currently, but some of them might be willing to if shown a good entry point. Again, they wouldn't be blocking the feedback, just distilling it down to the most relevant part (e.g. "your piece of sh*t update broke the f#$King feature I depend on for my work!" becomes "newest update caused a regression in this menu item"). Just an idea.
- folex 8y ago
  While the idea is good and kind, it's not as easy as it seems. That's called a support line, and it requires good understanding of the project by non-dev support. That requires to educate someone about your project, and maintain their knowledge to be up to date. That's not an easy task even in commercial projects with a team of several people, and ability to delegate, and requires a non-trivial skill of leadership. In other words, the project is very lucky to have such people. And while it sometimes happen organically, it's hard to implement this intentionally.
  - rossdavidh 8y ago
    I'm sure it's not easy, but... 1) a support line offers support to the end user, which is different; I'm talking about filtering out the emotion from the content 2) most people who could do this, do not know that they could, that there is a need, or how one would volunteer to do it 3) the same person would not have to process all feedback, just as much as they have time for; at least some of the pile of feedback would be processed by someone other than a dev 4) the non-technical nature of the person is actually helpful, because that is usually where the originator of the feedback is coming from, and the job of this person would not be to determine the fix, but only to separate content from emotionally motivated criticism
  - 8y ago
holri 8y ago
Has it been tried to offer such unproductive users paid support?
steve76 8y ago
I learn a lot when I make something, and I'm always looking to improve. It's a balance between getting work done the old way versus my real motivation is in the new better way. Identifying it helps.
maze-le 8y ago
>> I do wonder sometimes what would be the best way to protect ourselves as maintainers of open source projects. Well, some of us develop an attitude of contempt towards their userbase (the techincal illiterate and rude part of them at least). "Cannot configure? RTFM! Doesn't compile? Read the damn error messages! Outdated libs? Fork or fuck off!". It helps keeping your peace of mind, but it doesn't help the situation in any way, since we are just loading up the contempt we receive to other users (even the ones with good intentions). This is neither good for you nor for the project. So, as I am writing this I am trying to change my personal style when dealing with those issues, but it flares up fom time to time, and that never has solved any issues but created even more. I have no convincing answer as of yet, but people who don't even try to be "not-rude as default" are being pushed lower in the "to-answer" queue.
Jyaif 8y ago
> not even mentioning which project My trick to solve this problem: Include the name of the project in the email address, e.g. dessant+project1@gmail.com dessant+project2@gmail.com etc...
- dessant 8y ago
  That's a neat trick, though I only accept bug reports over GitHub, but that doesn't stop people from contacting me through any other email address or social media account they can find. The problem is not the lack of processes, but that we don't have a good way to enforce them. Even on GitHub issue templates are often ignored, and there is no option for making them mandatory. Some projects resort to accepting bug reports only through a third-party service such as Google Forms, because that supports mandatory form fields. GitHub could really step up and offer proper tools for controlling how bugs are reported.

rorykoehler 8y ago

Add a don't be a dick clause to the license and revoke the keys of anyone who is.

dessant 8y ago
That can be cathartic, but normalizing hostility towards users will ultimately hurt both you and your project. There are no winners in this context once you decide to draw your weapon.
- otikik 8y ago
  On the other hand, letting people use the project forums to vent, or to attack others users, or attempting to hoard the devs' attention, will create its own set of problems. I'd say 1 or 2 polite warnings are due (everyone can have a bad day). If the misbehavior continues, take out the banhammer. Use it judiciously but decisively.
- Goronmon 8y ago
  That can be cathartic, but normalizing hostility towards users will ultimately hurt both you and your project. Does it? In ways that are worse than what the devs are dealing with as mentioned in the OP? That sounds like a pretty big assumption to me.
- myself248 8y ago
  Normalizing hostility towards devs is already harmful. Why not take steps to reverse that?
- rorykoehler 8y ago
  It's not about winning or losing, it's about setting healthy boundaries. No one owes anyone anything but if you are giving the fruits of your hard work away for free you get to set the rules. I have fired clients who were being dicks before and they were paying me good money. This is no different.

peterwwillis 8y ago

You get to decide how much support you're going to give, and what kind of access. The easier access people have to you, the more they're going to share their frustrations and start demanding things. My first suggestion is to limit access. Only provide a mailing list e-mail address, so people know their comments are going to be public, and they have to subscribe to it and craft an e-mail. Second I'd suggest you provide your users with clear expectations of use and support. Tell them you're not producing it for them, but for you, so you're not going to take feature requests, but you are open to suggestions. Tell them you aren't responsible if they can't get it working, but you are open to legitimate bug reports. Provide a mechanism to determine bug reports such as system information dumps to spend less time troubleshooting. If people get through your filters and are still rude, there's always public shaming.

dessant 8y ago
I agree that this is how it should work. Though in practice issue and feature request templates are usually left there unfilled, and people will find a way to reach out on all of your social media accounts. My experience has been that the lines we draw are regularily disrespected.
- peterwwillis 8y ago
  More and more projects are turning off GH Issues & PRs and I think it's a good practice. I think setting the expectations early and visibly may prevent some of the disrespect on social media, but private or pseudonymous amounts may help too. (Maybe all code authors should use pseudonyms, the way book authors do?)

rossdavidh 8y ago

So, it seems like there is a potential way for a non-dev user to help out with open source, here. Basically, if a person volunteers to be an intermediary, reading the feedback and distilling it down to the relevant content (stripping out the unproductive negativity), that could be useful. It would also be emotionally easier to read harsh feedback, when it's not about _your_ work, just the work of a product you use. Many open source projects have plenty of non-dev users, who cannot really help out currently, but some of them might be willing to if shown a good entry point. Again, they wouldn't be blocking the feedback, just distilling it down to the most relevant part (e.g. "your piece of sh*t update broke the f#$King feature I depend on for my work!" becomes "newest update caused a regression in this menu item"). Just an idea.

folex 8y ago
While the idea is good and kind, it's not as easy as it seems. That's called a support line, and it requires good understanding of the project by non-dev support. That requires to educate someone about your project, and maintain their knowledge to be up to date. That's not an easy task even in commercial projects with a team of several people, and ability to delegate, and requires a non-trivial skill of leadership. In other words, the project is very lucky to have such people. And while it sometimes happen organically, it's hard to implement this intentionally.
- rossdavidh 8y ago
  I'm sure it's not easy, but... 1) a support line offers support to the end user, which is different; I'm talking about filtering out the emotion from the content 2) most people who could do this, do not know that they could, that there is a need, or how one would volunteer to do it 3) the same person would not have to process all feedback, just as much as they have time for; at least some of the pile of feedback would be processed by someone other than a dev 4) the non-technical nature of the person is actually helpful, because that is usually where the originator of the feedback is coming from, and the job of this person would not be to determine the fix, but only to separate content from emotionally motivated criticism
- 8y ago

holri 8y ago

Has it been tried to offer such unproductive users paid support?

steve76 8y ago

I learn a lot when I make something, and I'm always looking to improve. It's a balance between getting work done the old way versus my real motivation is in the new better way. Identifying it helps.

maze-le 8y ago

>> I do wonder sometimes what would be the best way to protect ourselves as maintainers of open source projects. Well, some of us develop an attitude of contempt towards their userbase (the techincal illiterate and rude part of them at least). "Cannot configure? RTFM! Doesn't compile? Read the damn error messages! Outdated libs? Fork or fuck off!". It helps keeping your peace of mind, but it doesn't help the situation in any way, since we are just loading up the contempt we receive to other users (even the ones with good intentions). This is neither good for you nor for the project. So, as I am writing this I am trying to change my personal style when dealing with those issues, but it flares up fom time to time, and that never has solved any issues but created even more. I have no convincing answer as of yet, but people who don't even try to be "not-rude as default" are being pushed lower in the "to-answer" queue.

Jyaif 8y ago

> not even mentioning which project My trick to solve this problem: Include the name of the project in the email address, e.g. dessant+project1@gmail.com dessant+project2@gmail.com etc...

dessant 8y ago
That's a neat trick, though I only accept bug reports over GitHub, but that doesn't stop people from contacting me through any other email address or social media account they can find. The problem is not the lack of processes, but that we don't have a good way to enforce them. Even on GitHub issue templates are often ignored, and there is no option for making them mandatory. Some projects resort to accepting bug reports only through a third-party service such as Google Forms, because that supports mandatory form fields. GitHub could really step up and offer proper tools for controlling how bugs are reported.