launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxx>]

2009/9/8 Tom Berger <tom.berger@xxxxxxxxxxxxx>:
>>>> "Also notified" has never had a clear meaning to me, maybe it means
>>>> "Implicitly subscribed" and should say so?
>>>
>>> Actually, I'm not sure one is better than the other. Will it really be
>>> clearer if we used the phrase you are suggesting? But I agree that
>>> this can be confusing to many users, so any suggestions for
>>> improvement are welcome.
>>
>> Maybe you can tell me what it means now, then we can work out a short
>> label for it?
>
> It means "People who will receive email despite not being directly
> subscribed to the bug, for one of several possible reasons, like have
> an important role in the project or being subscribed to all email for
> the project".

OK.

> The use case where you want to be sure someone will receive your email
> is, I think, more important. This conversation, though, makes me
> re-think the whole in-page subscribers list. Maybe it's not such a
> great idea to have it there. Let's think if we can come up with a
> better way of satisfying all the important use cases without showing
> the subscribers list there. Either way, I don't think we'll be able to
> make substantial changes in time for 3.0, so I suggest proceeding with
> the portlet as-is and trying to improve it later.

I think deferring it until after 3.0 is totally fine, and at that
point putting it into a popup or separate page would be fine.  It
would let you show more clearly what *my* subscription to this bug is,
whether it's direct or indirect, and through a team or personal.

However, since we're talking about it: to me, being sure a person
receives mail about a bug is a very weak kind of promise, and I would
be a bit surprised if anyone relies on it.  Serious Launchpad users
(upstream developers or distro developers), get tens or maybe hundreds
of bug mails per day.  If you subscribe to all Ubuntu mail (which I
think is possible) you probably get thousands.  These people also tend
to be already subscribed to relevant products/packages.  Just making
sure that mail about this bug got into that very large bucket is
almost meaningless, it seems to me.  And knowing that the person is
now somehow subscribed to the bug doesn't tell me they got the
previous mail about it, let alone that they read it.

What I mean by 'semantic' is saying 'hey, have you seen X' or 'I just
want you to be aware of X' or 'would you please start work on X',
where it's not just bug spam but specifically a message from me to
them.

>>>> Similarly "Nominate for release" is misnamed; it should be "request
>>>> fix in series", and "also affects distribution" perhaps likewise.
>>>
>>> Again, I'm not convinced that the phrase you are suggesting is
>>> necessarily better. I'm not a heavy user, and I know how it works, so
>>> I may be the wrong person to judge this. I definitely want to hear
>>> more opinions about this.
>>
>> https://bugs.edge.launchpad.net/malone/+bug/132733
>>
>> It has nothing to do with releases! :-)  Well, indirectly it's going
>> to affect it, but it doesn't connect up the launchpad objects called
>> Bug and Release afaik.

I think this still is an issue, and should be an easy change while
you're updating the page.  I don't see any disagreement in that bug,
but perhaps there are other people to consult, which might make it
harder.

We're using series targeting for our stable release branch so this is
on my mind.  Approximately everyone needs to be told what that link
does, and then they say "oh really? how strange."

> I don't actually have a problem with the location (nor do I feel that
> information is lost placed between the description and comments), but
> I've heard this opinion from more than one person, so let's try and
> come up with new ideas.

Well, one option would be to put it below the task table, above the description.

The usual case is that there is zero or one linked branch, so it won't
use much space.

It would put all the non-textual data together and make sure it's
above the fold, even if the description is long.  It also puts the
"status of this fix" together with the bug state.

Also, as Jono says, it would be nice to show the merge proposal link
and status, though that's also something we could do after the
restructuring.

>>>>  * Original description: this is ok in this position cause it really
>>>> does relate to the description, but it would be cooler if there was
>>>> just a timeline entry saying "description changed" and linking to the
>>>> previous version.  (Isn't this already there? If so, just remove the
>>>> link under the description.)
>>>
>>> Yes, that's already in place (though it can be improved a bit). I
>>> think it's still important to indicate that the description has
>>> changed next to it, because it is implicitly associated with the bug
>>> reporter, who may not have written the latest version.
>>
>> Personally I don't care about this; anyone who's used Launchpad knows
>> it can be edited, and it's almost always edited to make things better
>> and clearer, not to make the reporter look bad.
>
> I don't think there's much harm in keeping the link, and it is
> sometimes useful, so unless I'm convinced that we'll be much better
> off without it, I'd like to keep it for now.

Fair enough.

> Could a different formatting, but without changing the location, improve things?

If you made them more visually prominent somehow it would help, by for
example turning them into a table like the task table, or indenting
them, or emboldening them.  But I think the location is the important
thing - see above.

>> Oh, is it moving to the bottom of the page?  That seem poor.
>
> I agree. You can see examples on some of the pages that have already
> been converted. I think that way it's impossible to find without
> knowing it's there in advance.

Right, putting the login status and the search box in the top right is
a very well established pattern.  Launchpad global search works pretty
well now so it's a shame to deemphasize it.  In your mockup it looks
like it just searches the help.

>>> Seems not everyone agrees, so for now we have a mixed
>>> approach, where we indicate using colour whether something goes to a
>>> new page or opens and editor inline. I think this is another one of
>>> these cases where we fix broken navigation by breaking it even more.
>>
>> Of course the problem is that green and blue (at least) can be either
>> link colors or semantic (bug status) colors.
>
> Right, but of course linking to a status is pretty meaningless, so
> that's not an option.

I do sometimes want to go from a critical bug to other critical bugs,
or inprogress to other inprogress bugs, and I may be misremembering
but I think Launchpad used to support that.  But it's a tradeoff;
doing that would mislead some people who just want to change the
status, and give a smaller click target for a very common operation.

-- 
Martin <http://launchpad.net/~mbp/>