Changing RFC time for proposals including deprecation

General talk Tagging general discussion
1

Hello all,

In recent months there has been a steady stream of proposals which, in some way, seek to deprecate a tag or value. These proposals have been put together with great effort by their authors, but have found mixed success with being approved.

There has been much written already about the challenges inherent with deprecating a tag (especially a highly used tag): proposals don’t have to be implemented, so deprecation has limited effect; the effort required to change tags is often very high; data consumers often need time to adjust.

I sense that there is a higher level of scrutiny applied to such proposals, and I would like to float the idea of extending the minimum RfC period for proposals which include, in some way, deprecation. The extra time might help increase the amount of feedback received, and in turn lead to higher quality, more successful proposals.

Dian

4 Likes
2

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
3

I agree with you, ‘deprecating’ is a huge step. Maybe we should introduce a new rule for proposals:

  • A proposal introducing a new tagging scheme should not deprecate any well established tags.
  • A proposal might discourage the use of a tag it aims to replace.
  • deprecating an existing tag in favor of another requires its own proposal, and the new tag must already be established and supported by at least a subset of applications.
4

The main issue is that while the current voting criteria are OK for “approving” a completely new tagging (aka for something that previously had not been mapped), they are 2-3 magnitudes too low for changing existing tagging, particularly when it is well established.

8 Likes
5

I believe OSM has a structural issue where it’s easy to roll out a poorly-thought out tagging idea, but hard to improve it when flaws are discovered later.

There are two basic design strategies that would make sense to me:

  • make it easy to create things and also easy to change them later (i.e. iterative improvement), or
  • spend the initial effort trying to get it right the first time.

At the moment, we’re pretending that we’re doing the former. It’s even in the core values: “We iterate towards excellence rather than spending years in planning.” And we certainly make it rather easy to roll out new stuff: There’s any tags you like, barriers to editing the wiki are pretty low, etc. But we lack the essential ingredient that makes iteration actually work: The ability to make effective changes later on.

I feel this suggestion goes into the direction of further enshrining this pattern where it’s easy to introduce mistakes and hard to fix them. And looking at the list compiled by @Matija_Nalis, I wonder whether we shouldn’t view it as a set of obstacles to making necessary improvements and consider what would have to change about our tools, processes or culture to make such improvements easier.

8 Likes
6

Well first part of that is create, we make it easy to create things.
It is however not at all easy to change them later (nor have I’ve seen such bold claim being made before?); the closest we have come to that ideal is dropping the old idea, creating a new (hopefully improved) one, and then lobbying data consumers to implement both until the one of them dies out.

Well, I would vote for that one. It need not take years as “core values” threaten us, but some thought and effort should go into creating new tags, in order to avoid much bigger pains that come with poorly though-out ones. Bigger problem is finding enough contributors willing to wade through poorly made proposals and invest their time into it (even if they don’t particularly care about idea being discussed).

Since often it is much more chore than a fun (especially as some proposers seem to disdain people trying to inform them of problems they are likely to introduce with their proposal), perhaps (this is not going to be controversial at all :smile:) OSMF should put on a payroll few people with different backgrounds to invest their time on helping users propose better tags?

7

So far, the community has done a great job downvoting bad proposals, of which there seems to have been a lot lately. So I’m not sure there’s a need to change the process on that regard. However, I’d happily support a proposal to increase the minimum number of yes votes across the board, even if it means some niche tags take a longer time to accumulate a sufficiently large voting tally.

3 Likes
8

The voting process may be working but it means a lot more work for the community all of a sudden. And that in itself is a denial-of-service attack on the process.

I have the impression that something fundamental is changing in the way people approach tagging questions. Only a few months ago the normal mode of operation was to come to the tagging mailing list ask about some tagging problem and after some discussion write an RFC which already took into account at least some of the points discussed. Lately, there is an influx of RFCs with topics that I have not seen discussed before. They are announced and then put to vote as is two weeks later. The whole point of the RFC, the discussion with the community, seems to be largely ignored.

Any idea why this change might have happened? Is there some new documentation that tells people that an ‘approved’ stamp is required for tagging?

3 Likes
9

