launchpad-dev team mailing list archive

[Bjorn Tillenius <bjorn@xxxxxxxxxxxxx>]

On Wed, Dec 02, 2009 at 10:23:46AM +0000, Jonathan Lange wrote:
> On Fri, Nov 27, 2009 at 5:55 AM, Bjorn Tillenius <bjorn@xxxxxxxxxxxxx> wrote:
> > On Fri, Nov 27, 2009 at 08:20:45AM +1100, Robert Collins wrote:
> >> Is it feasible?
> >> ---------------
> >>
> >> Launchpad-project has 5800 bugs, and ~30 developers, or about 19 bugs
> >> per developer. bzr (core, not plugins) has 1800 bugs, and <10 developers
> >> developers, or about 18 bugs per developer. bzr hasn't split its bug
> >> database and the developers manage to get things done quite
> >> successfully :)
> >
> > I actually don't think that number or bugs in total, or number of bugs
> > per developer is that important. It's like you say, 1800 bugs isn't
> > that different from 5800. Sure, 3 times more,  but we also have three
> > times the developers. What's important is the number of developers.
> > Coordinating the work for 30 developers so way way much harder than
> > coordinating the work for <10. It's not 3 times harder; it's more than
> > that. That's why we divide the LP team into sub teams, so that the
> > coordination work actually gets feasible to do.
> >
> 
> I agree that we need to be able to coordinate work by teams smaller
> than "all the Launchpad committers".
> 
> However, I do think that ideally, we'd be modelling this by using
> teams. At the moment, we are modelling it with projects. I don't think
> there is any real sense in which, malone say, is a separate *project*
> from registry. It grates on me that we model it that way in Launchpad.
> Ideally, we'd have one project (launchpad) and many teams, and work
> could be coordinated through teams. Would you agree with this?

Yes, I definitely agree. What we really need is more tracking around
teams. At the moment, using a project is the best way of doing that.


> I think the next questions about whether the benefit of changing is
> greater than the cost, whether we can do a cost-effective experiment
> and what are the next actions are all interesting, but kind of futile
> to discuss unless we know where we stand on the first question: what
> would the ideal set up look like?

My point is that we don't really need an experiment at this point. We
already have a good idea of what needs to be done. I think the first
step is to implement tracking around teams that work both for project
groups and for projects. Then we can try it out ourselves, and when we
see that it somewhat works, we can switch to using one project only.

Maybe the first thing to do is to look at the milestone listing for a
project group, and see how we can change it to limit bugs that are a
specific team's responsibility.

Another thing we need to do is to make it easier to filter bugs by tags.
Tags could be a general solution here, actually. If all the listings
were able to filter by tags, we could use a tag to indicate that a
certain team is responsible for it. Anyway, I don't know exactly how
things should work here. Someone needs to spend time to look at our
current workflow and the current UI, and see how it should be modified.


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