Merge proposal URLs are ugly and needlessly long

I am not convinced.

Yes, the URL is long. On the other hand, it contains enough information for me to have some idea what is on the other end of it and attach hooks in my memory about it. This is unlike bug urls, where to be useful you have to paste the bug url and the description, or noone has any idea what the bug is.

The fix for this would be relatively straightforward. However, I tend to agree with Michael.

On Fri, 17 Jul 2009 10:39:33 Jonathan Lange wrote:
> The fix for this would be relatively straightforward. However, I tend to
> agree with Michael.

And I.

I agree as well.
I understand where mpt is coming from, and it would make it nicer to send URLs around, but, in the theme of the Usability week I'm doing, there's data that says that people actually look at URLs to figure out if that's what they want or not. Removing the interesting information from it may end up doing more harm than good, especially since people who use them are pretty savvy users.

Merge proposals are also typically short-lived, so I think pretty URLs are less important because of it.

I do agree with mpt in
<https://bugs.edge.launchpad.net/launchpad-foundations/+bug/317136/comments/9>.
 Although Launchpad URLs make sense when you see them, they tend to be
long enough and contain enough arbitrary redundant elements that
they're hard to correctly make up.

However I don't think I agree with this bug as stated, but I have some
thoughts on the general issue:

* Consistency with Launchpad Bugs is desirable. Bugs have a
redirector but the canonical url at present includes the context. I'd
kind of rather have MPs also include the context unless/until bugs
change to be contextless, and then have the change be consistent. (I
suppose on the other hand piecewise improvement is good, so if Code
can strike a path that bugs will follow, great.)

* Having fairly long URLs for bugs works because you can easily
identify them by number and redirect to them, including through
redirectors like ubottu or gnome-do that mechanically generate URLs.
Apparently there is no such thing at the moment so I filed bug 400513.

* Also along the lines of making the numbers work as references, it
should be at the start of the <title> as it is for bugs - bug 400514.

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

I don't see the value in increasing the visibility of the merge proposal's numeric identifier.

To me, the single most important thing about a merge proposal is the branch that's being proposed to be merged. That's how I think of the proposal and that's how I talk about it to others. The name of the branch has a meaning within the context of my project, the number is an arbitrary, meaningless identifier.

I also think this ranks very low on the list of things we can do to improve the usability of the code review system.

I don't want this to be stuck in the "New" status forever, I'd like to see a decision on whether we should do this.

If yes, then the related bugs I've marked as "wontfix": bug 400513 and bug 400514 should be re-opened.
If no, then let's mark this as wontfix too.

Assigning to Tim, whom I guess to be the tie breaker in this circumstance.

On Fri, Jul 17, 2009 at 04:52:01AM -0000, Jonathan Lange wrote:
> I don't see the value in increasing the visibility of the merge
> proposal's numeric identifier.

I don't think the point about this bug report is to increase the
visibility of the numeric identifier. It's about making it easier to use
the URLs in e-mail and IRC. When looking at a merge proposal e-mail
notificaiton, I sometimes want to go to the web UI to have a closer
look. Most of the time I have to resize my mail window, since the URL
doesn't fit in one line.

> To me, the single most important thing about a merge proposal is the
> branch that's being proposed to be merged. That's how I think of the
> proposal and that's how I talk about it to others. The name of the
> branch has a meaning within the context of my project, the number is an
> arbitrary, meaningless identifier.

Still, I seldom see people giving links to branches when asking someone
for opinions on a merge proposal. That tells me that the link to the
merge proposal is actually useful.

> I also think this ranks very low on the list of things we can do to
> improve the usability of the code review system.

You should also consider the cost of doing this. Even though it's low
priority, it can still make sense to do if it's really cheap to do. What
else could you do, that would be of the same cost, but be of more value?

    subscribe