I understand what you are aiming for, but I wonder if extra time would actually help. I have the impression that if an RFC doesn’t “catch fire” and generate a discussion as soon as it is announced, it then tends to go completely unnoticed (until voting starts and then the proposer is surprised by people raising issues that were not mentioned during RFC). Having more “live” RFCs competing for attention at any one time might make this even worse.

I agree that it might be useful to make a bigger distinction between proposals that imply deprecation versus those that simply introduce a new tag that does not conflict with anything else. But I’m not sure if “more time” is an effective distinction to make.

3 Likes
10

Well, I’m uncomfortable with one important point missing here: despite of deprecation requiring efforts, how many items remain to be mapped with proposed tagging?

I mean, what do we get at spending time to make a plan, that probably won’t occur as expected, to retag 500k objects if 50 millions remain to be found?
Facts (taginfo) show that such proposals catalyze contribution a lot. It often increases usage 2 or 3 times more on proposed new tagging than on the deprecated one.
We tag 12x times more line_attachment=anchor than tower:type=anchor, starting from the deprecation of the last.

We replaced waterway=riverbank, landuse=farm… so how this can be a challenge anymore?

As we may deal with unifying tagging practices among many in use at the time of the proposal, consumers won’t be bothered by the change. They will continue to use existing tagging until it disappear from the database.

My 2cts.

11

True. It probably would we worth suggesting that proponent sends a reminder at least once again in the middle of RFC if there are not much comments, and additionally on any major change to the proposal.

12

Well if you were talking about 5 objects instead of 500k, that would totally make sense to just ignore. But 500k is extremely huge number, and even 5k is very very high. There are 500k of useful pieces of information that would stop being useful (and become database deadweight) if they were ignored instead planed for. Those are 500 thousands of edits translates into years of someones hard work that somebody just carelessly destroyed with a swipe of the mouse, because they didn’t feel like investing extra half of hour into making a minimum of effort to do a more useful proposal. That is way beyond selfish!

How would you feel if someone came and removed just 5k streets or shops from your country? I know I would be very angry. It wouldn’t matter to me one iota that millions of streets elsewhere are just fine (in fact, it would probably make me even more angry!) Now replace that spatial emotional attachment (e.g. “my country”) with any other attachment (e.g. “my hobby”). For example I like cyclotouring. If someone deleted (or in other ways made them useless in apps and websites) tons of cycleways worldwide, it wouldn’t make me feel better because “oh well, but all the roads for cars of which are there many more are still there, so it’s fine”. No, I would be even more outraged.

That is why one should not do half-assed proposals, but invest effort into them, if they propose to negatively affect work of all those who came before them.

13

Correlation does not imply causation. I would propose that it is more likely that strong leader emerged who incited more mapping of such feature, or that community using that tag has grown or had extra imports/organized mappings, or that the improved semantics allowed more things to be mapped, etc - than that the mere tag name change (which majority of users rarely if ever use directly, but instead often use presets in their local language in their editing apps) has caused the sudden surge of usage.

But regardless, note that there were effort to handle old keys there. Maybe you weren’t involved in it, but it was there. So, potential proponents must be made aware of that fact that the “renaming of OSM tags” is much much harder and more time consuming than “search & replace” in their favorite word processor, which many of them seem to naively assume.

We replaced waterway=riverbank, landuse=farm… so how this can be a challenge anymore?

Have we really replaced (past perfect tense) them, now?

We have surely started the process of replacing them, and after mere 3 years of work we have made a great progress, but there are still 4481 unfixed waterway=riverbank according to taginfo. Perhaps in several more years that effort will be completed, and those tags will really be replaced, but until such time, there is more fixing that is yet to be done to rectify damage that was done in the name of that “river modernization”.

But what is important is that this problem was considered, cost / benefit analyses was done and taken into account, and it was deemed that it will likely be worth it, and an effort has gone into proposing how to handle it in the best way. (and that is all that one would ask from new proposals!)

As we may deal with unifying tagging practices among many in use at the time of the proposal, consumers won’t be bothered by the change. They will continue to use existing tagging until it disappear from the database.

