
How to be an open source gardener (2014) - evex
https://words.steveklabnik.com/how-to-be-an-open-source-gardener
======
steveklabnik
This post is (2014), but I still stand by it today. I still do a lot of this
kind of thing. Happy to answer questions, as always.

> For Rust, we have issues for feature requests, meta-issues… everything.

This has changed, now Rust has the RFC process for feature requests.

~~~
evex
If you were to contribute to rails today, and you knew nothing about rails,

How would you exactly go about it?

1\. Learn Ruby to a good level where you can understand (almost) any ruby
code? if yes, is there any tutorial or book you recommend?

2\. Learn Rails to understand all the different parts of it?

3\. Or would you just go on and start reading the rails quick start guide, and
then get immediately to reading all of the issues on github and start
contributing to the docs first and work your way up from there?

Thanks :)

~~~
steveklabnik
I would get reasonably proficient at Ruby before tackling Rails; Rails uses
Ruby to its full extent, and so you'll need the chops to know what's going on.
Or at least, you used to. I imagine it's the same today.

The best book for leveling up your Ruby is "Metaprogramming Ruby". Yes, it's
technically a book about metaprogramming, but in order to metaprogram, you
need to learn about how Ruby really works. In my mind, if you don't grok
what's in that book, you're still new at Ruby (which is okay!), and once you
do, you're intermediate/advanced. Before that, the classics like the Pickaxe
are good for getting started.

From there, I personally would go the "pick an issue and dig in" route;
there's a lot to learn, and so having a reason to learn about a specific part
of the project is a good way to get going. If you hit a wall, pick another
issue.

~~~
evex
> Now, being as outdated as it is, it can no more be treated as one.
> Relatively "small" changes were made to Ruby since 2.0, but those changes
> are everywhere, and they seriously reshaped the language, preferred style,
> common patterns, and solution. So, one being introduced to language through
> Pickaxe will immediately be in possession of outdated knowledge.

source:
[https://www.reddit.com/r/ruby/comments/82ubtj/is_it_still_wo...](https://www.reddit.com/r/ruby/comments/82ubtj/is_it_still_worth_reading_the_pickaxe_manual/dvdbqir/)

I see Picaxe outdated? do you have another resource just to not learn the
outdated stuff?

~~~
steveklabnik
Interesting! I had not heard that. Maybe I myself am becoming outdated :)

~~~
evex
So I think I have to learn ruby the hard way, through outdated sources, ruby's
latest version is 2.5.0 right now,

I'll be learning through source on 2.0 and 2.1.0

please tell me if you have a better alternative or if it even matters to learn
the latest ruby.

~~~
zedeks48K
The Well Grounded Rubyist is a wonderful resource and the third edition,
released this August, covers Ruby 2.5.

[https://www.manning.com/books/the-well-grounded-rubyist-
thir...](https://www.manning.com/books/the-well-grounded-rubyist-third-
edition)

* Sorry, it seems it's going to be released on January 2019. In any case, the second edition covers Ruby 2.1. It's safe to learn with that one.

------
octref
I hope GitHub could add some features to help Open Source maintainers. Allow
adding contributors with issue triaging privileges is an obvious one. Required
fields (link to repro, software version) could be really helpful too.

Currently people have to work around these issues in awkward ways, like
creating a whole organization just to grant issue triaging privileges or
redirecting people off GitHub for filing issues with required fields [0].
Those workarounds run into limits quickly.

[0]: [https://new-issue.vuejs.org/?repo=vuejs/vue](https://new-
issue.vuejs.org/?repo=vuejs/vue)

