Don’t just stand around saying somebody should do something: Be someone

On one of the frivolous mailing lists in the Windows project, somebody spotted some behavior that seemed pretty bad and filed a bug on it. The project was winding down, with fewer and fewer bugs being accepted by the release management team each day, so it was not entirely surprising that this particular bug was also rejected. News of this smackdown threw the mailing list into an fit of apoplexy.

Don't they realize how bad this bug is? Somebody should reactivate this bug.

Yeah, this is really serious. I don't think they understood the scope of the problem. Somebody should mark the bug for reconsideration.

Definitely. Someone should reactivate the bug and reassert the issue.

After about a half dozen of messages like this, I couldn't take it any longer.

I can't believe I'm reading this.

I decided to Be Someone. I reactivated the bug and included a justification.

Don't just stand around saying somebody should do something. Be that someone.

(And even though it's not relevant to the story, the bug was ultimately accepted by the release management team the second time around because all the discussion of the bug gave the bug representative more information with which to to argue why the bug should be fixed.)

I always like to think of that 'someone' as the super hero who flies down and solves all devs problems as soon as they shout for it loud enough. She, too, is resigned to exist only in fantasy like the rest of the super heroes people wish for.

Which is different from, "Someone should change how this behaves." After yesterday of "rogue" features, someone learns that the proper way to change a behavior is to argue for it, convince others it's needed, find offsets in other features to schedule localization, documentation and testing, find enough pros to outweigh the cons.

Or i can decide i'm too exhausted to do all that again. It would have been a good change, but if i have to argue every step of the way: i give up, and let the system be design-by-committee.

(Apologies if I double post, the post button brought me back here without any indication of success or failure.)

Strangely, this reminds me of a restaurant I worked at while in college that served complementary dinner rolls to every table. On busy nights, many servers would loudly (and profanely) gripe about how there was no bread ready, and none was on the way. The thing that always struck me about it, was that those who griped the loudest were usually the last to actually do something to solve the problem (like putting bread in the oven, or ask for help). Back then, I would usually take on the "be somebody" role and take care of it. Looking back now, I wonder if by doing so, I actually perpetuated the problem.

If somebody had been somebody sooner, it would most likely have just been closed off again. This would have added weight to the closing off argument: "It's been closed twice already without being accepted for fixing…".

In this case, the preceding INaction was arguably necessary to the eventual success of the ACtion.

Sometimes these types of discussions are a way of verifying support for your position. Sure, *I* think it's important, but what does the rest of the team feel? If other people agree, I will gladly be "someone".

Btw, I think it follows "Poisson law of small numbers". So it's somehow unfair to say there's too few "someone" exist.

If there is someone already, chances are "something" is already done so you won't see people moaning. People's moaning, is easier to get into your radar than works silently be done.

Also, there's also some people who need to gather opinion from other people, verify that others also need the action, before deciding to perform the action. So arguably, I think "keep moaning and something could be done" is true in certain level.

@Simon: That's probably because quite a lot of code (open-source or not) is *scary* bad (or at least difficult to understand).

Also, issues of "ownership" sometimes get in the way. I can think of a few cases where something was identified as a problem, and someone even provided a patch to fix the problem (without negative consequences), but the maintainer refused to integrate it because "it wasn't important enough to write my own fix".

I think what's left unsaid in discussions like these is the fact that people don't want to be 'Someone' because that person will inevitably either become a scapegoat when things go wrong or, perhaps even worse, speaking up just means you'll end up getting the problem dumped in your lap to work on all by yourself.

Of course, in cases like these I like to turn to the knowledge I've gained from Mr. T: "Be Somebody, or Be Somebody's Fool."

These kind of discussions is usually a result of "politics" in the development environment. It's a signal of a bad work place. To be "somebody" WITHOUT making a scene is a guaranteed FAIL in these circimstances.

The developers complaining isn't really complaining about any specific bug or missing feature, they're complaining about how the ignorant management prioritize.