How to be an open source gardener (2014)
words.steveklabnik.com
words.steveklabnik.com
> For Rust, we have issues for feature requests, meta-issues… everything.
This has changed, now Rust has the RFC process for feature requests.
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
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 :)
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.
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?
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.
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.
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.
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'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...
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...
Someone else will have to write that post :)
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?
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
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?
[1] https://github.com/npm/npm/issues