"Subscribe Someone Else" should be restricted to drivers of relevant software

Bug #58410 reported by Matthew Paul Thomas on 2006-09-01
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself

Bug Description

"Subscribe Someone Else" is similar to signing people up for mailing lists they didn't ask for. The sabdfl says, "it should be limited to being done by people with responsibility in the project".

In practice this means that "Subscribe Someone Else" should be available only to maintainers/drivers for the products/distributions that the bug is recorded as affecting.

Matthew Paul Thomas (mpt) wrote :

Context: Mark's suggestion was an alternative to my proposal that "Subscribe Someone Else" should be replaced by the ability to forward a bug report to someone from the Web interface (analagous to clicking Forward from an e-mail client, but with bug description included). But leaving unprivileged people with neither the ability to forward *nor* "Subscribe Someone Else" might be a bit annoying.

Changed in malone:
importance: Untriaged → Low
status: Unconfirmed → Confirmed
fantasai (fantasai) wrote :

I have frequently CCed other people on bugs in Bugzilla while triaging: e.g. the relevant developer for a particular type of bug, or the relevant standards expert, etc. Taking this out of the bug system would make a worse mess out of their inboxes since random emails "you should look at bug XXX, here's the summary copy-pasted for you" are harder to track and filter. I suggest WONTFIX.

Caroline Ford (secretlondon) wrote :

We need to be able to find the useful people to subscribe amongst a list of everyone on launchpad. Teams would be useful - for example if you search for "laptop" you get people who have called themselves laptop. If you add laptop into the box without searching it defaults to a user with no karma called laptop. I wanted the ubuntu-laptop team..

Looking for english localisation teams took ages because there is so much rubbish in there. 99% of entries will/should never be subscribed by others.

Emmet Hikory (persia) wrote :

This change would break the workflow for MOTU-hopefuls, and -core-dev-hopefules, who are expected to subscribe ubuntu-universe-sponsors, and ubuntu-main-sponsors in order for their patches / uploads to be reviewed. Perhaps each team should rather have a preference "Allow others to subscribe bugs to this team", with a default of "No". This would allow both protection of mass bugmail for inappropriate teams and the continued use of teams for approval workflows.

Matthew Paul Thomas (mpt) wrote :

Emmet, I've previously suggested that you should be able to do a one-time forwarding of a bug report to a person/team, instead of subscribing them. Would that be sufficient for the teams you talked about?

Being one of the u-u-s people, i'd suggest restricting it to members, or bugsquad, or something. It's very useful to be able to subscribe the relevant person, eg with the canonical commercial repository, or whatever, where you dont know what the package is.

Emmet Hikory (persia) wrote :

I'm not certain about other teams where the docs indicate that subscription is appropriate (ubuntu-archive, ubuntu-main-sponsors), but informal polling of representatives from ubuntu-universe-sponsors indicates that https://bugs.launchpad.net/~ubuntu-universe-sponsors/+subscribedbugs is a meaningful part of workflow. I'm not sure what mechanism "forwarding" would use - perhaps another URL could serve this purpose.

William Grant (wgrant) wrote :

I think the only way this is likely to work is with the addition of an extra option for teams/people to allow/deny subscription by anyone. Breaking good workflows isn't a good thing, but neither is allowing Joe Random to subscribe some team to a lot of bugs.

still...random people adding random bugs to ubuntu-release isnt ideal either.

I wonder about a field on the teams page that says "allow other people to subscribe bugs to this team" with defaulting to allowing. Teams seem to be worse than people, in this, just because of the sheer number of people on some of the teams. (yes, there are still some bugs that get wrongly assigned to ubuntu-qa and such.)

As a workaround at least, that's not such a bad idea. I think a default for "you cant subscribe others at all" isnt optimal.

Curtis Hovey (sinzui) on 2011-11-27
tags: added: bugs subscribers
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers