It's not bikeshedding, but there ought to be a name for that.
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.
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.
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.
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.
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.
@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...
I didn't really care that much about it getting merged in, so long as the docs changed (fxn's argument about using a fixed-width font in html docs to indicate the singleton true vs a truthy value is something that really ought to change). That stance is unfriendly to developers and follows what seems to be the Principle of Most Surprise.
At the end of the day, it's not worth all the trouble for something so trivial. I'd rather rails-core deal with more important issues. And that's the last time I ever send a pull request on principle to a project I don't own.
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.
Try imagining this from somebody else's eyes — what does it look like?
Yes it matters to me, but up to a point. I cannot do things in my life seeking approval or saying yes to some people when I am convinced the answer is no.
Also, saying no, and not applying the PR the way I did, with the rationales and respect I showed, should not be taken as an offense. People just get upset when they see the red label "Closed".
On the other hand, for every 24 haters, I can present 24 lovers. It just doesn't matter, one has to do what he thinks is the correct action. Do it politely, but do it.
What you failed to address was why your way was better than returning a boolean true/false. Everyone understood your comments that predicates don't necessarily need to return those, but your comments kind of read like "my way is perfectly valid Ruby" while the other people's perspective seemed to be "our way is perfectly valid Ruby also, and it alleviates some potential annoyances or pitfalls". You never really addressed any of that, it always seemed to just go back to "my way is valid Ruby".
Maybe this wasn't really your intention, but it honestly seemed as though you were deliberately trying to frustrate people. I think that's why there was so much push-back (in the form of about three other PRs being opened). Not because people felt so strongly about xhr?, but because it just seemed like you were just rejecting everyone's opinions without really expressing why returning true/false is worse than returning 0/nil.
I'm basically a total outsider since I haven't contributed to Rails yet, so feel free to completely ignore my perspective.
There you see how closely I follow this story... :)
If you read the original source for the term at 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.
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.
Of course, people don't actually do this. They talk about doing it, but don't actually carry through.
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.
readable = File.world_readable?('/etc/passwd')
What's the best way for a rookie to find small, welcoming open-source projects to contribute to?
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.
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.
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.