8 ms·

I'm the creator of a just-mildly popular OS project (~700 stars on GH) and I had to give up being the main maintainer. Too many "issues" were just people who co

I'm the creator of a just-mildly popular OS project (~700 stars on GH) and I had to give up being the main maintainer. Too many "issues" were just people who couldn't debug their own code, or "issues" where the person would describe some weird edge case but be unable to provide any example code. After enough of those, and getting busy with other things, I just couldn't keep up with it. Luckily, one of the contributors stepped up and is now the main maintainer. I still read through the issues that come in and he does a great job of responding and keeping cool. I don't know how he does it.

akerro 10y ago
I was contributing to more popular projects, between 2.5k to 4k stars on GH, I just gave up and stopped doing it for free when users just open issues like 'I requested this feature 5 months ago and it's still not implemented. what are you waiting for?', after reading 8th of such issues in 3 projects I just left all of them the same day and started working on my commercial project. Working on OSS where every idiot can open an issue for free and complain or think we're their slaves if waste of time and energy. Never. again. The worst were users or forkers who asked me to change license of a project from MIT to GPL because they would like it more... eh.
- stuaxo 10y ago
  Can always close as WONTFIX - reopen if you have a pull request in the first case ... and just WONTFIX the license changers.
  - akerro 10y ago
    Did it once. Closed an issue I couldn't reproduce and author didn't want to show me their code. I got blamed for not helping them and not fixing problems in my code :) I stopped responding to such issues at all.
    - jbrooksuk 10y ago
      I maintain Cachet [1] which has 4.4k stars on it. I've closed several issues in a similar vein, only to be ranted at for not giving a reason. I shouldn't have to explain the same reason for the fifth time when you could've searched for it already — but hey, I appreciate the thoughts. [1] https://github.com/Cachethq/Cachet https://github.com/Cachethq/Cachet
      - facorreia 10y ago
        Would it help creating a page with "common reasons for closing" and adding a note with a link to that page?
        akerro 10y ago
        More work to avoid more work?
    - deleted 10y ago
      [deleted]
    - nv-vn 10y ago
      Can't you just lock the thread?
      - RyanCavanaugh 10y ago
        My experience, having locked a thread exactly once after triaging several thousand reports on TypeScript, is that you immediately get another bug from the same person complaining about how dare you lock an issue.
        adekok 10y ago
        The solution for that is to ban the person.
        Bahamut 10y ago
        I've gotten that a few times too - sometimes the issue opener turns out to have been right. I think more people need to do better at communicating better is what it comes down to.
- panic 10y ago
  Maybe the solution is to use an issue tracker outside of GitHub. It seems like a lot of these problems come from how easy it is to make drive-by comments without really being involved in the project's community.
  - akerro 10y ago
    I moved to GitLab where I can disable issues completely or allow only specific people opening issues[1], unfortunately most projects are on GitHub. It also discourages lazy (who are usually useless) reporters from opening the issues, as they would have to create new account, 2:0 for me. [1] https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/permissions/permissions.md https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/perm...
  - tobias3 10y ago
    Altassian JIRA (cloud or self-hosted) is free for Open Source projects. You can add as many required fields as you want and make creating issues as complicated as necessary :)
- Vexs 10y ago
  A pretty good example of this is the recent opening of Fallout 4 mods to Xbox users- almost overnight mod makers were spammed pretty much everywhere with demands to stick it on xbox, do this, do that, etc. Lots of bad blood.
- ryandrake 10y ago
  A maintainer of an open source project, or really anyone who has a public-facing role online, needs to develop a thick skin and be able to ignore griefers and trolls. Ask anyone who works retail or customer support how horrible people can be. Now multiply that by 10 for people online.
- greggman 10y ago
  This actually makes me wonder if open source is the right thing for many projects. For a project that other engineers will use it seems to make sense. Other engineers (or some percentage of them) can contribute. But certain projects really target non-engineering types. I don't mean that in any judgmental way. Only trying to distinguish between those who will need a ton of hand holding and are unlikely to contribute back and those the have a higher percentage of contributing directly back the the project. Off the top of my head the creative coding community is full of artists who've learned just enough code to be able to glue things together and make cool art but not enough to contribute to the things they are gluing together. They generally fit the profile of "starving artist" or student. The game dev community is also going that direction because several projects have made it simpler to be able to create a game with very little programming skills. I'm not sure what my point is other than if you make one of those types of projects you're going to get pleads for help from people that probably can't construct a pull request. Not sure how to fix that.
  - cyphar 10y ago
    > This actually makes me wonder if open source is the right thing for many projects. This is why the term "open source" is confusing, and I'm annoyed when people use it. If you're referring to software freedom, free software is necessary for a free society. If you're referring to the bazaar model of development, then I agree that some projects don't need to work that way. What's important in free software is that there can be a community of users, but it doesn't matter if the original developers decide to be part of that community.
