[MeeGo-dev] Poor decision making in MeeGo, again ...
michaelh at openismus.com
Tue Jun 28 16:43:45 PDT 2011
I wondered why bugs for our component, the virtual keyboard, were moved
to newly created components without prior announcement, nor
Turned out it was the execution of BMC#19369. Now, starting to move bugs
to entirely new components without asking/commenting is somewhat rude in
itself, as it completely bypasses the triaging efforts of the original
bug component owner.
If I hadn't been informed about above bug by accident, then I would have
thought that someone is using MeeGo's bugzilla as a personal playground
for new ideas. Not cool.
Actually, a good way to piss off your contributors, since you just broke
my (developer's) workflow. Again.
Hiding behind your bosses as in:
"especially this is actually requested by MeeGo lead engineers and
simply doesn't work here. This is not your typical corporate,
I-dont-want-to-think-for-myself environment. *You* take the
responsibility for *your* actions. Always.
Discussing this issue on the relevant mailing list (Read: Where the
developers are. Hint: It's not the QA ML) would have been the minimum
And once a decision is made, you also need to publicly announce it. No
you cannot expect me (or anyone else who is *not* in your QA team) to
read your miles-long thread on your QA ML
really have more important stuff to do (like, uh, actually fixing bugs
for you so that your QA work stays relevant). I want the executive
summary. Again, minimum requirement for stuff that potentially affects
everyone contributing to MeeGo. You could have used news.meego.com even.
If we see MeeGo as an open community then we'd better start to act
accordingly. This seemingly arbitrary decision-making (followed by
top-down no-questions-asked execution) needs to die.
Michael (who wasn't amused when he couldn't find certain input method
bugs any longer)
More information about the MeeGo-dev