Hacker News Reader

Comment by dessant | Hacker News Reader

> 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.

View on HN

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.

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.

They don't necessarily need full knowledge of the product or any such thing, they just need to be able to provide a sort of filter, remove anything uselessly abusive or congratulatory without value, open defects for obvious bugs with reproduction instructions and get users to dig in and provide useful details when asking questions.

Those questions can then be answered directly by them or forwarded off to a dev who will have more detail and be able to get answers faster without the drudge of dealing with the rest of it.

Personally while working at a small company and doing both support and development work, I found it helpful to simply tell customers we'd address issues "with the development team" even when that meant I was going to work on it. Drawing that line in the sand between support and development roles compartmentalize those activities and reduces the immediacy of demand from users.

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

I have help multiple roles that could be called "very technical support" - technical enough to understand the guts of a project, troubleshoot, deflect reports that are just user error, report bugs on behalf of users with extra debugging insight, etc... but not technical enough to contribute meaningfully to the source code.

That job is just as exhausting and unrewarding as any support role. There's no fucking way I would do it for free on open source software that wasn't my own creation. EDIT: Unless it was a definite path to being a core contributor to a project I was very passionate about.

In theory it's a great idea but I think in practice very few people want to do that (or anything). In the same way that non-dev users could help with translating documentation etc but very rarely do. As it happens I recently had a guy translate our documentation into Catalan and he's just started on Spanish - but it's the first time I've been offered that sort of help in 6 years.

You are no doubt correct, but I could easily believe that 1% of people would be willing to, but don't know that there is a need, or how to volunteer for it if they did. Also, a system for crowdsourcing this, with "crowd" being minimally vetted volunteers, so that maybe you can't get everything but you could do 5% of the total.

>> 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.

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.

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.

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?)

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

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.

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.

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.

Normalizing hostility towards devs is already harmful. Why not take steps to reverse that?

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.

> 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...

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.

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

Reply on news.ycombinator.com