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.
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.
I think more people need to do better at communicating better is what it comes down to.
[1] https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/perm...
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.
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.
- 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!
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.
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.
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.
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.
Edit: misread post, disregard
If there are too many issues it means that your guidelines for contributing is not clear enough.
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.
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).
The good people contribute features, bug reports, bug fixes, documentation, etc. The project wouldn't be as good as it is without them.
If some corporation with deep pockets needs support maybe they can pay but the majority of people that need support seem to be people that need everything to be free (noobs and students).
I maintain UI Bootstrap (over 12k stars on GitHub), and I have to make decisions on bugs and feature requests. I prefer erring on inaction of response if I am not sure of how to decide, and I make it a policy to close support issues on the repository.
Ultimately, if someone really cared about a particular issue, the person would make an attempt at a pull request to help contribute. I will even often help give most of the important abstract information needed for a contribution too to assist in the general implementation, but I can only do so much work for people.
I am also inclined to help bad attitude people the least - it is the quickest way for me to take longer to reapond & implement, so be nice to your friendly open source maintainers people!
That's not always true. They may not have the necessary skills. That's no excuse for laziness in reporting problems though.
Learn the necessary skill.
Dismissing users because they do not have the skills to fix every problem is absurd.
feature requests
An understated problem here is that opening an issue to create a "feature request" is seen by Github as a "contribution", one on par with actually fixing bugs.We've got people going around opening hundreds of issues for silly things like variable names in products they don't even use, presumably with the aid of some bot.
Nearly everything written in C or C++ has had a issue requesting the build system use autoconf, an issue requesting the use of CMake and a issue declaring scons is the best. Even if you liked all these tools, it would be absurd to satisfy all three requesters.
None of these people are "contributing" in the way someone fixing a bug is.
Something like 70% of every issue/email I've ever received could easily be auto replied with "please provide version, platform, code to reproduce, etc.." the number of people that will post an issue that just says "it doesn't work" or "how do you do X?" wears on you after awhile. The open issues for a medium sized project are (I consider) a metric of the project's overall health. So, if you want to keep your tracker clean, you've gotta put on your administrative hat and spend time grooming things, which takes an energy toll. Developing is fun, fixing real issues is fun, repeatedly teaching people how to ask a useful question is not fun.
Also, pull requests can be the most stressful of all. People are extremely entitled about pull requests. The number of reasons why something might not get merged in right away or at all is _massive_ (and often simple: I'm busy). However, a lot of people seem to take it as personal attack that their glorious work was not immediately commented on/reviewed/liked/pulled/etc..
All of that can add up to a lot of stress around a project from which you draw no income.
Have you considered creating an FAQ?
> Something like 70% of every issue/email I've ever received could easily be auto replied with "please provide version, platform, code to reproduce, etc.."
Github has issue templates now. This could fix at least some of these incomplete submissions.
For me, we have a FAQ, "man" pages, on-line web documentation, and documentation in the config files. There will always be some idiot who is incapable of reading any documentation.
My personal favorite is a debugging error messages which is something like:
Failed reading file X: no permissions. Please check that file X is owned by user U and writeable by group G"
People post such messages to the mailing list about once a month, asking "What does that mean?"
There is no good answer which will satisfy them. If you tell them that the message is self-explanatory, they get mad at you for not explaining it. If you ignore there messages, they re-post repeatedly, asking "Why doesn't anyone help me?"
There's a subset of people who just shouldn't be using software.
I've closed two github accounts (and 4~5 related projects on each) because, well, all the stuff you say. I'm happy to toss something out there, documented, and let people do with it what they will - but supporting stuff in someone else's use case is not part of my agreement with the universe.
I am assuming it refers to https://help.github.com/articles/blocking-a-user-from-your-o...
My solution? Bypass that lock screen. It's not an issue for enough people to be worth me bothering them about it, if it was then it would have a fix already.