ubuntu-bugcontrol team mailing list archive
-
ubuntu-bugcontrol team
-
Mailing list archive
-
Message #04168
Re: request to join ubuntu-bugcontrol team
* Alberto Salvia Novella (es20490446e@xxxxxxxxx) wrote:
> Alan Pope:
> >Assigning a bug to someone is one way to ensure we have someone
> > working on a feature/bug.
>
> ---------------------------------------
> WORK ON DESK IS NOT WORK GETTING DONE
> ---------------------------------------
>
> One person can work in one thing at a time: the rest of assigned
> work is just accumulated in a place that says "don't touch".
"don't touch" is too strong a way to read 'assigned'; it's
reasonable for a technically knowlegable manager to sort through
the fire-hose of incoming bugs and say 'they've got a good chance
of knowing how to deal with that'.
> Look, it told this same thing to the Ubuntu One developers five
> months before the project was closed. Nearly every bug had an
> assignee from Canonical, but nobody really was able to work on most
> reports.
An 'assigned' tag shouldn't stop someone else with an interest in
fixing the bug posting a question to the bug or asking the assignee;
what it does stop is 15 separate people all simultaneously trying to
solve the same bug, submitting it upstream and neither of the fixes
going anywhere.
Indeed it should be an indication that if you independently have
an idea of how to fix it that the assignee might be able to help
you get the fix incorporated.
> So this approach was making difficult to contributors to fix the
> software, as they were implicitly told not to do. As result the
> service was very flawed and gave very little monetary returns;
> because nobody was interested in, for example, their files to be
> wiped consistently or to be unable to access the service from the
> phone because the captcha being unreadable.
So that suggests the way people are reading 'assigned' needs fixing.
The only thing an 'assigned' should stop you doing is changing
priorities/importances etc - there's no way it should stop you
from proposing a fix on the bug (or upstream if you cc the
person assigned).
If you fancy working a bug that's 'assigned' then:
Make sure you cc the assignee to let them know that you
are looking at it and what your intended plan of attack is; so
the assignee can then tell you if they've already started fixing
it or if they're aware of another change that means it's not
a good way to fix it.
(I don't work for canonical but I work for another org where my
manager assigns public bugs to me - I'm also free to pick my own
as well)
Dave
>
> In fact I reported a step by step guide on how to make Ubuntu One to
> wipe files by accident, what had being happening to me for two
> years, and a bug this critical never got fixed; just it got very
> soon someone saying to be working on it.
>
>
> ---------------------------------------------
> THINKING FOR EVERYONE IS BLOWING YOUR MIND!
> ---------------------------------------------
>
> Instead of assigning the work to the person who knows how to do it,
> better to make obvious how it can be done; so anyone can take it and
> you get as much work-force as possible. And let the specialist come
> in only if there's a very atypical irregularity.
>
> Good management is not about assigning tasks, but about empowering
> people. So it is more related with training and building smart
> systems, than with administration.
>
>
> That's all! Now I will have my gazpacho, Popey.
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ubuntu-bugcontrol
> Post to : ubuntu-bugcontrol@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-bugcontrol
> More help : https://help.launchpad.net/ListHelp
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux | Happy \
\ gro.gilbert @ treblig.org | | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
Follow ups
References