Define bikeshed and how to identify one

Wikipedia:

Parkinson's Law of Triviality, also known as bikeshedding or the bicycle-shed example, is C. Northcote Parkinson's 1957 argument that organisations give disproportionate weight to trivial issues. Parkinson demonstrated this by contrasting the triviality of a bike shed to a nuclear reactor. Later, Poul-Henning Kamp applied the law to software development and introduced the colour of the bike shed as the proverbial trivial detail receiving disproportionate attention.

[...]

A nuclear reactor is used because it is so vastly expensive and complicated that an average person cannot understand it, so they assume that those working on it understand it. Even those with strong opinions often withhold them for fear of being shown to be insufficiently informed. On the other hand, everyone can visualize a bicycle shed, so planning one can result in endless discussions because everyone involved wants to add his or her touch and show that they have contributed.

In Parkinson's version, 'to bikeshed' would be to ignore complex systems in order to concentrate on something easily-understood, in no small part for personal glory.

In software development culture, the term seems to take on a more accusatory tone when directed at someone's lone stand on an issue, or invalidates the otherwise reasonable discussion that led to a stalemate.

Accusation and invalidation are not positive activities. :-)

Parkinson's point is funny. He's actually trying to bring a humorous perspective to a problem faced by organizations. The inherent problem beneath the problem is this: People tend to avoid larger perspectives, especially when they're busy scrapping for their own glory, and especially when the perspective they need is about themselves. Thus it's easier to say, "That guy is bikeshedding," than it is to say "I am bikeshedding and I'm being a bit of a fool about this. Let's have cake."

Colloqually, Drupal has lately been using "bikeshed" as a synonym for any discussion that has some degree of subjectivity. "Let's go post an issue to bikeshed that" is a line I've seen many many times lately, and I think we need to stop doing that. It legitimizes bikeshedding, aka trivial and uninformed yet forceful opinions that disrupt the process of finding a good conclusion, rather than treating that behavior as something to discourage.

So why is this not called "Bikeshedding the definition of bikeshed"? ;)

Seriously, though, I agree with Crell. We joke about bikeshedding a lot but we do need to clearly draw the line between productive differences of opinion working towards a compromise and unproductive bickering, especially about trivialities, that are derailing the issue.

Michelle

When I was running my slides past Eaton before my session, he pointed out to me that we also sometime use the term 'bikeshed' to cast doubt on someone who disagrees with us (this is in the same vein as what Crell posted above but also somewhat different.) 'Bikeshed' should not be a weapon to quiet dissent, and it also should not be a throwaway joke to the point the term loses all meaning. I think something helpful to do would be to post a list of example discussions and describe what does or doesn't make each of them 'biksheddy'. I will try to start to put this together sometime after I've recovered.

Aw.
I've come to quite like the d.o. meaning of "bikeshed"

I think there is an interesting "watercooler" effect to it sometimes. *Technically* there's not a lot of work getting done at that instant, so technically it looks non-productive. But there is a community-building and open communication factor to bikeshedding. They are often topics where the "code is gold" developers don't get to overrule everyone else.

When a discussion goes into bikeshed mode it means that we know that ultimately it's not so very important in the grand scheme of things, but it opens up participation, we can talk in a relaxed way, and maybe it's an interesting topic. And safe because there are no dangerous repercussions.
It's *actually* an interesting leveller sometimes, as - implicit in the above definition - it lets the less-senior players can offer suggestions on the same level as the super-devs. There is a non-technical social aspect to it. ... provided everyone knows not to get too excited about it.
"Bickering" is only one possible characterization of bikeshedding. Hearing others opinions and getting to interact with them is another. For newbies to get a reply from a core contributor in a perr-to-peer way is a little bit of a thrill, and encourages them.

So I don't see "bikeshed" as a pejorative term at all.
In a few cases - it can even be a life-saver. If some functionality is underway, but being held up because of disagreement on wording, or grouping, or placement - that sub-issue can be shunted off into its own 'bikeshed' discussion and stop being a blocker for the actual development. We can say : "The decision on whether to use fieldsets or the 'details' element is being discussed over there, but in the meantime, here's the code that will add user-help everywhere..."

Nobody got *any* entertainment out of #242048: Replace "blue smurf" in no search results message at all? I loved it!

How about instead of defining "bikeshed" and legitimizing it with concrete definitions, we instead pick a word like "blocked" (as rfay suggested) and use that strictly for a very serious meaning and leave bikeshed for all the rest of the more jokey uses?

This is a metaphor indicating that you need not argue about every little feature just because you know enough to do so. Some people have commented that the amount of noise generated by a change is inversely proportional to the complexity of the change.

Bikeshed.com

