launchpad-dev team mailing list archive

[Bjorn Tillenius <bjorn@xxxxxxxxxxxxx>]

On Fri, Nov 27, 2009 at 09:11:13AM +1100, Robert Collins wrote:
> On Thu, 2009-11-26 at 23:55 +0200, Bjorn Tillenius wrote:
> 
> > > The experiment would be a success if it becomes easier to see the
> > > overall launchpad bug priorities / more awareness of other subteam
> > > priorities and issues.
> > 
> > Just a quick question before I go to sleep. Why do we have to move the
> > bugs? That's rather disruptive, and not easily undone, and will cause
> > some confusion.
> 
> Its easy to do and undo! Seriously, it is.
> for project in projects:
>  for bug in project.bugs:
>    if bug not in launchpadproject.bugs:
>       output_bug()
>       move_bug()

How do you deal with bugs that are targeted to multiple LP projects?
What about e-mail notifications?

Anway, that's not so important. It's the disruptive part that is. I've
spent a lot of time fine-tuning my e-mail filters for bug notifications.
If you do this experiment, you're going to force me to do that again. I
won't do it at once, I know that from experience. There will be a period
where I basically ignore bug notifications, since it's not possible to
follow them. Maybe we need to make everyone's life a pain to make
progress, but the question is, is it worth it? I'd like us to refine the
purpose of this experiment first.

This is a really expensive experiment, since it will totally disrupt
people's current workflow; they have to come up with a new one. People
have already found the need to get a more focused view of the project's
bugs. I don't think we have a good alternative at the moment. We
currently use projects to do the filtering, but by doing this
experiment, we problably would switch to filtering on tags instead.
Practically that doesn't make any difference. People would probably do
what they did previously; it would just take a while to get there, and
some other (like milestone) tracking for a team would be lost.

Personally, I think a more useful experiment would be to try out
different hypothesis, which doesn't make the whole team unproductive for
a few cycles. One hypothesis is that we need to get views for a single
team. Let's implement views for teams for milestones, assigned bugs,
subscribed bugs, and so on. Then have one team try it out and see how it
works. We could do this in /launchpad-project, since this feature should
work for both projects and project groups.



> 
> > Why not simply use /launchpad-project instead? The bugs are already
> > there, providing a view across all projects. From your success criteria
> > it sounds like focusing on /launchpad-project would be enough, making
> > the experiment more lightweight to execute.
> 
> Two reasons - Launchpad isn't equally functional at the project-group
> scope, (e.g. series are not visible there).

Any other examples of lack of functionality? We don't currently use
series anyway, so I don't think that would matter.

> Secondly, we wouldn't get as
> much feedback if folk can individually opt-out rather than saying 'hey
> it really isn't working for me'.

Right. You will get much more feedback if force people to do something.
However, that makes this experiment very expensive. Not
implementation-wise, but in developer time. It will make people
unproductive in the beginning. So unless we have a really good goal, and
committment to get there, I think we should try with cheaper experiments
instead. We've done that in the past, where a team has committed to
trying something else. I think that has worked out quite well, without
forcing everyone to do it. Getting 30 developers to try something out is
hard. Getting a sub team to do it is easier. Why don't we make an
experiment, to see whether having an opt-out actually doesn't work? :)



-- 
Björn Tillenius | https://launchpad.net/~bjornt