7 ms·

Rookies in the Bike Shed

74 points by jashkenas 15y ago

jashkenas 15y ago
The Rails commit that spurred this post, apparently: https://github.com/rails/rails/pull/5329 https://github.com/rails/rails/pull/5329
- lucisferre 15y ago
  Bah, I can't be bothered to read the whole thing. Before the request was closed, if I understood correctly, the argument was about whether or not `xhr?` needed to return a boolean rather than what it's doing which is aliasing a regex match. Hmm, call it bike-shedding if you want, but I have to be honest part of the beauty and value of Ruby is how semantic it can be made when you follow some conventions. How hard or awful is it to just actually return a boolean here? I mean is anyone expecting or relying on the clearly undocumented feature that it also returns the offset of where `/XMLHttpRequest/i` is found in the request? The problem with throwing out the 'bikeshedding' defence is that it goes both ways. It's their choice to fight a small, trivial pull request that appears to make logical sense, and arguably reduces the potential for cognitive friction. It's debatable who's actually bikeshedding here.
  - dhh 15y ago
    Dude, that's deep. You're bike shedding the bike shed. So meta. Turtles all the way down. Touché!
    - lucisferre 15y ago
      Fair enough, I wont argue with your elastic defence ;).
    - CodeMage 15y ago
      Upvoted you despite the slightly obfuscated phrasing, because it's essentially true. This turned into a bikeshedding discussion on bikeshedding the moment lucisferre misrepresented his own definition of bikeshedding as the canonical definition.
      - lucisferre 15y ago
        Did I? Perhaps you could elaborate for my benefit then.
  - bradleyland 15y ago
    This happens all the time, and I'd argue, is the source of what many consider bike shed issues, even when they're not. An essential element of a bike shed disagreement is that the matter being discussed must be trivial. That is, the color of a bike shed doesn't matter. It has no impact on the utility of the bike shed. This is a function before form viewpoint. Ah, but if real life were only so black & white. In practice, triviality is a sliding scale. The presence of the offset is only trivial if you're not using it. So, to some people, it's a bike shed issue. To others, it's a matter of breaking lots of code. Clearly not a bike shed.
    - nirvdrum 15y ago
      Agreed. It all depends on perspective. That's why I've always found the term to be needlessly dismissive.
  - deleted 15y ago
    [deleted]
  - lucisferre 15y ago
    Just wanted to note, I had a chance to read the closed pull request from later and then this post (http://blog.leshill.org/blog/2012/03/25/a-question-of-truth.html http://blog.leshill.org/blog/2012/03/25/a-question-of-truth....) and I see the point being made, which is not against the change, but in defence of not making an unneeded one. So my understanding of the situation was poor. But then I am, admittedly, a bike shedding rookie. However, and this is just my opinion, I still feel as though calling out everyone (there was a good number of people involved including @tpope) as rookies and accusing them of bike shedding, seemed like, well, poor taste, and unhelpful.
- zumda 15y ago
  To summarize it: Someone upgraded from Rails 2.3 and had an issue, since xhr? stopped returning a boolean but 0 instead (the regex index of the first match). But he used the return value of that predicate in javascript. In Ruby 0 is truthy, but in Javascript it is false. So he made a pull request to change the behavior back to a boolean instead of 0. @fxn then said that's not needed, and the predicate did return a truthy value and the contract never specified that it would actually return a boolean, so no contract was broken, so there is nothing to fix. (The Rails documentation uses monospaced "true" and "false" for the singletons and normal "true" and "false" for truthy and falsey values.) Then Tim Pope suggested an alternative solution that would actually return a boolean. It got merged by @tenderlove but quickly reverted by @fxn again. And so the bike shedding continued...
  - fxn 15y ago
    Indeed, it took me some 24 hours to revert. I reflected about it for some time. After thinking about it for a day, I was convinced the commit was sending the wrong message, and felt it had to be reverted. The commit message explains the rationale.
    - zumda 15y ago
      Ah I'm sorry, I should have rechecked before posting this. I meant no offense. There you see how closely I follow this story... :)
    - kelnos 15y ago
      I was thinking about avoiding replying on this thread, because I can't know the motivations of the people involved, but this reply kinda takes the cake. I was an active open source contributor and maintainer for around 6 years this past decade. I've witnessed (and sadly fervently participated in) my fair share of bike-shed discussions. Some (most?) of them quite regretfully. I've learned something recently about APIs and frameworks, when you're the author. Something that should be obvious, but apparently isn't: your job is to make it as easy to build on as possible. Full stop. That's it. That is the number one priority. If one of your interfaces is confusing, you make it not confusing. It doesn't matter if it makes the implementation a little bit more complicated, or a little bit less beautiful and idiomatic. It does matter if it introduces a huge unacceptable performance degradation or a security issue. But that just means you need to rethink your implementation and assumptions. Because really, the user of your software is all that matters. You can make all sorts of stupid arguments, arguments that I myself have made in the past: * I write this software for me, not for you. Be happy that I've chosen to share it with you so you can benefit too. * Maintainability is more important. * Implementation elegance is more important. * Following common idioms is more important. * It's documented, so even if it's not 100% straightforward, it's ok. * If you don't like it, fork it. No. I don't care. At all. Once you make your code public in the open source world, it's not yours anymore. It belongs to everyone. Suggesting any of the above is just selfish, egotistical, and irresponsible to your users. This is the real world here, not some idealized theoretical academic playground. People use your software to get work done. People use your software to avoid having to reinvent the wheel every time they come across a similar problem. People use your software because it saves them time. Oh wait: except when behavior is changed for no good reason, and now they have to audit tens of thousands of lines of code to make sure everything still works. It's utterly unnecessary to force people to do this. I've been sorely tempted any number of times to stick to my guns, believing more in the principle of the thing than in the practical effects my decision would have on my users. And I'm sad to say that many times I made what I now know to be the wrong decision. The closing of the initial pull request might be forgivable. I disagree with it, but hey, it's not the end of the world, and there's certainly precedent for that behavior. Sure, the change that introduced that behavior is pretty questionable, but... ok, let's leave it be. But then we have another developer who commits a change that "fixes" the behavior in a manner that looks elegant and readable and maintainable. And you revert it. Why? Because you feel it sends the wrong "message". Because it might make people believe that all predicate methods return boolean singletons. Which is nothing more than convoluted logic used to reinforce your own opinion. But ok, ok. We're all human. And I could certainly argue that it was rude of the other guy to make that commit without consulting you first. (Assuming he didn't, I actually do believe it was pretty rude of him to do that.) And then there's the final straw: someone submits a pull request to augment the documentation to make it clear what the method actually returns. And you reject it. Ok, you don't want so much information about the internal implementation in the docs. Gotcha. But you can still make the docs clearer without leaking that info. (Or, hell, you could just, y'know... not leak the implementation out through the API call itself.) All credibility lost now. The crap about variable-width vs. fixed-width font usage in docs is just semantic masturbation. You are not making things clear for your users. That is a problem. Instead of fixing it, you dismiss people who try to help you. Is this particular issue a bike-shed moment? Yeah, probably. The return value of xml_http_reqeust? isn't really what I care about. I'm sure there are plenty of other predicates in Rails that behave similarly. The issue here is the message this sends: "I care more about writing idiomatic ruby than I care about making my users' lives easier". Which is ridiculous when you consider that the entire purpose of Rails is to make webapp developers' lives easier.
- protomyth 15y ago
  I found this comment https://github.com/rails/rails/pull/5329#issuecomment-4669686 https://github.com/rails/rails/pull/5329#issuecomment-466968... interesting for the implications of keeping an instance variable around as opposed to true / false.
- bguthrie 15y ago
  Thanks for the link. It wasn't clear to me, however, who was doing the bikeshedding. If you read the original source for the term at http://bikeshed.com/ http://bikeshed.com/, Kamp shows his respect for the submitter of the change: I bow my head in respect to the original proposer because he stuck to his guns through this carpet blanking from the peanut gallery, and the change is in our tree today. I would have turned my back and walked away after less than a handful of messages in that thread. This is how I feel about the pull request: a seemingly innocuous change that looks, to this outsider anyway, well worth making. It seemed to have been declined over a concern that people would come to expect Rails to formalize undocumented behavior that others had relied on. I've been consuming Rails docs for years (thank you to the contributors), and that doesn't seem that crazy to me. (Edit: formatting.)
- stiff 15y ago
  To me it is not bike-shedding, but being rightfully indignant with decisions being made not by merit but from a position of "authority", completely ignoring the opinion of the majority of people presenting pretty logical arguments in favour of the change. I do not understand how you can defend returning a method call result completely meaningless from the caller point of view by saying that returning an actually meaningful one would suddenly make everyone think that the xyz? methods have to return true/false everywhere. This is the kind of reaction you get from people when you refuse to admit you were wrong after it is already clear to everyone you were.
  - stock_toaster 15y ago
    Maybe they are just trying to optimize for pedantry.
  - Cushman 15y ago
    That's the only objective read of this. There were a couple of good reasons to make the change, a couple of bad reasons to, and no reasons not to. The discussion fixated on the bad reasons early on, it became a matter of principle on both sides, and thus the change was not made despite the good reasons. It's not bikeshedding, but there ought to be a name for that.
    - aeturnum 15y ago
      My read of the article is that "bikeshedding" generally covers discussions in which the energy expended vastly outweighs the gravity of the topic under discussion. There can be a correct answer to, "what color should we paint the bike shed?" (or, at least, many incorrect answers). The fact that one side might be correct (or more correct) than the other does not justify the effort. The point of the article, as I read it, was that you should consider the energy needed to influence a decision v.s. the impact of that decision.
      - Cushman 15y ago
        I think the point we're making is that most of the people arguing over that PR didn't have a strong opinion about the feature itself, but were irritated by the weirdly philosophical reason for rejecting it. (I don't care what color you paint your bike shed, but if your local government says you can't paint it green because that's surrendering to the plants, I'm likely to have an opinion about that.) Obviously at some point (and the earlier the better) you still need to to throw up your hands and walk away, but I'd say pig wrestling is the better metaphor here.
- bluesnowmonkey 15y ago
  It's frustrating to work with people who will go to the mat over pedantic, highly philosophical points like that, right or wrong. Arguments should be grounded on concrete pros/cons.
spacesuit 15y ago
This post raises some interesting points about the difficulty of contributing to open source for the first time. Over the last year, I've taught myself to code. I want to contribute to open source, and I think I can provide value to smaller projects. But the public nature and unique culture of open source have left me feeling a bit overwhelmed. So I observe instead. What's the best way for a rookie to find small, welcoming open-source projects to contribute to?
- viscanti 15y ago
  Find a small project you use for something you're building. Do you run into any issues with using it, that could be improved? Improve those and send a pull request. Make your first commit small and obvious.
- lucisferre 15y ago
  Find a "small" project is probably best. I've contributed to probably over a dozen opensource projects on Github in the past year or so. I highly encourage you to find a few that you use and like. They don't even have to be really small, but I'd probably avoid projects like Ruby, Rails or the Linux kernel for now.
- rohitarondekar 15y ago
  Try to get into a bugmash of some kind. I started this way with Rails and I wrote about it http://www.rohitarondekar.com/articles/my-first-rails-bugmash http://www.rohitarondekar.com/articles/my-first-rails-bugmas... Many companies and tech groups have these around the world during meetups and conferences. But most importantly dont let this pull request fool you. Rails is nice to contribute to even if you are starting out and the rails core team especially jose valim and santiago pastorino are super helpful.
- code_pockets 15y ago
  Start your own project. Open source is not strictly about contributing to existing projects. You can start as many new projects as you'd like. My experience is that many big projects started out as personal (read small) projects that grew out of adoption. What kind of projects should you start? Pick something that you reason you can solve with your current knowledge, and get working.
jasonlotito 15y ago
And this is why people reinvent the wheel. If you disagree with the core teams decision here, you are at an impasse. So, you fork and move on. Or, you think about it, and decide to create your own framework that will be like Rails, but do things the way you want to do them, including making xhr? work the way you think it should. Reinventing the wheel gets a bad wrap. People suggest you should contribute to existing projects. The problem is when that existing project's direction diverges from your needs. Reinventing the wheel is part of the power of open source. On a side note, considering the sheer number of types of wheels, "reinventing the wheel" comes across as a bit odd.
- dhh 15y ago
  This is exactly the point of the original post. That if you're willing to redo Rails because a predicate method does not return singletons, you're a rookie who don't know the value of time. Of course, people don't actually do this. They talk about doing it, but don't actually carry through.
  - jasonlotito 15y ago
    > That if you're willing to redo Rails because a predicate method... I wasn't clear. My mistake. The issue isn't one of a predicate method, but rather, overall approach. If Rails doesn't work the way you want, you don't whine and complain it doesn't work. You either accept it, or move on and do something better. The if the attitude demonstrated here is something you can't work with, you move on. It's not just this issue, but every issue like it as well. I agree with the premise of the post (bike shedding is pointless); however, if you need a garage and not a bike shed, trying to get people who want that bike shed and are building that bike shed to instead build a garage, your better off moving on.
parfe 15y ago
I saw one post mention File.world_readable? I don't know Ruby and the result surprised me. irb(main):002:0> File.world_readable?('/etc/passwd') => 420 irb(main):003:0> File.world_readable?('/etc/shadow') => nil 420 is decimal for octal 0644 which is the permissions on my /etc/passwd file. Fair enough, but as someone looking from the outside it seems weird to leak partial and unreliable information like that. Especially if I was to write readable = File.world_readable?('/etc/passwd') and later readable has an integer in it representing an octal value which can't be used for more than a true/false value. Is it common to throw !! in front of truthy/falsey calls to get down to the boolean literal?
- nfm 15y ago
  It's not a common idiom to use !! in Ruby.
sunir 15y ago
I agree this is a good approach for any open source project leader to have. It's valuable to let rookies argue small debates so they can learn the ropes and get a feel for the community; it's even more valuable for the veterans and leadership to make decisions, set priorities, and maintain focus on what's important. Both are necessary to grow and sustain an open community project. You bring people in and get them engaged whilst reinforcing what the project is focused on, its tone, style, and mission. Making a decision civilly, whether everyone agrees or not, is very reassuring to newcomers and oldtimers alike. It proves that the community is fun and worthwhile.
mvgoogler 15y ago
This reminded me a bit of this thread: https://bugzilla.redhat.com/show_bug.cgi?id=638477#c38 https://bugzilla.redhat.com/show_bug.cgi?id=638477#c38

74 points by jashkenas 15y ago

The Rails commit that spurred this post, apparently: https://github.com/rails/rails/pull/5329 https://github.com/rails/rails/pull/5329

lucisferre 15y ago
Bah, I can't be bothered to read the whole thing. Before the request was closed, if I understood correctly, the argument was about whether or not `xhr?` needed to return a boolean rather than what it's doing which is aliasing a regex match. Hmm, call it bike-shedding if you want, but I have to be honest part of the beauty and value of Ruby is how semantic it can be made when you follow some conventions. How hard or awful is it to just actually return a boolean here? I mean is anyone expecting or relying on the clearly undocumented feature that it also returns the offset of where `/XMLHttpRequest/i` is found in the request? The problem with throwing out the 'bikeshedding' defence is that it goes both ways. It's their choice to fight a small, trivial pull request that appears to make logical sense, and arguably reduces the potential for cognitive friction. It's debatable who's actually bikeshedding here.
- dhh 15y ago
  Dude, that's deep. You're bike shedding the bike shed. So meta. Turtles all the way down. Touché!
  - lucisferre 15y ago
    Fair enough, I wont argue with your elastic defence ;).
  - CodeMage 15y ago
    Upvoted you despite the slightly obfuscated phrasing, because it's essentially true. This turned into a bikeshedding discussion on bikeshedding the moment lucisferre misrepresented his own definition of bikeshedding as the canonical definition.
    - lucisferre 15y ago
      Did I? Perhaps you could elaborate for my benefit then.
