No way of deliberately requesting someones input in a bug

[Ursula Junque]

In projects/packages with a high volume of bugs, it's impracticable to follow up every comment through a mailing list, so people usually assign the user they want input to the bug. That's pretty much abusing the tool, because:
 - as it may imply that the "pinged" user is the one responsible for the discussion to continue, but that's not necessarily true, neither most of the cases; Also more than one person's input might be required.
 - there are a lot of workarounds to filter bugs in launchpad, it would be good if we could tell bugs are being taken care of by checking if they're assigned to someone (like launchpad team does).
 - we could change bug's description with something parseable, but that would be yet another addition to the description which will become unmanageable soon.
 - <add your own reason here>

A button with "Request user's input" that shows a person picker and send him an email requesting input might work fine.

[Deryck Hodge (deryck)]

So I have some questions about this that make me not sure how to triage it.

Do people really still assign people to bugs as a means of requesting input? I thought we fixed the bug tracker so you can only assign yourself unless you're the bug supervisor.

Also, I assumed practice would be to subscribe someone and ask a question directly. Is this not the case? If it is, how is this breaking down due to large numbers of bugs. I know I get my mail differently when directly subscribed. But I do recognize that I don't get the same volume of mail as Ubuntu devs.

I'm not disputing this is an issue for Ubuntu devs. Just wondering if we really need to change Launchpad or if subscriptions are enough and a cultural/process shift is required.

[Martin Pool (mbp)]

On 17 August 2011 01:31, Deryck Hodge <email address hidden> wrote:
> So I have some questions about this that make me not sure how to triage
> it.
>
> Do people really still assign people to bugs as a means of requesting
> input?  I thought we fixed the bug tracker so you can only assign
> yourself unless you're the bug supervisor.

Yes, I believe this does happen: in unity-related things people assign
the bug to the design team to request a decision from them. I think
it's also done for verification but I can't recall which team does
that.

> Also, I assumed practice would be to subscribe someone and ask a
> question directly.  Is this not the case?  If it is, how is this
> breaking down due to large numbers of bugs.  I know I get my mail
> differently when directly subscribed.  But I do recognize that I don't
> get the same volume of mail as Ubuntu devs.

I think the problem is that mail generated from directly-subscribed
bugs doesn't look very different (except in the headers?) from mail
you receive through other means; also you cannot(?) easily search for
bugs to which you're directly subscribed.

If you could include a message when subscribing someone that might
help make it semantic rather than just noise.

A very similar case comes up in code reviews where you want to ask for
specific attention from someone who may already be subscribed, and I
suppose also answers and blueprints.

[Deryck Hodge (deryck)]

I thought we did send an email to the effect of "You have been subscribed to this bug by Foo Bar" to help it stand out. Maybe that's broken again?

At any rate, I'll mark this a low bug to track that we have some issues still to address with requesting a user's input. I think it's hard to solve this nicely for every case, though, which is why I tend toward preferring each project coming up with there own process for dealing with this. When you get a lot of mail, well, you get a lot of mail. :) And just adding a different kind of mail may not really be the solution, even though it seems nice at first. But I understand we could perhaps do something to give projects more flexibility in crafting their own process.

[Brian Murray (brian-murray)]

The body of the email does say that for example:

'You have been subscribed to a public bug by Ursula Junque (ursinha): '

[Bryce Harrington (bryce)]

> Also, I assumed practice would be to subscribe someone and ask a question directly. Is this not the case? If it is, how is this breaking down due to large numbers of bugs. I know I get my mail differently when directly subscribed. But I do recognize that I don't get the same volume of mail as Ubuntu devs.

It certainly is possible to set up mail filter rules to promote subscription bugs, but this assumes the person in question has taken the time to set it up; often they haven't, and so the subscription emails end up in their general launchpad email pool (which in Ubuntu's case can be rather large.) So it doesn't seem to work reliably in practice.

The established practice in Ubuntu now is rather than subscription, to assign to the appropriate Canonical team. This puts the bug on that team's weekly agenda to review and assign out accordingly. This seems to work quite reliably in practice. But it's not intuitively obvious as a regular reporter that this is what you're supposed to do.

Ursula's right that this is a clumsy process.

It seems that subscription is used for three purposes: a) bugs that affect me, b) bugs I want to bookmark to follow, and c) bugs someone needs my input on. Perhaps rethinking how these three different cases are handled would be worthwhile?

[Robert Collins (lifeless)]

FWIW the assumption that mail is involved seems to be flawed to me:
 - if we imagine a dash in LP with 'things you should do', that could
(right now) include:
 - bugs directly assigned
 - code review directly requested
 - blueprints directly assigned, or direct sign-off

and 'things your teams should do':
 - archive queue admin
 - bugs assigned to teams
 - code review not yet claimed
etc

It seems plausible to me that 'request input' is a useful concept for
bugs ('is the proposed approach right?', 'can you please confirm that
X happens'), code review (as a super-set of 'request review'),
blueprints ('its time for the sign off now please'), distro queue
processing ('please explain where you want XYZ binary to go'),
projects ('X looks like proprietary code, can you please either make
it open or buy a subscription'), and so forth.

-Rob

[Brian Murray (brian-murray)]

Related to this to some degree is bug 834908 which is regarding how the body of the assignment / subscription email is unclear and missing information.

[Brian Murray (brian-murray)]

Which therefore makes it harder to request in someone's input.

[Bryce Harrington (bryce)]

I like robert's proposal of having a way to itemize things you need to attend to.

It is possible that this bug is a sub-case of needing a "task management/workflow" type system. We currently have a lot of makeshift task tracking systems implemented throughout launchpad, using tags, team subscriptions, blueprint work items in the whiteboard, status misuse, bug task abuse, and so on; would be nice to have a more general purpose solution.