There are two types of data consumers: that which read data only, and those that write it too (AKA “Editors”. They both need to be upgraded, but possibly at different times (see especially bulletpoints 2 and 3 of this post).

1 Like
14

While there has always been the occasional proposal from well-meaning but inexperienced contributors, it seems like lately, we’ve seen a string of unpopular proposals from well-established, long-term contributors. Other than coincidence, I am at a loss to explain the recent trend.

15

But if you don’t count Norway, that drops to only ~130 worldwide! overpass turbo

1 Like
16

Interested tidbit! That actually makes it worse :cry: (even if it strengthens my points)!

i.e. if Norway is intentionally not wanting to change to new tagging schema (which seems possible reason, but I have not investigated at all, it might as well be just an mistake or coincidence), than we’ll probably never finish replacing waterway=riverbank with water=river, instead of it possibly being finished in several more years (in addition to initial 3 years which did most of the work) like current taghistory trend seem to indicate:

riverbank
riverbank1080×87 7.24 KB

But that Norway is randomness which varies with the tag; if you take another example mentioned above, old landuse=farm which still has 6098 uses, and strongholds seem to be predominantly UK and west coast of USA. Regardless: if OSM purports to be a map of the world, it should not start excluding Norway, UK, California etc. from its definition.

Anyways, my main point was: Rome wasn’t built in a day, and neither was discussion about waterway=riverbank deprecation (and finally carrying out that idea to the conclusion) done in a day (or a month, or a year. In a decade - maybe). And IMHO, the same principle should be applied to other new proposals wanting to deprecate things: The more issues new proposals create by deprecating existing usages, the more effort needs to be put into them for addressing those issues.

17

It is not random.

When this issue was discussed with the Norway mapping community there was not a consensus for making the change. The specific issue is that at least one editor in the country was combining waterway=riverbank with intermittent=yes and natural=sand (or some other non-water value of natural=*.) in order to show intermittent water rendered on top of some other type of landuse. And since an object can’t be both natural=water and natural=sand, thus is the problem.

For an example of the effect this type of mapping is trying to achieve, take a look at some detailed land cover mapping I’ve done along the shores of Lake Powell as part of my Mappy Hour Presentation on river tagging.

4 Likes
18

Thanks for that bit of history! So I guess waterway=riverbank is here to stay, then?
Too bad that this usage wasn’t caught in proposal stage, or we’d likely be happily living with more versatile waterway=riverbank today without all the renaming fuss. Just goes to show how important it is to involve a lots different people and dedicate a lot of time into such big changes, as even with forethinking some issue might still slip through. (Now imagine how much more problems would that cause instead of just that one, if proponents were fans of “well why bother with all those checks and overthinking about potential damage, it’s just few hundred thousand elements, whatever” philosophy.)

(Aside: about the “random”; I didn’t mean to imply that relation between Norway and waterway=riverbank is random, but that random countries will be “old tag strongholds” for different tags; e.g. Norway for waterway=riverbank, but UK/California for landuse=farm, etc.)

19

Not really. The key conflict is a non-issue since the intermittant water area and the sand or rock can be mapped as two separate objects. For example: river area, rock area. Eventually the remaining waterway=riverbank areas in Norway will get changed to this style.

3 Likes
20

But what do you do when people don’t respond, or do but then stop?

As mentioned on the Tagging list: [Tagging] Feature Proposal - RFC - Start moving proposal announcements to the new forum, I’ve been discussing making changes to the various existing lifeboat-station tags, which would mean setting emergency=lifeboat_station as the default, while deprecating the mainly duplicated options: [Tagging] Possible merge of marine_rescue & lifeboat_station tags? & Possible merge of marine_rescue & lifeboat_station tags?.

The last two questions I’ve asked haven’t had any response, apart from two likes on here.

Do I now just raise a proposal to change that tag from “in use” to “approved” & also mark the others as deprecated, or just think, “I asked, but nobody answered or complained, so they must be happy with the idea, so I’ll just go ahead & do it”?

Next step would be to go through the several 00 uses of the various tags worldwide & remove the duplicated tags that have been used on the same POI e.g. emergency=lifeboat_station + amenity=lifeboat_station.

Some of them are also tagged as emergency_service=water, which doesn’t even have a page created, but is in use 250+ times!