To me a bikeshed is simple - Everybody agrees on a "feature". Everybody agrees that the "feature" is needed and would be valuable. Enough people disagree on the implementation of that feature that it stalls for lack of agreement. So, to my mind, for a "bikeshed" to exist you need the following:

• Agreement that "something" (code, documentation, feature, change request, almost anything else) would have value and should be worked on.
• People who are or are READY to work on it.
• Differing opinions on how that thing should be worked on (implemented).
• Deadlock from those who's opinions matter on this particular topic (subject experts).

@MatthewS: That's simple deadlock. No one wants to work on something that has already been derided as poorly-designed, even before it's made. :-)

One solution is rock-paper-scissors, two out of three, and then iterate over the *code.*

Another solution is to start discussing what tests to write.

I honestly think its a useless word, to describe lack of leadership rather than lack of consensus. I might have a very opposite stance on this than other community members, but "bikeshed" gets thrown around in almost every single design issue and its often due to people thinking certain arguments are solely subjective like for example, what color to use when (this argument of "its subjective" when in fact its merely uninformed applies to probably 99% of the design "bikesheds" we have). We tend to avoid this word, and provide direction when we see uninformed discussions - but also make sure, people realize that Drupal core development is not a 100% consensus driven process.

I don't see how identifying "bikeshed" will really help us progress issues, that seem to be blocked upon it. We should spend time investigating blocked issues, and unblock them - it seems like a separate problem.

What Bojhan said. Few issues are "blocked on a bikeshed", rather, we're unwilling to differentiate between opinion and fact. (This is a modern world problem in general, sadly.) Lack of structure and lack of willingness to say "no, what you're saying is not true, sorry if it's your opinion but you're just wrong" lets way too many issues get killed by over-discussion.

I like the deadlock described in #12.

What we're interested in is not actually defining "bikeshed", but having a way to identify deadlocks that needs to be unblocked.

I think the list in #12 could be complemented by something subjective, too. It might be valid to say that an issue has been deadlocked if people in it feel so. This addition might be unnecessary, though.

I agree with Bojhan that trying to define bikeshed is not going to help much.

I do think it's worth finding specific examples of issues that are/were blocked, and how they were either resolved (or not), and the ways in which that happened. From that, it's possible to look at patterns that work and don't work.

To get that started, a recent and quite painful one:

#1240138: Adopt PSR-0 namespace convention for core framework classes
#1290658: Move all module-provided classes to PHP namespaces (PSR-0 or similar), and autoload them without the registry [policy, no patch]
#1467126: PSR-0 namespace auto registration for modules

In this case one or more threads were open with conflicting proposals and a fair degree of deadlock and frustration.

A new issue was opened just for implementation, picking the least controversial of the proposals.

That patch was committed, while the discussion in the deadlocked issue was still ongoing (but also assigned to Dries to make a final decision).

Dries eventually updated the deadlocked issue to confirm he was fine with the committed patch, and closed it.

This is a variation of the 'let's open a bikeshed issue to discuss that bit' side-issue stuff, it took a long time to get to that course of action, probably the same tactic could have been used a lot earlier.

Also there's the 'revisit before release' tag, not all of these were blocked issues, but it's being used for postponing conversations about PHP version requirements, IE8 support until such a time where there's less room for speculation about what the situation will be like when 8.x is released. http://drupal.org/project/issues/search/drupal?issue_tags=revisit+before...

That allows potentially long and drawn out discussions to be paused for a few months, but with the guarantee they won't be punted on forever (or at least, an explicit decision would have to be taken to punt on them until 9.x).

I came across this issue today and have read all the comments.

I joined the community around the time this issue was created. I leaned what 'bikeshed' means by reading issues. I also probably asked someone as well. If my experience if anything to go by a definition is not needed.

The point catch makes is helpful. That is, to identify the different methods that successfully moved an issue forward. And two techniques are mentioned in his comment. Both of those, delaying an issue in some fashion and splitting the issue up into workable chunks I have seen on numerous occasions. That suggests to me that there is sufficient knowledge in the community to deal with bikeshedding behavior.

Is there a need to review issues to find that that are blocked on bikeshed behavior "that must be unblocked for the health of our product or community". I think not. Using my experience with the Bug Smash Initiative I know that this would be a time consuming task. I think people's time would be better used in other ways to help Drupal. And while that initiative is for bugs, we have triaged 5,174 issues and in all those there were very few that had any significant bikeshedding going on. I image that there would be more opportunity in Feature Requests or Plans for someone to bikeshed, so one could say that those be reviewed. But that brings me back to the amount of work required, which I think is not a good use of our people.

This issue was opened 11 years ago and 10 people have commented, the last one also 11 years ago. The lack of further discussion and support for defining bikeshed is an indicator to me that the community has adapted and learned how to handle this. And follow on from that, It is up to all of us to continue to help new comers to learn how we approach this.

Therefor, I am closing this as outdated.