4 ms·
I think if someone gets mad or ignores someone because they claim that the other person is bikeshedding based on a single comment or suggestion, that's most lik
by mwfunk 10y ago
I think if someone gets mad or ignores someone because they claim that the other person is bikeshedding based on a single comment or suggestion, that's most likely a misuse of the term bikeshedding.
Bikeshedding is when an entire discussion gets bogged down or derailed by people who would rather talk about something that's not super relevant, than say nothing and let other people talk about a topic that's important but they personally have no expertise in. They would rather sidetrack a conversation so that they could be more involved, than sit back and let other people talk about the original topic.
This makes sense for social situations (where what you're talking about is usually far less important than keeping everyone engaged), but makes no sense for situations where the communication really is about solving problems. You can really see this tension on more developer-focused open source mailing lists, where often a small number of people are working really hard on evolving some critical software, but their discussions get drowned out or derailed by precocious teenagers/overconfident CS undergrads/bored retirees who are just killing time on the list as a hobby, and who expend lots of energy trying to get everyone to talk about how terrible the variable naming convention is (or the source file directory structure, or source file naming conventions, or how much they hate this or that open source Internet celebrity person, or what's the deal with airplane food...)
I can totally imagine someone who would dismiss as bikeshedding any comment that they didn't feel like talking about, but that person would be misusing the concept of bikeshedding (and probably being super rude on top of that, as it's an accusation against the presumed bikeshedder as well as a dismissal of what they're saying).
- gravypod 10y ago> I think if someone gets mad or ignores someone because they claim that the other person is bikeshedding based on a single comment or suggestion, that's most likely a misuse of the term bikeshedding. I just see this as a way to justify that behavior. If it's not the indented use for the term then I agree some things are stupid but things that people I've worked with have cared about have came from real world concerns they have about technical choices. Maybe I'm just lucky? > but their discussions get drowned out or derailed by precocious teenagers/overconfident CS undergrads/bored retirees who are just killing time on the list as a hobby I think most of this can be sifted out easily. Why is X objectively better for the project as a hole? I've had project's where people have said "change this! change that!" For instance I was asked for one project, my StarmadeWrapper project, to look for a server in a different path then the one I had been checking. For instance I was checking "./StarMade/" for the .jar and they wanted me to check "./starmade" for the .jar. I said that it wasn't needed because it would break already setup servers and that it was already possible by editing the config file. They couldn't provide a reason for that to be done so I ignored the people suggesting this. This was a compatibility breaking change that could already be done on the side of the end user and fixed what amounted to making the end user run "mv ./StarMade ./starmade -r". This is in stark contrast to something else I was asked. Someone wanted me to make a maven .pom file for my project. At this point this person was contributing to the project and he made his case that "it would make it easy to import the project". I told them if you want it implement it since hell, it was a single file! These are the filters I apply to suggestions: - Does this make sense in a technical light - Does the person who is asking for this have the ability to write it by themselves - Will it break compatibility - Is it better then what I do currently The second change was technically sound, this person was a maintainer, it wasn't going to break anything, and it provided an easy way to work on the project. The first situation was none of these things.