Changing RFC time for proposals including deprecation

I find this is usually due to one of the following reasons:

  1. The proposal is discussing a niche topic that many people are not interested in.
  2. The proposal is poorly-written and people are not willing to put in the time and energy needed to fully develop it.

I tend to find that the best way to get useful feedback on a timely manner is to share the proposal on one of OSM’s many chat communities, which tend to result in faster response times.

Unfortunately, persuasive writing is a fairly challenging skill to get right and there is no obvious feedback when you’re missing the mark beyond a lack of engagement and negative responses when the proposal goes up for a vote. If the topic is niche, then there is often not a need to go through a proposal at all - just document the usage under the principle of “any tags you like”.

5 Likes

I still don’t believe that more time would bring more answers. A reminder after a week or similar would make more sense.

Much more important is: I would start somewhere completely different. We finally need a reasonable deprecation process. Maybe it will be somewhere around a year or two and take all stakeholders with it. But a “cleaning up” of the database should not be prevented any further.
Incl. broader participation, e.g. when we finally get away from the mailing list. Less “nerdy” people are simply deterred from it. Also one must ask oneself as a community whether we “consensus” with our Tagging recommendations in controversial questions Tagging A or Tagging B not with 75+% but halt simple majority to decide let. But then also prepared accordingly.

2 Likes

I’m not sure it is possible to get a deprecation process that can support a large-scale deprecation process, enjoys broad participation, and has a lower threshold for “consensus”.

Deprecation is inherently disruptive as it requires data consumers to change the way they use the data. We don’t have any control over how or when consumers choose to do that, but we must keep in mind that consumers will have some maximum capacity for changes in a given period. Deprecation needs to take some time if we want to keep data consumers happy and up to date.

Increasing participation in these discussions is a good thing, but as more people join the conversation it will take longer and longer to reconcile different points of view. More participation will increase the amount of potential issues identified with proposals, and it will take more time, not less, to resolve them.

Lowering the threshold for consensus will resolve some of the difficulties with increased participation, but will compromise the legitimacy of the entire process. The proposal process operates essentially “by consent”, and a highly polarised proposal that passes with 51% will lead some to ignore the process entirely.

By analogy to the Project management triangle - the cost (effort by data consumers to transition) is fixed, and the scope (of proposals) is fixed. The only way we can increase quality is by allowing more time.

By your writing, shouldn’t deprecation of little used, non-standard, or non-adopted ones have a more relaxed requirement?
Requiring a thorough analysis of their existing usage might be too much, when a problem statement could do. But it should be reasonable to ask proposers to check and list out what visibly used public applications are using them.

I wouldn’t describe it as a “relaxed” requirement, but it might be easier to put together a comprehensive proposal that meets requirements that other tags.

Although if noone is using the tag, is there any reason to officially “deprecate” it at all?

1 Like

But that is precisely the point why we really need a process. And I think that in the end we don’t need more time for a proposal, but for the transition process. But then you also have to define this process correctly. Especially with a project that has this scope, we really have to consider whether the database should be structured a bit more and “official” tags introduced, precisely because there is this mishmash. Just so that you don’t always have this hiccup.

I searched around again and brought the old proposal for a sensible deprecation process here. Unfortunately, it was abandoned at the beginning of the year. Not everything made sense with this one either. But if you only look at the intended process…

But this is where I would like to step in. After all, according to project management, the proposal process is first of all the start of a project, in which the scope is defined.
And if we then use the project triangle, the costs are, as you said, the effort of the data consumers, but the scope is the deprecation itself. And that’s why we have to extend the duration until a deprecation is complete.

note that it is also viable to establish ongoing bot edit to retag new tags as they appear in a given area (if local community is sure that some specific tagging can be autimatically amended/retagged)

I have some ongoing bot edits doing exactly this.

1 Like

That is useful additional info to know what is possible under “automated edits”. Although I at least would prefer a solution where deprecated tags stop being created.

But if it is impossible to totally eradicate such new usages of deprecated tags, such bots might be an option (as you say, in areas where local community approved that) in same cases (e.g. when there is simple one-to-one renaming - it obviously won’t work if old deprecated tag is unclear; e.g. might be interpreted to mean different things for which different tags exist).

1 Like

We have a process already, and it works just fine. That process is the Automated Edits Code of Conduct which of course we’re all aware of. And that’s exactly what I used to guide me when conducting the river modernization project, in which the community replaced, by way of automated edits, a tag which had been deprecated in a proposal, with support from the local communities involved.

The underlying subtext that I am hearing is that we would like it to be easier than what I just described to make mass edits after a tag is deprecated in a proposal.

2 Likes

This process must be able to do much more. It has to take the relevant stakeholders with it. So editors and data users. It must provide an information platform (e.g. by informing them directly). There must be a defined procedure depending on the “Automated Edits Code of Conduct” for a) first double tagging (if possible) and then b) after a transition phase, phasing out the old tag.
In my view, deprecating is a process that can make use of automatic edits, which are then sub-processes, but must still represent other functions.

