
How to be an open source gardener - nkurz
http://words.steveklabnik.com/how-to-be-an-open-source-gardener
======
daleharvey
1000 times yes

For PouchDB (gardeners welcome -
[https://github.com/pouchdb/pouchdb](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](https://twitter.com/daleharvey/status/451378807006838784))

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

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

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

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

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

------
dsfadadsffd
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...](https://github.com/rails/rails/commits/master?author=steveklabnik)

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.

------
teddyh
> _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/](http://www.jwz.org/blog/2003/02/the-cadt-model/)

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

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

------
orasis
This article isn't about growing plants :-(

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

~~~
awor
Me too!

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

[http://www.rootsimple.com/2013/03/arduino-homesteading-
proje...](http://www.rootsimple.com/2013/03/arduino-homesteading-projects/)

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

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

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

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

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

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

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

~~~
steveklabnik
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](https://github.com/rails/rails/issues/1769)

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

~~~
daleharvey
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

~~~
reedlaw
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](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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

~~~
Ygg2
Aren't you working on Rust?

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

------
Fasebook
How do be a little bitch.

------
mors_ontologica
Not one word about gardening. Fail train.