FLUX-YOU 10y ago
Has anyone tried a non-profit model for open source? That workload is more than some full-time jobs.
- afarrell 10y ago
  The Django Software Foundation supports someone named Tim who plays a role in release engineering and bug triage.
  - piquadrat 10y ago
    It's called the Django Fellowship Program and you can help fund it here: https://www.djangoproject.com/fundraising/ https://www.djangoproject.com/fundraising/ Tim is doing an absolutely marvellous job managing releases, reviewing pull requests, and a plethora of other work. Any Django user who can afford it (and especially companies that profit from Django) should think about donating to keep the Fellowship going. It's a great investment.
- colejohnson66 10y ago
  Besides Red Hat? Edit: misread post, disregard
  - thinkmassive 10y ago
    Red Hat is for-profit
adekok 10y ago
Having maintained an Open Source project for almost 20 years now, there are some ways to deal with bad users. One is to not take it personally. Annoying people should get ignored or banned. They're just not worth the effort. Two, is to recognize that your time is limited. If the person filing the bug can't (or won't) help track it down, well... too bad. Maybe no one else runs into the bug, and your best response is "works for me". (Note that this is the approach taken by most commercial software vendors in my experience) Three, is to recognize that there are idiots out there, and you can't help them all. It's OK to be on the lower end of the bell curve, but sometimes it's like the kids rides: "You have to be THIS TALL to go on this ride". If the user can't comprehend something, perhaps he shouldn't be using it. And perhaps you shouldn't waste your time trying to get him to understand something he just can't understand. My general approach is to be nice to people who ask good questions, and who try. When people ask terrible questions, and make it clear that they have no interest in lifting a finger, but demand that you do all of the work... well... they get told in no uncertain terms to shape up, or get banned. You don't owe these people anything. If they had an ounce of human decency, they would understand that they got the software for free, and that they don't deserve anything. And that they need to put some effort into it on their end. The main response I have with these people is If you're too lazy to help solve the problem, then I'm too lazy to help, too.
- impostervt 10y ago
  20 years? Man. There are Saints that had less patience than that.
- specialist 10y ago
  Could you charge for support? Can you offer consulting services? H2 (h2database.com), one of my favorite projects, accepts donations. A close friend created a reasonably popular web framework. Books, conventions, etc. He got some good consulting gigs and paid travel. He regrets he didn't pursue that more (others stepped up to fill the void).
  - adekok 10y ago
    Yes, I charge for support and consulting. But the Open Source side has huge value. Even if that includes the occasional whiner. The good people contribute features, bug reports, bug fixes, documentation, etc. The project wouldn't be as good as it is without them.
nemild 10y ago
I liked Github's new feature that prefills in the New Issue with the instructions. Maybe that cuts down on poorly specified issues? Separately, was there ever demand for charging for non-standard support, a la Red Hat? I don't mean for those highlighting bugs, but for people who wanted more basic help. The world needs more open source and open source developers, and I wonder if models like that are both compatible with OSS and provide some support resources for the developer.
- RyanCavanaugh 10y ago
  Anecdotally, we added a template to the TypeScript issue form. Our stats (duplicate / not repro / just a question) didn't move at all. Our template had a sample version number in it that the logger was supposed to replace with the actual version number; that nightly-changing version number exists in 63 issues. People still log bugs with literally identical titles to existing issues. People still log bugs with repros that don't display the behavior they're describing. People log bugs that are obviously just questions, which the template asks them not to do. I don't think there's a fix here. Fundamentally you're asking someone to do work that they can, at no social cost, offload to someone else. I would love to try a model where it costs $1 to log an issue and the maintainer can give you back the dollar at their discretion.
  - eric-hu 10y ago
    Stack Overflow and Discourse both have a feature to search for related titles when posting a new topic. I've yet to see this in a big tracker.
nolanl 10y ago
Some advice I would give to open-source maintainers, based on my own experience and also advice I've received from veterans: - take breaks. go AWOL for 2 weeks. it clears the mind - ask the user to provide a test case to reproduce. if they cannot, close the issue after a month or so - mark issues as "needs test case" or "has test case" - use email instead of GitHub notifications. mark as read, labels, folders, etc. are all invaluable - if some user is abusive, cut them out immediately (e.g. ban them from the GitHub org) - do a little bit every day so you don't become overwhelmed - set up automated tests that run for every PR. projects without tests are impossible to maintain. Good luck!
- Buttons840 10y ago
  I wish GitHub had a "close in one week unless there are further comments" button. Maybe make the time adjustable. That way, if someone submits an inadequate bug report you can ask for more details and then tell the ticket to auto-close if nobody responds in time. I'm sure you could do this with a 3rd party tool and the GitHub API.
fagnerbrack 10y ago
> Too many "issues" were just people who couldn't debug their own code If there are too many issues it means that your guidelines for contributing is not clear enough.

akerro 10y ago

I was contributing to more popular projects, between 2.5k to 4k stars on GH, I just gave up and stopped doing it for free when users just open issues like 'I requested this feature 5 months ago and it's still not implemented. what are you waiting for?', after reading 8th of such issues in 3 projects I just left all of them the same day and started working on my commercial project. Working on OSS where every idiot can open an issue for free and complain or think we're their slaves if waste of time and energy. Never. again. The worst were users or forkers who asked me to change license of a project from MIT to GPL because they would like it more... eh.

stuaxo 10y ago
Can always close as WONTFIX - reopen if you have a pull request in the first case ... and just WONTFIX the license changers.
- akerro 10y ago
  Did it once. Closed an issue I couldn't reproduce and author didn't want to show me their code. I got blamed for not helping them and not fixing problems in my code :) I stopped responding to such issues at all.
  - jbrooksuk 10y ago
    I maintain Cachet [1] which has 4.4k stars on it. I've closed several issues in a similar vein, only to be ranted at for not giving a reason. I shouldn't have to explain the same reason for the fifth time when you could've searched for it already — but hey, I appreciate the thoughts. [1] https://github.com/Cachethq/Cachet https://github.com/Cachethq/Cachet
    - facorreia 10y ago
      Would it help creating a page with "common reasons for closing" and adding a note with a link to that page?
      - akerro 10y ago
        More work to avoid more work?
  - deleted 10y ago
    [deleted]
  - nv-vn 10y ago
    Can't you just lock the thread?
    - RyanCavanaugh 10y ago
      My experience, having locked a thread exactly once after triaging several thousand reports on TypeScript, is that you immediately get another bug from the same person complaining about how dare you lock an issue.
      - adekok 10y ago
        The solution for that is to ban the person.
      - Bahamut 10y ago
        I've gotten that a few times too - sometimes the issue opener turns out to have been right. I think more people need to do better at communicating better is what it comes down to.