~~~
steveklabnik
They did add [https://blog.github.com/2016-03-29-saved-
replies/](https://blog.github.com/2016-03-29-saved-replies/) a few years back
which would have saved my "copy/paste" stuff in the post.

I have long had chats with Hubbers over the years about the privilege thing,
and one of the hardest parts is the UI challenge. That is, you can do this,
but can you do it in a way that's not maddeningly complex? It's unclear.

~~~
octref
> that's not maddeningly complex

I'm not sure what's complex. Adding one more option "Triaging" here[0] doesn't
seem complex.

I'm working at VS Code and now we are trying to make a bot that would add a
label if someone (from a whitelist) types `/label bug` (same for marking
duplicates). The fact that we have to go this far for letting community
contributors assign labels to issues is more maddening to me.

See an example here:
[https://github.com/Microsoft/vscode/issues/62016#issuecommen...](https://github.com/Microsoft/vscode/issues/62016#issuecomment-433814370).

[0]: [https://user-
images.githubusercontent.com/4033249/47674432-8...](https://user-
images.githubusercontent.com/4033249/47674432-82167800-db74-11e8-8841-b542a9ce2d98.png)

~~~
steveklabnik
Yeah, we do that with Rust too.

Sure, if the perm is solely "traige issues", maybe that's fine, but what is
the exact level of granularity for this kind of thing?

I don't mean it's impossible, just that it's not completely simple, and
there's work to do to sort out the details. I also have never seen what dotcom
looks like, so I have no idea how hard these things are to implement, either.
Sometimes simple features can be rough to implement, especially in large,
legacy Rails apps...

------
GuyPostington
I thought this was going to be about actual gardening and am a bit
disappointed.

~~~
galois198
Same here - was interested in seeing the comparisons to OSS.

~~~
steveklabnik
While I did grow up on a farm, it was a beef cattle farm, and I discovered
computers at a young age and decided to ignore farming.

Someone else will have to write that post :)

------
worldsayshi
We should move towards application architectures that allow recording app
behavior in a reproducible way.

If every application had the ability to record input, output and state for a
given interaction then reproducibility wouldn't be such a huge burden.

Is this really a pipe dream?

~~~
setr
How do you know what level of state matters?

Eg a pure function just needs to track the function’s inputs and outputs; an
impure function relying on class-globals has to track class state, an impure
function on true-globals has to track full program state, an impure function
modifying the filesystem has to keep track of fs state, etc.

And if you try to track more state than you need, then you end up with say 40
test cases for each permutation of config env variables that aren't actually
relevant to the function in question, because users generating the test suite
were on different machines/environments.

And if you santize the environment, ensuring its always the same, and specify
exactly what should be tracked... you’re just back to handwritten tests

~~~
zoul
[https://guide.elm-lang.org/](https://guide.elm-lang.org/)

~~~
setr
Afaict on a quick skim, the elm guide makes no reference to testing, and other
than fully specifying your dependencies with only pure functions, doesn’t seem
to resolve the question of minimal state to generalize a test.

Html might be inherently simpler because the total output state is simpler
(just the html), but then you have things like caching, cookies, browser
versions, etc, which elm does not appear to capture in its dependencies

So.. whats the relevance to this conversation?

~~~
zoul
Elm has a time travelling debugger and the ability to dump all the state
transitions and replay them elsewhere, for example to reproduce a bug. Seems
relevant to me.

------
latchkey
The npm project moved their issues from github [1] to discourse [2]. I briefly
tried to find my open issue [3] in the new discourse search and couldn't. That
is one way to garden.

[1] [https://github.com/npm/npm/issues](https://github.com/npm/npm/issues)

[2] [https://npm.community/c/bugs](https://npm.community/c/bugs)

[3]
[https://github.com/npm/npm/issues/20072](https://github.com/npm/npm/issues/20072)

~~~
aeneasmackenzie
PostgresQL used to have an unusual bug tracking system: you report the bug,
and either someone on the mailing list volunteers to fix it, or it's dropped.
It has the advantage that you don't have an ever-growing collection of bug
reports.

~~~
anarazel
It kind of still works like that...

------
gardaani
Popular projects seem to be flooded with issues. Visual Studio Code release
notes [1] has interesting graphs showing how the number of issues start to
rise immediately when no one is taking care of them.

[1]
[https://code.visualstudio.com/updates/v1_28](https://code.visualstudio.com/updates/v1_28)

------
golubbe
"Writing a patch is the easiest part of open source. The truly hard stuff is
all of the rest: bug trackers, mailing lists, documentation, and other
management tasks." Truth.

