For PouchDB (gardeners welcome - https://github.com/pouchdb/pouchdb), 90% of my time is between triaging issues and setting up infrastructure for contributions (mostly working on tests / CI).
Sometimes every few days, at least every week I sit and go through all the issues, try and figure out whats needed to close out the old issues, a good percentage of the bugs are ones that need someone to investigate and produce a clear set of steps to reproduce.
Actually after reading I am gonna start tagging these ones specifically for new contributors.
Not only that. It also shows that a project needs to invite help.
A helper who wants to do something like like this does not necessarily need to code a lot (even though it is of course necessary to have basic programming knowledge to triage bugs). But he needs extensive rights in the issue tracker, so that he can tag and close and comment with authority, and the other developers need to respect that work. Something like that won't appear out of thin air, something like that needs a process, the possibility to build up trust, and an invitation.
This is something important that I forgot: GitHub's permissions are such that you need to have commit to truly do this job effectively. For Rails, this means that the issue team has commit on GitHub, but isn't actually allowed to commit. It hasn't been a significant problem.
I would have done the same thing, getting into to Rust, etc. after the job transition, as you have other things to focus on. However, you mentioned Rails, and I think this is an opportunity to talk about "leaving the garden".
I have a few projects I had enjoyed working on, but when I left the old job, I was stuck with those projects and no one wanted to take them on- I tried to find help, but it was temporary- no one has taken over. Do you or others have suggestions for successfully abandoning a project, because I can't seem to, and those projects languish with the lack of effort I put into them because it is so infrequent, but I do just enough apparently to keep others from thinking I've abandoned them.
> Was this issue for an older version of Rails than is currently supported? If so, copy/paste an answer I wrote that asks if anyone knows if this affects a supported version of Rails.
No. Please do not do this blindly. It is very discouraging for the bug reporter to see their bug being ignored for a few releases, followed by this response. Example:
I know it's discouraging, but sometimes, bugs get fixed as an accident of another change, or the feature was removed, or a variety of other things. Leaving it sit open with no movement at all is even _more_ discouraging.
The bug reporter reported a legitimate bug. It lies on you to act on this information. If you ignore the bug and make other random changes to the code, it still is your responsibility to fix the bug - the fact that you made it harder to find the bug by altering the code is entirely your own doing. It does not fall upon the bug reporter to test your code for bugs for every change you make. To demand this, and to close the bug when they do not comply, is entirely the wrong thing to do.
I'd suggest checking out http://growstuff.org/ to get your fill of more literal open source gardening! It's a neat project: "Growstuff is a community of food gardeners. We're building an open source platform to help you learn about growing food, track what you plant and harvest, and swap seeds and produce with other gardeners near you."
Well said Steve, we have 500+ issues on Docker and are going through the same process.
The most valuable contributors are those who show up day after day and are not afraid of repetitive and unglamorous tasks. Those are worth their weight in gold.
If you don't "want" to take up this unglamorous task, and keep at it day after day at a high quality, the work will inevitably gradually slide to lower and lower quality.
Sorry to be contrarian, but bug reports aren't weeds. The count of open bugs on a project is just a number and it doesn't matter if it is large or small. Closing bugs that never should have been opened in the first place is of course great, but many times the bug report is open because it is a tricky issue to solve. You cant just mark old bugs as "stale" and close them and hope that the bug is fixed in a newer version of the software.
Maybe i am naive, but i think this screams for a system which enforces reproducing of bugs.
1. Bug is filed
2. System checks if bug is reproducible
3. As long as the bug is not reproducible it is hidden in the issue tracker and flagged as "needs reproducibility" and emails are sent to the creator. After a given time the bug is closed automatically.
4. When the testcase to reproduce the bug is provided, the build system checks against the current supported versions. If it passes, the bug is fixed as "needs reproducibility" again, if it fails, the bug is finally pushed to the main issue tracker.
I can see how brutal this approach is, but this way, the number of bugs is kept to a minimum. Bug filers, who actually take the time will therefore have a high probability of immediate fixing. Motivated people can always play gardener additionally, but without the email spam, they can simply help in one step of the process.
I don't think this would have helped us a lot on Go.
We occasionally get reports like "We're seeing [issue] on our system, but only when it's loaded with production traffic." Some bugs are simply impossible to reproduce in an isolated, mechanical way. (Or at least very hard for people who aren't totally familiar with the project.)
But often one of the core will take a look at those reports and say "Aha! That must be a consequence of [some change we made]." Then they investigate, poke at some of their code, check their assumptions, and eventually find the cause.
Another large class of bugs pertains to docs, for which the concept of "reproducibility" is irrelevant.
This is pretty contradictory to 1. my motivations as a maintainer, 2. how to solve (imo) the barriers in having people contribute to OSS
1. As a maintainer I want my project to work, if a reporter only wants to give a brief description then I am both happy and have the context in order to read it, attempt to understand it and ask the relevant follow up questions. Ideally someone turns up with a test case and patch and I will make that as easy as I can, but its not a requirement for being able to contribute.
2. I did a questionnaire on what prevents people contributing to open source, by far the biggest barriers I found were things that were solved by asking a quick question to a maintainer, people get stuck on what to fix, or how to set stuff up and they want to ask a person and not a mailing list or a chat room, and certainly not a robot policing their filed bugs
That sounds like a good process for smaller projects. For larger projects, or projects where developer attention is a precious resource, not so much. For example, look at the detail provided by the issue submitter to the nouveau (open source Nvidia Linux driver) project: https://bugs.freedesktop.org/show_bug.cgi?id=76732
Not only is there a lot of log output, the submitter took the trouble to run git bisect on the Linux kernel to see at which point the breakage occurred. I'm sure the submitter spent quite a bit of time and has a high level of familiarity with the project and related tools. This will help developers to isolate the problem and provide a quick fix. Without this level of detail, the issue might never get fixed.
Thats the point, ultra motivated contributors will do this, semi motivated contributors can be coached into it, people that just want their stuff to work may not, but all of it is useful, putting a barrier in front of that is wasting developers time.
And I am not speaking solely about small projects, I experience exactly the same thing while working on Firefox OS, at nearing a million 'issues' its definitely not small.
> I can see how brutal this approach is, but this way, the number of bugs is kept to a minimum.
Right, this is the problem I see here. Some people will just drop off entirely in this case, which may or may not be what your project wants. And some people give great reproducible steps, even if they aren't already automated: "Run 'rails new foo', then add this controller <code>, then hit the page and you'll see 1 instead of 2." The system would reject that, even though it has instructions to reproduce.
Bookkeeping software tries to catch all payments and decides which invoice was paid. If the identification misses, they can try to match by other indicators (Name etc.). Some payments slip through the system and a person looks after it.
What i am saying is: Half-automated is better than manual.
There are tons of bugs which are easy to describe in prose, and for which such an explanation can easily allow someone familiar with the codebase to be able to reproduce or even fix it right off the bat, but which would be quite difficult or even impossible to create an automated test for that could reproduce it in a way that the bug tracker could check.
It might be nice for bugtrackers to offer an optional system that allows you to submit an automated test case, which could be run in some kind of sandbox, and bugs that were easily reproducible would be marked as such and could get more attention. But anything that simply discarded all other bugs would be throwing the baby out with the bathwater; you would simply not hear from your users as much, on lots of important issues.
You are essentially advocating that reporters write a test script with each bug filed. During the process, of course, this makes sense, but it may not work right away because coming up with a solid repro can be a challenge. And not all users of all projects will be coders able to write test scripts. OTOH that is a fine job for a somebody taking on the role of triage / "gardener".
I think rails users, who are able to find a bug in rails are also able to write a test for it.
A GUI system, which allows you to make the system do the stuff which causes the bug and records the steps would be great, but i fear most software is to complex and special to come up with a useful system.
Tests generated by GUI systems are extremely fragile and you wouldn't them hanging around your codebase.
OTOH, often a video recording is a great way to demonstrate a bug without having to (be able to) write an automated test, and pretty easy for even a non-technical user to produce.
That's still quite a bit of work - there are some projects I'd do that for, but if (for instance) an IRC bot was having an issue, I doubt I'd bother if submitting a bug required writing a new test, and submitting a PR.
This only works for bugs which are easy to reproduce automatically and on all hardware. Your system would completely block a lot of bugs in linux (e.g. https://bugzilla.kernel.org/show_bug.cgi?id=68761). For some projects this might not be so ridiculous but you're still raising the barrier to bug reports and so you're going to miss bugs. I don't think a manual process is all that difficult unless you have an especially large and/or vocal userbase.
I enjoyed reading this. I can relate to the point about reading open issues of a project to know exactly what state the project is in and where it is going.
While I don't actively participate in many open source projects, I have found myself reading the mailing lists and watching the issue trackers for a few projects over the past few months and as a result I feel that I have a very good idea of what is going on with them.
I expected some command line tool for github instead of manual navigation through 800 issues. This way he could have saved batches of issues, neatly organized in a directory structure suiting his needs.
Check out www.codetriage.com (albeit not CLI). In any case it sounds like you have a great angle for a fresh approach to the issue, maybe using the GitHub API.
If you submitted a bug report on Stack Overflow, they'd tell you to file it on the bug tracker instead. GitHub issues are a terrible way to teach someone how to use a project.
That's the expert point of view. But when you're learning a technology, you don't know what's the expected behavior, where's the problem (your code or the lib) and if you understood the spirit correctly, so you don't know where the problem is, you just need an expert pair of eyes to make sense of things. So you get kicked out of SO for lack of point-worthy question, and of github for lack of repro.
Moreover some projects do their support on github (not saying it's good or bad, just confusing).
I've had that recently, I don't even know where to ask what's the expected behavior (google chrome APIs, impossible to reach a human being).
For PouchDB (gardeners welcome - https://github.com/pouchdb/pouchdb), 90% of my time is between triaging issues and setting up infrastructure for contributions (mostly working on tests / CI).
Sometimes every few days, at least every week I sit and go through all the issues, try and figure out whats needed to close out the old issues, a good percentage of the bugs are ones that need someone to investigate and produce a clear set of steps to reproduce.
Actually after reading I am gonna start tagging these ones specifically for new contributors.
Even as someone who considers myself very reactive to bug reports etc, its very easy to let it slip (https://twitter.com/daleharvey/status/451378807006838784)