How to be an open source gardener | Hacker News Reader

How to be an open source gardener

words.steveklabnik.com

280 pointsnkurz59 comments

1000 times yes

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)

OpenFrameworks tags the low hanging fruit issues as 'bitesize'. :)

This is a really good post, if only because it reiterates that code isn't the only way to help an open source project.

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.

+1 in doubt, err on the side of trust.

Steve, first off I respect you a lot for the work you have done. But, the elephant in the room is that when you changed jobs, you totally fell off the map with Rails: https://github.com/rails/rails/commits/master?author=stevekl...

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:

http://www.jwz.org/blog/2003/02/the-cadt-model/

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.

This article isn't about growing plants :-(

Why not write an article about that yourself? :)

I also read it thinking someone had open-sourced some gardening tips or planting layouts. Whoops.

Me too!

Here's a bunch of Arduino gardening (and other) links:

http://www.rootsimple.com/2013/03/arduino-homesteading-proje...

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.

Do they get salaries (or other consideration) commensurate with being the most valuable contributors who are worth their weight in gold?

Maybe they could get free conference passes, or an invitation to a company gathering if they are in the area.

Wondering why big project, backed by a real company that makes money don't pay someone to keep gardening?

it could help some student pay the rent and definitely will help the project...

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.

I would prefer to manage a issues page of some open source project rather than flip burgers...

Still, if the gardener is not doing a good job you can always change him/her...

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.

To be clear, I only advocate that bugs with no reproduction instructions and an unresponsive submitter be closed as stale.

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

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.

You'd need a custom DSL to tell the system how to reproduce the bug; at this point, I'm already bored, and I don't even have a bug to submit.

In theory it could be a pull request with a failing test.

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.

Oh yeah, I'm still not in favor of it as an idea, just tossing thoughts around.

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

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.

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.

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.

For Rails, sure - but most FLOSS projects are not like that.

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.

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.

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.

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.

I almost used a fork of https://github.com/nashby/jose-vs-oss for a while...

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.

I should have plugged it; Code Triage was actually directly inspired by the events in this post.

code triage is great, but I was thinking about something like ghi - https://github.com/stephencelis/ghi

I can't imagine being on the receiving side of those canned messages. In particular, beginners seeking help being told to go away.

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.

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

> I don't even know where to ask what's the expected behavior

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.

for certain projects, I like ost.io as a way of "ask me anything" to project authors. I wish something like it were more widely used however.

Thank you Steve for what you do for Rails; I admire the way you deal with it

As I mentioned in the post, I don't do this for Rails anymore, but past me says thanks. :)

Do you mean that you don't develop for Rails anymore, or just that you don't do the gardener?

I have been taking a break from most of my general open source work. I do a little bit here and there, but not as much as I used to.

Aren't you working on Rust?

I don't contribute as much _code_ as you'd think: https://github.com/mozilla/rust/commits/master?author=stevek...

How do be a little bitch.

Not one word about gardening. Fail train.

Reply on news.ycombinator.com