allow users to select another user to follow/watch

[Micah Gersten]

This would be a nice feature especially when mentoring a new bug triager. It should be similar to bugzilla where you get a copy of the person's E-Mails from the system. Obviously a user should only get one copy of a bug report.

Would also be nice to get a header telling you which user you are shadowing to help with filtering bug e-mail. Another feature that could help with the filtering would be to be able to specify an alternate e-mail address. For example, if my gmail account is <email address hidden>, I might want the e-mail directed to <email address hidden>.

[C de-Avillez (hggdh2)]

This can actually be used in more places than just triaging, of course. This is something I really miss from bugzilla.gnome.org.

Holding myself hard *not* to confirm this one. I want to. I think it is good.

[C de-Avillez (hggdh2)]

Cannot resist. Confirming.

[Eleanor Berger (intellectronica)]

I don't think this is something we're interested in doing at this time.

[Brian Murray (brian-murray)]

I wonder if closing this as "Won't Fix" is the right thing to do since it removes it from default searches. While the Canonical Launchpad team might not be interested in doing it, isn't it possible someone else might want to? I'd think leaving it open so others can find it and possibly work on it while giving it a wishlist priority would make sense.

[Eleanor Berger (intellectronica)]

2009/8/17 Brian Murray <email address hidden>:
> I wonder if closing this as "Won't Fix" is the right thing to do since
> it removes it from default searches.  While the Canonical Launchpad team
> might not be interested in doing it, isn't it possible someone else
> might want to?  I'd think leaving it open so others can find it and
> possibly work on it while giving it a wishlist priority would make
> sense.

The problem is not that we can't schedule the work on adding this
feature right now, but that it's not clear at all how such a feature
should be implemented. The bug is not going away - if anyone wants to
work on specifying how this should be implemented they can do it and
we can help. Once that's done, we can re-open this bug and see who can
pick up the work.

[Björn Tillenius (bjornt)]

On Mon, Aug 17, 2009 at 10:23:05PM -0000, Tom Berger wrote:
> 2009/8/17 Brian Murray <email address hidden>:
> > I wonder if closing this as "Won't Fix" is the right thing to do since
> > it removes it from default searches.  While the Canonical Launchpad team
> > might not be interested in doing it, isn't it possible someone else
> > might want to?  I'd think leaving it open so others can find it and
> > possibly work on it while giving it a wishlist priority would make
> > sense.
>
> The problem is not that we can't schedule the work on adding this
> feature right now, but that it's not clear at all how such a feature
> should be implemented.

That's fine. A bug should be Triaged when the main problem is
understood. It doesn't mean that we know how to implement it.

> The bug is not going away - if anyone wants to
> work on specifying how this should be implemented they can do it and
> we can help. Once that's done, we can re-open this bug and see who can
> pick up the work.

Marking a bug as Won't Fix does make it go away. Won't Fix means that we
won't ever do this, not even if someone does all the work and provide us
with a patch. Won't Fix is a final state; you shouldn't re-open a Won't
Fix bug.

It's ok to keep a bug as a use case only. We often do this, and think of
the implementation more in detail when it's getting time to actually
implement it. If the use case is unclear, we should ask more questions
and mark it as incomplete until the questions are answered.

[David Henningsson (diwic)]

We noticed on an UDS-M session that this bug is important and would be a very good feature for the bugsquad team / mentorship.