- bradleyland 15y ago
  This happens all the time, and I'd argue, is the source of what many consider bike shed issues, even when they're not. An essential element of a bike shed disagreement is that the matter being discussed must be trivial. That is, the color of a bike shed doesn't matter. It has no impact on the utility of the bike shed. This is a function before form viewpoint. Ah, but if real life were only so black & white. In practice, triviality is a sliding scale. The presence of the offset is only trivial if you're not using it. So, to some people, it's a bike shed issue. To others, it's a matter of breaking lots of code. Clearly not a bike shed.
  - nirvdrum 15y ago
    Agreed. It all depends on perspective. That's why I've always found the term to be needlessly dismissive.
- deleted 15y ago
  [deleted]
- lucisferre 15y ago
  Just wanted to note, I had a chance to read the closed pull request from later and then this post (http://blog.leshill.org/blog/2012/03/25/a-question-of-truth.html http://blog.leshill.org/blog/2012/03/25/a-question-of-truth....) and I see the point being made, which is not against the change, but in defence of not making an unneeded one. So my understanding of the situation was poor. But then I am, admittedly, a bike shedding rookie. However, and this is just my opinion, I still feel as though calling out everyone (there was a good number of people involved including @tpope) as rookies and accusing them of bike shedding, seemed like, well, poor taste, and unhelpful.
zumda 15y ago
To summarize it: Someone upgraded from Rails 2.3 and had an issue, since xhr? stopped returning a boolean but 0 instead (the regex index of the first match). But he used the return value of that predicate in javascript. In Ruby 0 is truthy, but in Javascript it is false. So he made a pull request to change the behavior back to a boolean instead of 0. @fxn then said that's not needed, and the predicate did return a truthy value and the contract never specified that it would actually return a boolean, so no contract was broken, so there is nothing to fix. (The Rails documentation uses monospaced "true" and "false" for the singletons and normal "true" and "false" for truthy and falsey values.) Then Tim Pope suggested an alternative solution that would actually return a boolean. It got merged by @tenderlove but quickly reverted by @fxn again. And so the bike shedding continued...
- fxn 15y ago
  Indeed, it took me some 24 hours to revert. I reflected about it for some time. After thinking about it for a day, I was convinced the commit was sending the wrong message, and felt it had to be reverted. The commit message explains the rationale.
  - zumda 15y ago
    Ah I'm sorry, I should have rechecked before posting this. I meant no offense. There you see how closely I follow this story... :)
  - kelnos 15y ago
    I was thinking about avoiding replying on this thread, because I can't know the motivations of the people involved, but this reply kinda takes the cake. I was an active open source contributor and maintainer for around 6 years this past decade. I've witnessed (and sadly fervently participated in) my fair share of bike-shed discussions. Some (most?) of them quite regretfully. I've learned something recently about APIs and frameworks, when you're the author. Something that should be obvious, but apparently isn't: your job is to make it as easy to build on as possible. Full stop. That's it. That is the number one priority. If one of your interfaces is confusing, you make it not confusing. It doesn't matter if it makes the implementation a little bit more complicated, or a little bit less beautiful and idiomatic. It does matter if it introduces a huge unacceptable performance degradation or a security issue. But that just means you need to rethink your implementation and assumptions. Because really, the user of your software is all that matters. You can make all sorts of stupid arguments, arguments that I myself have made in the past: * I write this software for me, not for you. Be happy that I've chosen to share it with you so you can benefit too. * Maintainability is more important. * Implementation elegance is more important. * Following common idioms is more important. * It's documented, so even if it's not 100% straightforward, it's ok. * If you don't like it, fork it. No. I don't care. At all. Once you make your code public in the open source world, it's not yours anymore. It belongs to everyone. Suggesting any of the above is just selfish, egotistical, and irresponsible to your users. This is the real world here, not some idealized theoretical academic playground. People use your software to get work done. People use your software to avoid having to reinvent the wheel every time they come across a similar problem. People use your software because it saves them time. Oh wait: except when behavior is changed for no good reason, and now they have to audit tens of thousands of lines of code to make sure everything still works. It's utterly unnecessary to force people to do this. I've been sorely tempted any number of times to stick to my guns, believing more in the principle of the thing than in the practical effects my decision would have on my users. And I'm sad to say that many times I made what I now know to be the wrong decision. The closing of the initial pull request might be forgivable. I disagree with it, but hey, it's not the end of the world, and there's certainly precedent for that behavior. Sure, the change that introduced that behavior is pretty questionable, but... ok, let's leave it be. But then we have another developer who commits a change that "fixes" the behavior in a manner that looks elegant and readable and maintainable. And you revert it. Why? Because you feel it sends the wrong "message". Because it might make people believe that all predicate methods return boolean singletons. Which is nothing more than convoluted logic used to reinforce your own opinion. But ok, ok. We're all human. And I could certainly argue that it was rude of the other guy to make that commit without consulting you first. (Assuming he didn't, I actually do believe it was pretty rude of him to do that.) And then there's the final straw: someone submits a pull request to augment the documentation to make it clear what the method actually returns. And you reject it. Ok, you don't want so much information about the internal implementation in the docs. Gotcha. But you can still make the docs clearer without leaking that info. (Or, hell, you could just, y'know... not leak the implementation out through the API call itself.) All credibility lost now. The crap about variable-width vs. fixed-width font usage in docs is just semantic masturbation. You are not making things clear for your users. That is a problem. Instead of fixing it, you dismiss people who try to help you. Is this particular issue a bike-shed moment? Yeah, probably. The return value of xml_http_reqeust? isn't really what I care about. I'm sure there are plenty of other predicates in Rails that behave similarly. The issue here is the message this sends: "I care more about writing idiomatic ruby than I care about making my users' lives easier". Which is ridiculous when you consider that the entire purpose of Rails is to make webapp developers' lives easier.
protomyth 15y ago
I found this comment https://github.com/rails/rails/pull/5329#issuecomment-4669686 https://github.com/rails/rails/pull/5329#issuecomment-466968... interesting for the implications of keeping an instance variable around as opposed to true / false.
bguthrie 15y ago
Thanks for the link. It wasn't clear to me, however, who was doing the bikeshedding. If you read the original source for the term at http://bikeshed.com/ http://bikeshed.com/, Kamp shows his respect for the submitter of the change: I bow my head in respect to the original proposer because he stuck to his guns through this carpet blanking from the peanut gallery, and the change is in our tree today. I would have turned my back and walked away after less than a handful of messages in that thread. This is how I feel about the pull request: a seemingly innocuous change that looks, to this outsider anyway, well worth making. It seemed to have been declined over a concern that people would come to expect Rails to formalize undocumented behavior that others had relied on. I've been consuming Rails docs for years (thank you to the contributors), and that doesn't seem that crazy to me. (Edit: formatting.)
stiff 15y ago
To me it is not bike-shedding, but being rightfully indignant with decisions being made not by merit but from a position of "authority", completely ignoring the opinion of the majority of people presenting pretty logical arguments in favour of the change. I do not understand how you can defend returning a method call result completely meaningless from the caller point of view by saying that returning an actually meaningful one would suddenly make everyone think that the xyz? methods have to return true/false everywhere. This is the kind of reaction you get from people when you refuse to admit you were wrong after it is already clear to everyone you were.
- stock_toaster 15y ago
  Maybe they are just trying to optimize for pedantry.
- Cushman 15y ago
  That's the only objective read of this. There were a couple of good reasons to make the change, a couple of bad reasons to, and no reasons not to. The discussion fixated on the bad reasons early on, it became a matter of principle on both sides, and thus the change was not made despite the good reasons. It's not bikeshedding, but there ought to be a name for that.
  - aeturnum 15y ago
    My read of the article is that "bikeshedding" generally covers discussions in which the energy expended vastly outweighs the gravity of the topic under discussion. There can be a correct answer to, "what color should we paint the bike shed?" (or, at least, many incorrect answers). The fact that one side might be correct (or more correct) than the other does not justify the effort. The point of the article, as I read it, was that you should consider the energy needed to influence a decision v.s. the impact of that decision.
    - Cushman 15y ago
      I think the point we're making is that most of the people arguing over that PR didn't have a strong opinion about the feature itself, but were irritated by the weirdly philosophical reason for rejecting it. (I don't care what color you paint your bike shed, but if your local government says you can't paint it green because that's surrendering to the plants, I'm likely to have an opinion about that.) Obviously at some point (and the earlier the better) you still need to to throw up your hands and walk away, but I'd say pig wrestling is the better metaphor here.
bluesnowmonkey 15y ago
It's frustrating to work with people who will go to the mat over pedantic, highly philosophical points like that, right or wrong. Arguments should be grounded on concrete pros/cons.

spacesuit 15y ago

This post raises some interesting points about the difficulty of contributing to open source for the first time. Over the last year, I've taught myself to code. I want to contribute to open source, and I think I can provide value to smaller projects. But the public nature and unique culture of open source have left me feeling a bit overwhelmed. So I observe instead. What's the best way for a rookie to find small, welcoming open-source projects to contribute to?

viscanti 15y ago
Find a small project you use for something you're building. Do you run into any issues with using it, that could be improved? Improve those and send a pull request. Make your first commit small and obvious.
lucisferre 15y ago
Find a "small" project is probably best. I've contributed to probably over a dozen opensource projects on Github in the past year or so. I highly encourage you to find a few that you use and like. They don't even have to be really small, but I'd probably avoid projects like Ruby, Rails or the Linux kernel for now.
rohitarondekar 15y ago
Try to get into a bugmash of some kind. I started this way with Rails and I wrote about it http://www.rohitarondekar.com/articles/my-first-rails-bugmash http://www.rohitarondekar.com/articles/my-first-rails-bugmas... Many companies and tech groups have these around the world during meetups and conferences. But most importantly dont let this pull request fool you. Rails is nice to contribute to even if you are starting out and the rails core team especially jose valim and santiago pastorino are super helpful.
code_pockets 15y ago
Start your own project. Open source is not strictly about contributing to existing projects. You can start as many new projects as you'd like. My experience is that many big projects started out as personal (read small) projects that grew out of adoption. What kind of projects should you start? Pick something that you reason you can solve with your current knowledge, and get working.

jasonlotito 15y ago

And this is why people reinvent the wheel. If you disagree with the core teams decision here, you are at an impasse. So, you fork and move on. Or, you think about it, and decide to create your own framework that will be like Rails, but do things the way you want to do them, including making xhr? work the way you think it should. Reinventing the wheel gets a bad wrap. People suggest you should contribute to existing projects. The problem is when that existing project's direction diverges from your needs. Reinventing the wheel is part of the power of open source. On a side note, considering the sheer number of types of wheels, "reinventing the wheel" comes across as a bit odd.

dhh 15y ago
This is exactly the point of the original post. That if you're willing to redo Rails because a predicate method does not return singletons, you're a rookie who don't know the value of time. Of course, people don't actually do this. They talk about doing it, but don't actually carry through.
- jasonlotito 15y ago
  > That if you're willing to redo Rails because a predicate method... I wasn't clear. My mistake. The issue isn't one of a predicate method, but rather, overall approach. If Rails doesn't work the way you want, you don't whine and complain it doesn't work. You either accept it, or move on and do something better. The if the attitude demonstrated here is something you can't work with, you move on. It's not just this issue, but every issue like it as well. I agree with the premise of the post (bike shedding is pointless); however, if you need a garage and not a bike shed, trying to get people who want that bike shed and are building that bike shed to instead build a garage, your better off moving on.

parfe 15y ago

I saw one post mention File.world_readable? I don't know Ruby and the result surprised me. irb(main):002:0> File.world_readable?('/etc/passwd') => 420 irb(main):003:0> File.world_readable?('/etc/shadow') => nil 420 is decimal for octal 0644 which is the permissions on my /etc/passwd file. Fair enough, but as someone looking from the outside it seems weird to leak partial and unreliable information like that. Especially if I was to write readable = File.world_readable?('/etc/passwd') and later readable has an integer in it representing an octal value which can't be used for more than a true/false value. Is it common to throw !! in front of truthy/falsey calls to get down to the boolean literal?

nfm 15y ago
It's not a common idiom to use !! in Ruby.

sunir 15y ago

I agree this is a good approach for any open source project leader to have. It's valuable to let rookies argue small debates so they can learn the ropes and get a feel for the community; it's even more valuable for the veterans and leadership to make decisions, set priorities, and maintain focus on what's important. Both are necessary to grow and sustain an open community project. You bring people in and get them engaged whilst reinforcing what the project is focused on, its tone, style, and mission. Making a decision civilly, whether everyone agrees or not, is very reassuring to newcomers and oldtimers alike. It proves that the community is fun and worthwhile.

mvgoogler 15y ago

This reminded me a bit of this thread: https://bugzilla.redhat.com/show_bug.cgi?id=638477#c38 https://bugzilla.redhat.com/show_bug.cgi?id=638477#c38