"Also affects project" is inconsistent and obscure when in package context

[Scott Kitterman]

1. From <https://staging.launchpad.net/ubuntu/+source/mercurial/+bug/223789>, try to record the bug as needing to be fixed in the "edgy-backports" project.

What happens: When you click "Also affects project", the resulting page <https://bugs.staging.launchpad.net/ubuntu/+source/mercurial/+bug/223789/+choose-affected-product> is completely different from the usual one (that you would get, for example, from <https://bugs.staging.launchpad.net/hardy-backports/+bug/223789>). Because people naturally look at the form fields first, skipping over any non-form text, it is very difficult to find how to specify a different project.

What should happen: The "Also affects project" link should display the same form regardless of context. Suggested upstreams should be radio buttons added to the usual form, rather than a completely different form.

From #ubuntu-devel:
[15:54] <maix> > So far it's not been requested. It would have to be requested (use also
[15:54] <maix> > affects to add gutsy-backports) and them tested on gutsy.
[15:54] <maix> (https://bugs.launchpad.net/ubuntu/+source/mercurial/+bug/223789)
[15:54] <ubottu> Launchpad bug 223789 in hardy-backports "Please backport mercurial 1.0.1-2 from Intrepid to Hardy" [Wishlist,In progress]
[15:54] <maix> i cannot find such a link/option there
[15:55] <ScottK> See where it says "Also affects project" right under mercurial(ubuntu)?
[15:55] <ScottK> Click on that.
[15:55] <maix> yes?
[15:55] <maix> (i've tried that but it did not seem to be the right thing to me :)
...
[15:56] <ScottK> Yes. Actually you need to do that from https://bugs.launchpad.net/hardy-backports/+bug/223789
[15:56] <ubottu> Launchpad bug 223789 in hardy-backports "Please backport mercurial 1.0.1-2 from Intrepid to Hardy" [Wishlist,In progress]
[15:57] <ScottK> Then when it asks you about the affected project say gutsy-backports.
[15:58] <ScottK> maix: Does that work better?
[15:58] <maix> yes
[15:59] <ScottK> Feel free to discuss the user-friendly U/I in #launchpad. My thoughts on the matter are well known.
[15:59] <maix> but that's very confusing, why are there completely different options if i access the same bug by a different url
[15:59] <ScottK> That's a good question to ask in #launchpad.
[16:00] <maix> ok then i can guess what your thougts are :)

The only way I could find to get to the hardy-backports URL from the ubuntu/+source/mercurial URL was to hand type it in and there was not a way to add the package to gutsy-backports from the ubuntu/+source/mercurial URL.

Something less opaque would be nice.

(See also bug 1334.)

[Matthew Paul Thomas (mpt)]

That's bizarre.

[Björn Tillenius (bjornt)]

On Fri, Jul 04, 2008 at 11:45:13AM -0000, Matthew Paul Thomas wrote:
> That's bizarre.
>
> ** Changed in: malone
> Product: Launchpad itself => Launchpad Bugs
> Importance: Undecided => High
> Status: New => Confirmed
>
> ** Summary changed:
>
> - No apparent way to report bug affecting another project
> + "Also affects project" disallows adding a project depending on context

This is not correct, you can add any project you want from
https://bugs.launchpad.net/ubuntu/+source/mercurial/+bug/223789.

I think this is simply a UI issue. Suggestions on how to make it
clearer is appreciated. If you choose "Also affects projects" from a
source package, we automatically choose the project for you, if there
are packaging links. This is because it's very common to say that a
package bug affects the corresponding upstream project as well.

On the "Also affects project" page there is a way to choose another
project. There is a "Choose another project" link.

    subscribe bjornt

[Scott Kitterman (kitterman)]

Right but the wanted project in this case is gutsy-backports. Trying also
affects project from the package link gets you to the standard LP
gobbledgook about registering the upstream project for mercurial.

Did you actually try this before assuming the bug is wrong? I went through
a period of not bothering to report launchpad bugs because I thought it was
pointless. I recently decided to give it another try. Perhaps I'm wasting
my time.

Just to make sure I wasn't ranting pointlessly, I went and checked again.
My primary method of launchpad navigation is still typing urls and using
browser history completion. In this case I don't know how to add
gutsy-backports (feel free to add edgy-backports as a test since the
project is obsolete) without typing urls. It's not just faster, it's the
only way to do it.

[Björn Tillenius (bjornt)]

On Fri, Jul 04, 2008 at 02:21:40PM -0000, Scott Kitterman wrote:
> Right but the wanted project in this case is gutsy-backports. Trying also
> affects project from the package link gets you to the standard LP
> gobbledgook about registering the upstream project for mercurial.

Sure, but as I said, there is a "Choose another project" link there.

> Did you actually try this before assuming the bug is wrong? I went through
> a period of not bothering to report launchpad bugs because I thought it was
> pointless. I recently decided to give it another try. Perhaps I'm wasting
> my time.

I didn't actually try it, no, I only looked at the pages. But to make
you happy, I've now added edgy-backports on staging. This was my work
flow:

    1) go to
       https://bugs.staging.launchpad.net/ubuntu/+source/mercurial/+bug/223789

    2) click on "Also affects project"

    3) click on "Choose another project"

    4) replace "hg" with "edgy-backports"

    5) press "Continue"

    6) press "Add to Bug Report"