1 Like

This project wasn’t starting from scratch. There was never a serious risk of rivers vanishing from renderers after retagging, because natural=water enjoys better support (this being an argument in favor of the retagging). The retagging didn’t affect other use cases such as routing or geocoding. The analysis use case was also largely unaffected, as global queries had had to account for both tags for some time.

In other words, this was the best-case scenario. Unfortunately, many desired deprecations start out at a disadvantage because the migration path for data consumers is not as straightforward.

1 Like

Sorry to disappoint but this change did affect geocoding. It is a stellar example of something that might have looked like a bit of a simple cleanup but in reality was a structural change to the tagging that can suddenly pose quite a huge problem on the software side.

Here is the problem: we’ve had this double tagging of rivers with waterway=river/stream + waterway=riverbank. Often both were tagged with a name. This needs some deduplication for geocoding purposes. Nominatim did this by simply ignoring waterway=riverbank. After all, the river line is the more interesting result and ignoring a tag is easy enough. Then @ZeLonewolf came along and changed the tagging from a simple waterway=riverbank to natural=water+water=river. What was previously a primary feature now became an attribute to another tag. The way the tag processing works in Nominatim there is no way to filter by such an attribute, so deduplication of rivers has been broken since this particular mass edit because fixing it requires a change in the design of the software.

Please don’t discuss now the peculiars of how to implement secondary tag filtering. It’s not really the point. The point is that any changes to existing tagging may have an affect on data consumers that you don’t have foreseen. So if you want to have deprecation and ‘tagging cleanup’ in a major way, you have to devise a plan that gets feedback from data consumers already during the RFC phase. I consider any proposal doomed that cannot show that considerable thought has gone into the secondary effects that the change might have.

7 Likes

I stand corrected on this point, and am glad that we agree that deprecation is not normally as simple as it seems on the surface.

It is not double-tagging, they are entirely separate features. One is the path of the river, and the other is the water-covered area of the river.

Tagging a name on a river area is always incorrect tagging. If Nominatim is indexing names on waterway=riverbank or natural=water + water=river, then that behavior is simply incorrect, and has been incorrect for over a decade.

False, both tagging systems were widely in use at the time I became involved, sometimes just one, sometimes just the other, and sometimes both. If Nominatim was failing to correctly handle the former but not the latter style tagging, then it was already failing to properly handle a significant percentage of the river area objects tagged worldwide when I became involved.

If this effort further exposed an issue with Nominatim that was already widely present, I would consider that a positive outcome.

6 Likes

We would do well to establish a clear and predictable process for changing a tagging schema, deprecation, and finally full replacement. Even the smallest change is going to annoy someone.

5 Likes

I do agree, but who is going to do the work?
Using passive voice (“we would do well to xxx”) is almost guaranteeing nothing will happen.

How about you actually suggest a rough outline draft of the text/chapter how you think it should go (click on that arrow and “Reply as linked topic” so others know to follow), and I promise I’ll jump right in and offer changes / more details. In few iterations by parties interested, we might actually have something tangible which can be offered the rest of community for comments. Deal?

1 Like

I hear you say that this is a non-issue, but is it really? I’m a Norwegian mapper, and I’ve used the style you suggest for my own projects where I try to achieve this effect, but it comes with a bitter aftertaste. The technique of mapping with superimposed areas with tag natural=* is not well documented, and does not seem universally accepted. Whether data consumers treat it correctly seems quite hit and miss. I would not translate these cases to the style you suggest before said style:

  1. Is well documented and standardised. For instance, does one use layer=-1 on the area signifying the river/lakebed?
  2. Has gone through a proposal process.

A couple of points:

  • Projects can say what tags they consume by adding an entry at https://taginfo.openstreetmap.org/projects

  • Of all of the proposed tagging changes over the years, including “deprecations”, as a data consumer I’ve only ever been contacted once (by the parcel locker people) to say that a proposal might affect the data that I’m consuming. Thanks to them for doing that.

3 Likes

For what it’s worth, I don’t think the technique of tagging waterway=riverbank and natural=sand (or bare_rock, shingle, etc) on the same object is well documented or universally accepted either. I wouldn’t be surprised if some data consumers did something odd in both cases. I don’t see a problem with the data modeling though. One feature is an intermittent area of water, another feature is the intermittently exposed sand, rock, or shingle. The areas overlap in the real world, so it makes sense to model them as two overlapping areas in OSM as well. Improving documentation to mention this technique is a good idea though.

1 Like

You’re certainly correct. Making a statement like this is easy, but doing the real work to make change is difficult. I probably do not have the available time and energy to get started on this in the near future, but I’d be supportive of such an effort.