launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #01852
Re: process experiment proposal - move all our bugs to launchpad.net/launchpad
2009/11/26 Robert Collins <robert.collins@xxxxxxxxxxxxx>:
> ... I believe the current partitioning of bugs is harmful to our team responsibility - it drives
> the need to do things like action groups to work on tasks, because tasks
> are not globally visible to the whole team by default.
I have a feeling that you may be right when you observe that our
processes sometimes hurt team responsibility, but before we conduct a
pretty expensive experiment, I think we should ask what concrete
problems are we trying to solve. Team responsibility is a very vague
term. My feeling of team responsibility fluctuates several times
within the same day, and all that without experimenting with changing
the infrastructure we use. If we were to hold the experiment I would
not be able to tell you whether it is successful or not.
* As a Launchpad Bugs developer, I want to know of any activity that
is in direct responsibility of the bugs team as soon as it happens, so
that I can respond to questions and help triage and coordinate the
work on bugs.
This story works fine now. I subscribe to all bug mail for malone and
several other projects I feel personally responsible for. Moving the
bugs out of the sub-project would bleed this story for me, since I'll
have no way to tell these bugs from other Launchpad bugs I can't help
much with. We could work around this by making it possible to
subscribe to a tag (which is arguably a more powerful mechanism).
* As a Launchpad developer, I want to be able to get an overview of
the current state of bugs in the whole of Launchpad, so that I can
learn about the activity of other teams and consider helping when I
can.
This story is sort-of covered by the project group, but there are some
missing pieces.
These stories are quite high-level, and they suggest to me that
concentrating on making the project group work for us might be more
effective. I really think we should attempt to outline some more
specific use cases first, though (and I promised to do just that when
I'm less tired). Also, I'm sure the user stories for people with other
roles will be different.
Tom
References