(this may seem a bit awkward workflow, but the only extra step here is 2) )

[Scott Kitterman (kitterman)]

But the title of that section is "Confirm project". So what it is asking for
is for me to confirm the correct project for upstream, which gutsy-backports
is not. Thus leading the user to believe that it can't be done from there.

So, because you KNOW that the selection does something other than what it
says, you can get there. For us mere mortals without NDAs, it's a dead end.

[Björn Tillenius (bjornt)]

On Fri, Jul 04, 2008 at 03:18:09PM -0000, Scott Kitterman wrote:
> But the title of that section is "Confirm project". So what it is asking for
> is for me to confirm the correct project for upstream, which gutsy-backports
> is not. Thus leading the user to believe that it can't be done from there.
>
>
> So, because you KNOW that the selection does something other than what it
> says, you can get there. For us mere mortals without NDAs, it's a dead end.

If you read my first comment, you see that I suggested that this is a UI
issue. It's possible to add another project, but it's not obvious.

[Scott Kitterman (kitterman)]

On Friday 04 July 2008 11:33, Björn Tillenius wrote:

> If you read my first comment, you see that I suggested that this is a UI
> issue. It's possible to add another project, but it's not obvious.

The fundamental problem is that you get driven to a page that's about picking
the upstream project for the package when you wanted to select a project
affected by the bug. The entire "force the end user to figure out where
upstream lives before they can do something useful" model is really inside
out.

OK. It is possible. It's not only not obvious, it's completely opaque. That
link looks entirely like you are selcting a different upstream project for
the package, not the bug.

Driving someone who is trying to work on a bug to a package level selection
page is just broken and that's more than U/I.

[Matthew Paul Thomas (mpt)]

Björn, I'm sorry I thought that this page didn't allow choosing a different project from hg. The reason I thought that is that *there is no field* on the page for choosing a different project from hg.

First, in this situation I don't want to "choose another project". I don't want to add upstream hg at all, with another project or without. I want to choose a *different* project.

Second, it took me a full 20 seconds to find the "Choose another project" link, even after I knew -- from the comments in this report -- exactly what text I was looking for. I was expecting it to be the label for a text field, but it isn't, and I don't see why it shouldn't be. This wasn't helped by the form being so wide (bug 220529) that it's partly hidden under the irrelevant Actions menu (bug 243259).

Third, even once I clicked "Choose another project", the field defaulted to "hg". Launchpad is making an extra special effort to do completely the wrong thing here, because by this point it knows for certain that hg is the one project I do NOT want to add.

[Fred (frederic-lespez)]

I was trying to indicate that another ubuntu packages was affected by a bug.
After several tries and searches, I found out that you need to use "Also affects distribution" and not "Also affects project" (it seems be made only to add upstream projects).
I am just adding this comment to help others users since :
 - Launchpad help (https://help.launchpad.net/Bugs/MultiProjectBugs) is really not clear on this point
 - current interface is misleading: In "Also affects project", "project" seems to designate an upstream project. The Launchpad homepage says that "ubuntu" is a project, but you need to use "Also affects distribution" to indicate that bug affect another package of "ubuntu"
 - it is really easy to find this bug report with a web search or Launchpad itself

[Robert Collins (lifeless)]

I'm tagging this bridging-the-gap tentatively, it seems like its closely related to that effort.

[Curtis Hovey (sinzui)]

I removed bridging the gap because I think there is a larger issue here. The page really is confusing. The heading really is bad, the form is obfuscating import information. I think the intent of this form is to setup a bugwatch, but in the hg example, it is contradictory -- why can I provide a email address when hg's bug tracker does not use one. This layout might be better

Affects upsteam project

Affected Project
(*) _hg_
( ) Other [ ] (Choose)
( ) Register an upstream project for this package

Upstream bug
(*) I have the URL for the upstream bug:
( ) I have already emailed an upstream bug contact

[Thibault D (thibdrev)]

I confirm that this is confusing : I don't really get how to tell launchpad that another package is affected by an existing bug...