How to be an open source gardener (2014)

https://words.steveklabnik.com/how-to-be-an-open-source-gardener

by evex • 8 years ago

104 26 8 years ago

words.steveklabnik.com

gardaani• 8 years ago

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

octref2• 8 years ago

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

steveklabnik7• 8 years ago

They did add 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.

octref2• 8 years ago

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

[0] https://user-images.githubusercontent.com/4033249/47674432-8...

steveklabnik7• 8 years ago

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.

hedoban• 8 years ago

How does that work? It looks like Rust has a repository for RFCs where anyone can submit one. How/where do the discussions happen then?

steveklabnik7• 8 years ago

Proposals are opened as pull requests, and the discussion happens in the pull request.

If you're not quite ready to make a formal proposal, you can open an issue, or better yet, start a thread on internals.rust-lang.org

evex3• 8 years ago

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

steveklabnik7• 8 years ago

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.

latchkey• 8 years ago

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

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

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

aeneasmackenzie• 8 years ago

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• 8 years ago

It kind of still works like that...

worldsayshi• 8 years ago

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?

setr2• 8 years ago

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

zoul2• 8 years ago

https://guide.elm-lang.org/

GuyPostington• 8 years ago

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

galois198• 8 years ago

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

steveklabnik7• 8 years ago

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

golubbe• 8 years ago

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

How to be an open source gardener (2014)

Related Stories