panic 10y ago
Maybe the solution is to use an issue tracker outside of GitHub. It seems like a lot of these problems come from how easy it is to make drive-by comments without really being involved in the project's community.
- akerro 10y ago
  I moved to GitLab where I can disable issues completely or allow only specific people opening issues[1], unfortunately most projects are on GitHub. It also discourages lazy (who are usually useless) reporters from opening the issues, as they would have to create new account, 2:0 for me. [1] https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/permissions/permissions.md https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/perm...
- tobias3 10y ago
  Altassian JIRA (cloud or self-hosted) is free for Open Source projects. You can add as many required fields as you want and make creating issues as complicated as necessary :)
Vexs 10y ago
A pretty good example of this is the recent opening of Fallout 4 mods to Xbox users- almost overnight mod makers were spammed pretty much everywhere with demands to stick it on xbox, do this, do that, etc. Lots of bad blood.
ryandrake 10y ago
A maintainer of an open source project, or really anyone who has a public-facing role online, needs to develop a thick skin and be able to ignore griefers and trolls. Ask anyone who works retail or customer support how horrible people can be. Now multiply that by 10 for people online.
greggman 10y ago
This actually makes me wonder if open source is the right thing for many projects. For a project that other engineers will use it seems to make sense. Other engineers (or some percentage of them) can contribute. But certain projects really target non-engineering types. I don't mean that in any judgmental way. Only trying to distinguish between those who will need a ton of hand holding and are unlikely to contribute back and those the have a higher percentage of contributing directly back the the project. Off the top of my head the creative coding community is full of artists who've learned just enough code to be able to glue things together and make cool art but not enough to contribute to the things they are gluing together. They generally fit the profile of "starving artist" or student. The game dev community is also going that direction because several projects have made it simpler to be able to create a game with very little programming skills. I'm not sure what my point is other than if you make one of those types of projects you're going to get pleads for help from people that probably can't construct a pull request. Not sure how to fix that.
- cyphar 10y ago
  > This actually makes me wonder if open source is the right thing for many projects. This is why the term "open source" is confusing, and I'm annoyed when people use it. If you're referring to software freedom, free software is necessary for a free society. If you're referring to the bazaar model of development, then I agree that some projects don't need to work that way. What's important in free software is that there can be a community of users, but it doesn't matter if the original developers decide to be part of that community.

FLUX-YOU 10y ago

Has anyone tried a non-profit model for open source? That workload is more than some full-time jobs.

