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)
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.
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.
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:
Here's a bunch of Arduino gardening (and other) links:
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.
it could help some student pay the rent and definitely will help the project...
Still, if the gardener is not doing a good job you can always change him/her...
The oldest open bug in Rails is three years old, and even says "This has been around a while" in the description. https://github.com/rails/rails/issues/1769
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.
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.
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
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.
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.
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.
What i am saying is: Half-automated is better than manual.
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.
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.
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.
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 still don't know how to do it in open source tho. In private companies that's what support technicians are for, they triage and they do the 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).
Yup, this part can be super bad. This is why I'm happy CONTRIBUTING.md exists on GitHub, and why they show it whenever a new issue is opened.