Changing RFC time for proposals including deprecation

Agreed. To paraphrase Carl Sagan: “huge changes require huge investment in preparing the proposal”.

Any deprecation is going to require a lot of extra effort to make sense:

  • changing the wiki is easiest (and, when considering time effort needed, absolutely negligible) first step.
  • it has to be decided what to do for deprecation to lead to old key not being created anymore (i.e. research what tools create them, and if proposal passes, create tickets to use new tags instead. Also, reach out to users using that tag in generic editors i.e. without built-in presets, and ask them what external presets they are using, and work to change those too)
  • then support for new key should be lobbied for; not only in map editors (as done above) but also in other data consumers (renderers, routers, search engines …) and issues opened (and followed to completion) there too.
  • then, when old tags finally stop being created some time down the line (which needs to be monitored, and newly found data consumers contacted etc), it should be decided what needs to be done with existing usage of old tags. I.e. is it possible / valid to do Automated Edits code of conduct - OpenStreetMap Wiki ? Or should they be manually resurveyed / retagged? Who and in what way is going to do that.

People do not seem to appreciate enormous amount of effort and turbulence that needs to done. Just doing the research enumerating the number of things that need to be done is big effort, not to mention actually checking off that TODO list! But that research at the least should be part of original proposal to deprecate things used in the wild.

IMHO, the reasoning along the lines “well the old name was confusing and/or untidy-looking to me, so lets rename everything for no other reason whatsoever” should be at least be explicitly heavily discouraged.

6 Likes