afarrell 10y ago
The Django Software Foundation supports someone named Tim who plays a role in release engineering and bug triage.
- piquadrat 10y ago
  It's called the Django Fellowship Program and you can help fund it here: https://www.djangoproject.com/fundraising/ https://www.djangoproject.com/fundraising/ Tim is doing an absolutely marvellous job managing releases, reviewing pull requests, and a plethora of other work. Any Django user who can afford it (and especially companies that profit from Django) should think about donating to keep the Fellowship going. It's a great investment.
colejohnson66 10y ago
Besides Red Hat? Edit: misread post, disregard
- thinkmassive 10y ago
  Red Hat is for-profit

adekok 10y ago

Having maintained an Open Source project for almost 20 years now, there are some ways to deal with bad users. One is to not take it personally. Annoying people should get ignored or banned. They're just not worth the effort. Two, is to recognize that your time is limited. If the person filing the bug can't (or won't) help track it down, well... too bad. Maybe no one else runs into the bug, and your best response is "works for me". (Note that this is the approach taken by most commercial software vendors in my experience) Three, is to recognize that there are idiots out there, and you can't help them all. It's OK to be on the lower end of the bell curve, but sometimes it's like the kids rides: "You have to be THIS TALL to go on this ride". If the user can't comprehend something, perhaps he shouldn't be using it. And perhaps you shouldn't waste your time trying to get him to understand something he just can't understand. My general approach is to be nice to people who ask good questions, and who try. When people ask terrible questions, and make it clear that they have no interest in lifting a finger, but demand that you do all of the work... well... they get told in no uncertain terms to shape up, or get banned. You don't owe these people anything. If they had an ounce of human decency, they would understand that they got the software for free, and that they don't deserve anything. And that they need to put some effort into it on their end. The main response I have with these people is If you're too lazy to help solve the problem, then I'm too lazy to help, too.

impostervt 10y ago
20 years? Man. There are Saints that had less patience than that.
specialist 10y ago
Could you charge for support? Can you offer consulting services? H2 (h2database.com), one of my favorite projects, accepts donations. A close friend created a reasonably popular web framework. Books, conventions, etc. He got some good consulting gigs and paid travel. He regrets he didn't pursue that more (others stepped up to fill the void).
- adekok 10y ago
  Yes, I charge for support and consulting. But the Open Source side has huge value. Even if that includes the occasional whiner. The good people contribute features, bug reports, bug fixes, documentation, etc. The project wouldn't be as good as it is without them.

nemild 10y ago

I liked Github's new feature that prefills in the New Issue with the instructions. Maybe that cuts down on poorly specified issues? Separately, was there ever demand for charging for non-standard support, a la Red Hat? I don't mean for those highlighting bugs, but for people who wanted more basic help. The world needs more open source and open source developers, and I wonder if models like that are both compatible with OSS and provide some support resources for the developer.

RyanCavanaugh 10y ago
Anecdotally, we added a template to the TypeScript issue form. Our stats (duplicate / not repro / just a question) didn't move at all. Our template had a sample version number in it that the logger was supposed to replace with the actual version number; that nightly-changing version number exists in 63 issues. People still log bugs with literally identical titles to existing issues. People still log bugs with repros that don't display the behavior they're describing. People log bugs that are obviously just questions, which the template asks them not to do. I don't think there's a fix here. Fundamentally you're asking someone to do work that they can, at no social cost, offload to someone else. I would love to try a model where it costs $1 to log an issue and the maintainer can give you back the dollar at their discretion.
- eric-hu 10y ago
  Stack Overflow and Discourse both have a feature to search for related titles when posting a new topic. I've yet to see this in a big tracker.

nolanl 10y ago

Some advice I would give to open-source maintainers, based on my own experience and also advice I've received from veterans: - take breaks. go AWOL for 2 weeks. it clears the mind - ask the user to provide a test case to reproduce. if they cannot, close the issue after a month or so - mark issues as "needs test case" or "has test case" - use email instead of GitHub notifications. mark as read, labels, folders, etc. are all invaluable - if some user is abusive, cut them out immediately (e.g. ban them from the GitHub org) - do a little bit every day so you don't become overwhelmed - set up automated tests that run for every PR. projects without tests are impossible to maintain. Good luck!

Buttons840 10y ago
I wish GitHub had a "close in one week unless there are further comments" button. Maybe make the time adjustable. That way, if someone submits an inadequate bug report you can ask for more details and then tell the ticket to auto-close if nobody responds in time. I'm sure you could do this with a 3rd party tool and the GitHub API.

fagnerbrack 10y ago

> Too many "issues" were just people who couldn't debug their own code If there are too many issues it means that your guidelines for contributing is not clear enough.