add docs or prompts to rename route process

[brendanheywood]

Eg

Campbell Gome renamed the route Senza nome (throughout the grotto) to Catch you later

If the name is widely different should it suggest retaining the old name as a historical alternate name?

[cgome]

Good idea (but in that instance the old name was Italian for 'unnamed') I noticed an ascent comment with the right name and made the change ;-)

[scd]

This should be on a case by case basis. Yes definitely if the old name was a historical name or an alternate name. But if it is just the wrong name, a typo, or expansion then no. Sometimes it is hard to know.

What I am saying is yes, but I think it will be difficult to automate.

Also I think that if a route has an important historical name then eventually somebody from the climbing community will add it.

[brendanheywood]

I don't want to automated it. A good UI example is confluence which our enterprise wiki. Whenever you make a change you have to give a comment about the change similar to a git commit comment. As part of the comment there is a couple choices like ' Major change', 'Minor change'.

So what I'm thinking is something like:

New Name: ___

Reason for new name:

• Current name is offensive (so move it to offensive and make new name principal)
• New name is the 'proper' name (so move current to 'alternative' and make new one principal)
• Name belongs to a different route (just remove it)
• Current name is a temporary project name etc

And give the option to swap back to the current UI if hey want.

It's just that in all the feeds I've seen heaps of name changes but almost none of them retain the old stuff. And maybe for most of them that is a good thing but I just don't want the UI to encourage loss of data.

[scd]

You have actually got a very good point here, but is this an issue for route names only or route data more widely.

We are moving away from the change route name process and incorporating it into update route details process. We need to design this new comment field for the update route details process. If it is just route name lost data we are worried about, then this can be a hidden field which becomes active when the route name is changed in the form.

I'm not too worried about route descriptions because we never delete old versions. But other route details including history is irrevocably updated, which should be of some concern for us.

The only two UI processes we should be designing for here is:

• update route details; and
• request name change (this captures some of the concepts you are talking about, but poorly implemented).

Actually the later may actually eventually become request details change so maybe we should hold off on that too for a while.

[brendanheywood]

It is probably valid for area's as well. I think the logic should be there regardless of what process it ends up in, which should just be the uber 'route details' process.

[scd]

Yes same logic for areas and routes. Probably not required for ascents or accounts as these are personal records rather than community records.

In the uber route details process is it a comment for route name change field, or a general comment on any route details change?

[brendanheywood]

I think just for the name. Most other detail changes will be simply updating the climb to a more current state, like if bolts were chopped, or a block fell off. Details like that seem to be done well already in the markdown.

For me the key value here is retaining history for search / discovery, people won't be searching for 'that climb that used to have 6 bolts' but would search for an old name.