On Dec 8, 2009, at 3:17 AM, Bjorn Tillenius wrote: > It depends on what you mean with "auto-assign". I don't think the bug > should actually be assigned to someone, rather a team/person would be > responsible for a component, and would easily see which bugs he needs to > triage.
I do mean auto-assign to a person or a team. For example, if we had a mailing-lists component, we could auto-assign that to ~launchpad-registry. It would still be clearly not yet a single person's responsibility, but that team would get an email about the new bug and would then be able to easily triage it. It would help the other dev teams too, because they wouldn't (necessarily) get those emails. Of course, I might decide to subscribe to the code component because I find that interesting, so I'd get those emails too. >> * get an overview of the general health or velocity of a component >> * manage structural subscriptions on a component level > > All what you say can be done using tags. For example, one thing we want > to do is to offer structural subscriptions for tags. Seeing the general > health or velocity for a tag would also be useful, and whan you have tag > subscriptions, the auto-assign kind of work (without actual setting the > assignee). > > So, again, what value does adding yet another data structure add, rather > than to improve the way tags work? Well, I'm not actually sure there's much of a difference! I don't think components necessarily requires a different data structure. They could be implemented something like tags. One way to look at it is that "official tags" is just another term for "component". The advantage of components is that it's a controlled vocabulary defined by the project administrators, while general tags are uncontrolled and allow for the community to define emergent properties. There would be an important distinction made in the user interface however, and to me, that's the key thing. >> 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. Components can help this if done right. For >> example, sometimes I care about things project-wide, other times I care just >> about a particular component. Sometimes I care about my own personal >> artifacts, other times I want to see a community-defined slice through them >> (e.g. tags). > > You could substitute "component" with "tag" in the paragraph above, no? > Or rather "official tag", which aren't community defined. Right. >> Using tags mixes too many orthogonal concepts together. For example, it's >> kind of silly to have tags like mailing-lists, ui, and trivial. They're >> great >> for letting community-driven organization emerge organically though. > > Why is it silly? 'ui' I can understand, it's way way too broad, or at > least the way we've used it is silly, since it basically meant that a > bug needed some ui changes, which a lot of bugs do. I guess the point is that there are really two separate namespaces here. One narrowly controlled by the project administrators and displayed visually distinctly from the other, which is pretty much free-form. -Barry _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