I do think that bug report final URLs should be shorter too (<https://bugs.launchpad.net/nnn> for single-context reports, <https://bugs.launchpad.net/nnn?in=project> for multi-context ones). But it seems like an artificial roadblock to require bug report URLs to be shortened before merge proposal URLs can be shortened.

It's a good point that merge proposal URLs often contain recognizable information that saves you from needing to follow the link. But in some contexts <http://twitter.com/rexbron/status/2652629058> it's not a choice between <https://code.launchpad.net/merge/5520> and <https://code.launchpad.net/~diego-fmpwizard/mysql-proxy/master_info/+merge/5520>; it's a choice between <https://code.launchpad.net/merge/5520> and <http://bit.ly/WuKSA>. The former has the great advantage that it's at least recognizable as a merge proposal.

Perhaps leaving the branch name in the URL, while still removing the author and project IDs, would keep it recognizable enough? For example, <https://code.launchpad.net/5520/master_info>. (We don't really need to include "merge/" or "proposal/", for the same reason that <http://bugs.launchpad.net/number> doesn't need to include "bugs/".)

Using something like <https://code.launchpad.net/5520> isn't particularly helpful as it doesn't really give enough context.
<https://code.launchpad.net/merge/5520> is better, but merge would have to be blacklisted (like bugs) - it is currently available.

Perhaps an RFC on the dev list may be a better place to discuss this.

Personally I think anyone shortening links would shorten <https://code.launchpad.net/merge/5520> to <http://is.gd/xxxx> or something similar anyway. Despite all this, and whatever our desires may be to avoid people talking about reviews using their number, it'll happen anyway because it is a single number that uniquely identifies a merge proposal / code review. Having a deterministic way to get to the underlying review is helpful in this case.

I'd be happy to have +merge on the LaunchpadRoot to redirect to the actual review, but perhaps we should change the canonical_url as well.

Since this bug was last discussed, I set up http://pad.lv/ which is better than shortening through is.gd and friends: you know it's going to lp, you know where it's taking you, and you can make up short urls by hand.

If this existed, then we could have <http://pad.lv/mp/5520> redirect to it.

So Martin, you're suggesting we shorten our URLs so that you can make them even shorter ?

In any case, this URL is part of the web service API 1.0, so changing the canonical url now is complicated. It would have to affect only the devel API and web site. And it would break any code that assumed the 1.0 API's url was related to the web site URL, e.g. lp-land. Providing it as a redirect instead of a canonical url would be less challenging.

Tim said: "Despite all this, and whatever our desires may be to avoid people talking about reviews using their number, it'll happen anyway because it is a single number that uniquely identifies a merge proposal / code review."

I have never seen this, so if it happens at all, it's probably too rare a case to worry about.

On 8 December 2010 01:13, Aaron Bentley <email address hidden> wrote:
> So Martin, you're suggesting we shorten our URLs so that you can make
> them even shorter ?

Ha ha. In a way, yes. Short URLs are useful.

I'm not necessarily suggesting that you make the canonical URLs
shorter, but rather just that if I know the mp id, which is enough to
uniquely identify it, you let me open it. In other words I want to
open something like code.l.n/+merge/1234. I don't care if that
directly serve the content, or if it redirects to the other location.

> In any case, this URL is part of the web service API 1.0, so changing
> the canonical url now is complicated.  It would have to affect only the
> devel API and web site.  And it would break any code that assumed the
> 1.0 API's url was related to the web site URL, e.g. lp-land.  Providing
> it as a redirect instead of a canonical url would be less challenging.

Right, so a redirect could be good.

API clients may actually find it useful to be able to go from the id
to the object.

>
> Tim said: "Despite all this, and whatever our desires may be to avoid
> people talking about reviews using their number, it'll happen anyway
> because it is a single number that uniquely identifies a merge proposal
> / code review."
>
> I have never seen this, so if it happens at all, it's probably too rare
> a case to worry about.

I think there is a chicken and egg: you can't get from the id to the
mp so people don't use them. Instead, I see people using somewhat
vague textual descriptions like "my merge refactoring branch". They
certainly do this with bugs too but at least there they have the
option to say "do you mean 123456?"

--
Martin

On Fri, Dec 10, 2010 at 01:54:55AM -0000, Martin Pool wrote:
> > Tim said: "Despite all this, and whatever our desires may be to avoid
> > people talking about reviews using their number, it'll happen anyway
> > because it is a single number that uniquely identifies a merge proposal
> > / code review."
> >
> > I have never seen this, so if it happens at all, it's probably too rare
> > a case to worry about.
>
> I think there is a chicken and egg: you can't get from the id to the
> mp so people don't use them. Instead, I see people using somewhat
> vague textual descriptions like "my merge refactoring branch". They
> certainly do this with bugs too but at least there they have the
> option to say "do you mean 123456?"

Indeed. Giving the ID today isn't useful, since given that it's
practically impossible to find the review in the web UI. You have to
give a description or branch name, and given that it's actually not that
easy to find the review either.

I would love to be able to say "about MP 1234, ...." on IRC, and then
have a bot giving the details, including a URL to the MP, just like we
have with bugs. I think people would use IDs more that way, and it would
improve usability.

--
Björn Tillenius | https://launchpad.net/~bjornt