Deprecating is hard

This is an opinion article.
This page contains the advice or opinions of one or more OpenStreetMap contributors. This page is not documentation, nor is it one of OpenStreetMap's policies or good practices, and it has not been thoroughly vetted by the community. Some articles represent widespread norms; others only represent minority viewpoints.

This opinion article was created as a part of one of many discussion suggesting renaming and/or deprecating existing tags for some perceived benefit like "being more tidy" or "more logical" or "being correct English".

Here are some of the reasons why deprecating tags (or "renaming tags", which is basically creating new tags and deprecating old ones) is not only hard, but also usually much harder than expected.

In cases where the discussion is not about a completely new (yet unused tag), but about changing the popular, existing tag (like in example discussed in above linked thread), that brings a whole lot of new problems which would otherwise not apply (or at least not in such amount):

• it needs endless discussions (of which one that directed you to this wiki article is only a tiny, barely visible sliver) wasting enormous amounts of mapper time which could be much better used to, well, map
• it creates needless friction between mappers, leading to some percentage of them leaving the project (or even becoming vandals). Or, at the very least, it certainly does not increase happiness on the planet.
• even if somehow we all manage to instantly agree on every decision and thus avoid the negative consequences above (not likely before we become part of Borg collective, but let's pretend it is possible for the moment), it would still need huge amount of effort to execute:
  • changing the wiki is first, but infinitesimally small part of the job
  • then all the other documentation on the Internet that mentions those tags should be found and corrected (that include not only text materials, but editing or revoking old and making new videos too -- enormous job worthy of of certain 1984 Ministry), otherwise new people will stumble upon them and reintroduce the deprecated tags.
  • then, all the people who ever used the tag should be contacted and re-educated on new use
  • making an automated edit for old edits is another very tiny part of the job (with extra disadvantage is that it would also make planet history database bigger and slower to process)
  • then the main OSM database needs to be monitored and automatically-correct via automated tools for indefinite future, because not all people would be contacted (some might have learned the tag earlier, but not used it yet; or they could've downloaded videos/documents before the change; or they could've forgotten about the change, etc.)
    • alternatively to constant monitoring, we need to introduce concept of forbidden tags so "wrong" tags can never be entered into database -- while easier than constant monitoring/editing, such censorship mechanism is unlikely to be loved by much of the community interested in helping OpenStreetMap. It is also against fundamental OSM principles like ATYL
  • all the data consumers (i.e. app and website writers) should be contacted (good luck even finding all of them; that is a huge task in itself!) so they can be persuaded to use new tag instead of old one (although they should probably still support the old one for compatibility reasons, because the app might be using old dataset which might not be easily updated). Writing a pull request for each data consumer would be recommended to increase the chance of acceptance
  • even with all that, some uses will be broken (think of older devices which cannot be upgraded, so they continue using the old code, but new data not longer matches old code) - the things that worked for them before the "improvement" won't be working any longer.
  • and if not all of that is implemented, we would've made a situation actively worse for:
    • mappers (who are now bombarded with 2 conflicting mapping suggestions, having each of them waste additional time to educate themselves),
    • editor apps/data consumers (who have to support both for reading, but prefer one for writing, as well as answering endless stream of issues asking why it does not prefer the other value)
    • database wastage (both history database needless growth, and worse compression ratio as two tags compress worse than one tag)
    • and in the end there would still be tags which are "not proper English" (so even that primary objective which cause the whole hubbub would not be fully implemented), so all that trouble would be in vain.

All that (and probably several other things not mentioned) should be weighed against any real or perceived benefits. So people should firstly be considering:

• what are the actual benefits of making that change (e.g. renaming tags so they are more resembling proper English, or whatever is the case). Do we have examples of those benefits manifesting in similar situations in the past?
• how those actual benefits compare to all the problems and effort needed (or which things outlined above are an example, but likely not a complete list)
• is the proponent personally volunteering to do all that work enumerated above to increase cost/benefit ratio of such proposal to acceptable levels?

---

TL;DR: "renaming" popular existing OSM tags just because they would be "more tidy" and/or "slightly less incompatible with English language" is enormously inappropriate waste of resources (and for extremely tiny, if any, real benefit for mapping and using of OSM data). YMMV, of course, but please at least do consider all those issues and have an opinion for each of them before attempting to plunge in. Without taking them into consideration before making proposal, it will just waste everyone's time.

Also see Deprecated_features#Everything is more complicated than expected for more information.