= Personal Branch URL Change =

Personal branches currently have URLs of the format '''~owner/+junk/name'''.  "[[https://bugs.edge.launchpad.net/launchpad-code/+bug/387552/comments/3|+junk is not descriptive and sounds unprofessional, hackerish and stupid]]".

'''On Launchpad:''' [[https://blueprints.edge.launchpad.net/launchpad-code/+spec/personal-branch-url-change|personal-branch-url-change]]

'''As a ''' launchpad user<<BR>>
'''I want ''' to be able to publish my personal bazaar branches<<BR>>
'''so that ''' others can see and get access to my branch without the branch containing +junk in the name and the negative connotations that ''junk'' has.<<BR>>

Personal branches with +junk in the name are considered ''bad'', and some users will not use Launchpad (for simple personal branches) just because of this.  This has been observed through the bazaar users mailing list.

== Rationale ==

''Why are we doing this now?''

With bazaar adoption on the increase, we want to remove perceived road-blocks for people storing their branches on Launchpad.

''What value does this give our users? Which users?''

Increased perceived accepatance of personal branches in Launchpad.

== Stakeholders ==

''Who really cares about this feature? When did you last talk to them?''

Casual Launchpad and Bazaar users.

== Constraints ==

Any change to the URL must also provide access using the old name.
 * bzr+ssh needs to accept both old and new urls
 * http rewrite map needs to allow both old and new urls
 * branch traversal must allow both old and new urls

People with personal branches must be encouraged to make projects if they wish others to collaborate on the code.

== Workflows ==

''What are the workflows for this feature?''

Nothing new.

''Provide mockups for each workflow.''

== Success ==

''How will we know when we are done?''

When a personal branch is accessable through all entry points (except perhaps the api) using the old +junk label and whatever new label we choose.

''How will we measure how well we have done?''

Public acceptance of the change.

XXX - this needs to be something better we can actually measure. Why are we doing it at all? There has to be some benefit, and we should make at least a token effort toward measuring that benefit.

 * Possible metric would be increase in number of personal branches -- if it happens, then the change has caused the problem that "+junk" was meant avoid.

== Thoughts? ==

''Put everything else here. Better out than in.''

There are a lot of places in the codebase where the +junk label is used.  There will be much search and replace in implementing this feature.

Care needs to be taken around the branch traversal, and making sure that both the smart server and http access continue to work.  Bazaar does follow http redirects.  Perhaps an http rewrite would be sufficient for +junk rewrites into +branch (or whatever else we choose).  This may be much simpler than dealing with the rewrite map.

Curtis disables a few personal projects every week. The users favour the term "sandbox". There are some uses of "repo". 

I think the ''number of junk branches'' argument assumes the branches never become the base for a project. If it were clear that my sandbox was an incubator and thate there was action I could take to create a project from the branch, we could see better quality projects registers. Most registered projects have no code, nor ever will. We should also consider the number fo projects with branches that recieve no attention after one week. Incubating a branch to a state where it is valuable to the public is better that littering Launchpad's project namespace.