How to be an open source gardener (2014)(words.steveklabnik.com)
words.steveklabnik.com
How to be an open source gardener (2014)
https://words.steveklabnik.com/how-to-be-an-open-source-gardener
26 comments
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 :)
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 :)
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.
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.
> 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...
I see Picaxe outdated? do you have another resource just to not learn the outdated stuff?
source: https://www.reddit.com/r/ruby/comments/82ubtj/is_it_still_wo...
I see Picaxe outdated? do you have another resource just to not learn the outdated stuff?
Interesting! I had not heard that. Maybe I myself am becoming outdated :)
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.
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.
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...
* 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.
https://www.manning.com/books/the-well-grounded-rubyist-thir...
* 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.
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?
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
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
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
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
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.
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.
> 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...
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...
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...
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...
I thought this was going to be about actual gardening and am a bit disappointed.
Same here - was interested in seeing the comparisons to OSS.
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 :)
Someone else will have to write that post :)
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?
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?
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
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
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?
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?
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.
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
[1] https://github.com/npm/npm/issues
[2] https://npm.community/c/bugs
[3] https://github.com/npm/npm/issues/20072
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.
It kind of still works like that...
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
[1] https://code.visualstudio.com/updates/v1_28
"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.
> For Rust, we have issues for feature requests, meta-issues… everything.
This has changed, now Rust has the RFC process for feature requests.