launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #01988
Re: process experiment proposal - move all our bugs to launchpad.net/launchpad
Barry Warsaw wrote:
> On Dec 07, 2009, at 11:55 AM, Tim Penhey wrote:
>
>>> My hunch is that people are already using tags in an almost rigorous
>>> way to model this.
>> Yes we do, but I think we should still look to add components at some stage.
>
> I agree. I don't think tags are actually the right fit for this, though
> they're the best we have right now. Some things you could do once you have
> proper components:
>
> * auto-assign bugs in that component to a person/team for triage
+1. This is a huge benefit IMO given my experience with JIRA.
> * get an overview of the general health or velocity of a component
> * manage structural subscriptions on a component level
>
> One of the reasons why I think project groups and projects doesn't work is
> because Launchpad isn't agile enough to let you narrow and widen your focus
> easily based on your task.
Perhaps. I think it comes back to release granularity:
* all parts of a single project are released simultaneously
* that constraint doesn't hold for project groups.
Partitioning is the #1 tool there is for managing large lists. Once a
bug list gets over 100, my brain (and probably many others) is too small
to keep it in my head. Components really help break issue lists up into
manageable subsets.
Of course, once components are supported, one still needs to be smart
about deciding how to use them. I've got that wrong several times too.
In the end, I realised that you need to ensure that the components comes
from the end user's viewpoint, not the technical architect's one. :-)
Ian C.
References