[Tagging] Rules (was: Feature proposal - Approved - deprecate embassy=embassy)

[nathan case]

I'm not really sure where I fall on this, but to help my understanding…

1 – Those who have objected to specific deprecations via the proposal process, do you also object to deprecating tags through the proposal process _as part_ of proposing a new tag? This seems quite a common practice (i.e. introduce X=Y tagging and deprecate A=B tagging all in the same proposal - because one scheme is intended to "replace"/"improve upon" another) - but is this acceptable?

2 - To quote the proposal process wiki page: " The proposal process was designed to as mechanism to document that a rough consensus exists within the community on how to model and tag a feature that previously had no established tagging."

This is clearly not the only use-case any longer. Some recent (maybe older ones too?) proposals are about refining tagging/developing tagging schemes. If we do want to stick rigidly to what the proposals process was designed for, then we should be mindful of that. Alternatively, we could adapt and recognise that the proposal process does have some others uses too.

3 - Another quote: “As a non-binding documentation change, the outcome of a proposal vote does not compel a change in tools which use and generate OSM data”

It seems that this could hold just as well for a tag deprecation as it does for a tag creation? Just as someone proposing a tag for creation and some mappers voting to approve it does not force anyone to pay attention to it, couldn't the same be said for deprecation? In fact the deprecation template says something very similar.

Thanks.


-----Original Message-----
From: Topographe Fou <letopographefou at gmail.com> 
Sent: 04 February 2022 08:04
To: Tag discussion, strategy and related tools <tagging at openstreetmap.org>
Subject: Re: [Tagging] Rules (was: Feature proposal - Approved - deprecate embassy=embassy)

To all,

I agree with most of what is said here except on one point.

On the point that there might be more important stuf to do to have a cleaner database than voting on deprecation but to everyone its own capabilities. To change osm infrastructure it's a big and long term work which implies to be deeply involved (and known) within the project. It also implies trust which can I think only be earned by resolving basic issues with the community before, showing its ability to go throught the maze without becoming crazy. We all know it is also something which fails more than it succeeds because it's a hard thing to achieve without breaking everything and even with support from some gatekeepers (for the good or the bad). So I don't see why one cannot push some basic topics on the table such as deprecating some tags or schemas if he don't feel comfortable to change OSM API.

Personnaly I'm worried about peoples trying to lock the project (while claiming it is an open project) and saying that "you must not do this". I don't think they are doing it with bad intentions, I believe they try to smoother the curve giving more time to strengthen ideas (which is ok), but the consequence is that many think that " we must not do this", end of the discussion for the next 10 years to come. Let's all not be blured and convert a personal opinion to a consensus. I too often see this while reading the list.

I'm all in for a strong osm database (like all of us I guess) and for me this imply the ability to structure the data we have, not only the future data we get. Deprecation if one way of achieving it. A more structured database improves the overall quality and usage of OSM data. Even iD does it by forcing some tag conversions in the backoffice (hidden mechanical edit), and we all know how they stopped giving too much attention to this list and to their gatekeepers (for the good or the bad). And OSMF does not complain that much. 

A second option would be to have a second osm database, oriented to data users, in read only, which would be an automatically cleaned version of the existing one, targetting data users which focus on stable data. This way when two schemas for a same thing exists, scripts can fix this. Also it might help to complete some missing tags (for instance if wikidata tag exists, it creates all wikipedia tags).

So let's stop saying that depreciation is forbidden by whoever law. And stop thinking it's forbidden by community consensus.

LeTopographeFou


	  Message original  	


De: frederik at remote.org
Envoyé: 4 février 2022 2:29 AM
À: tagging at openstreetmap.org
Répondre à: tagging at openstreetmap.org
Objet: Re: [Tagging] Rules (was: Feature proposal - Approved - deprecate embassy=embassy)


Hi,

On 2/3/22 15:15, s8evq wrote:
> You write that only a fraction of the OSM contributors are active on this mailing list. How is that, you think? There's no open atmosphere here.

I don't think that any mailing list could ever handle *more* than a fraction of OSM contributors. People would join for a day, receive 100 messages, and quit again because they can't handle that much.

And that's not even opening the language can of worms.

Regarding the "open atmosphere", personally, what I always resist is when people try to reduce openness, for example by trying to dictate to others which tags are "right" and "wrong".

> These old-timers fail to see that a big group of contributors come to OSM with good intentions, and make it a better project, with better, cleaner data structure. They fail to even consider the thoughts and ideas of this large group.

The problem is that all these people with good intentions can think of is making OSM more controlled. More rules, stricter enforcement of stuff so we can all enjoy the better, cleaner data structure. Oh, you only speak Portuguese or Bangla, sorry, you can'T be part of this big group of cool people who invent the nice and clean OSM because they're all on the tagging list debating in English.

> Just consider that a rather large group of contributors thinks a clean data structure is important (more than tag-anything-you-like), and you'll have to do more than just keep repeating "You're wrong".

There are ways to work on cleaning up the OSM data structure but discussing which tags should be preferred over which other tags ranks very far down in that list. It would be much more important to work on a better way of representing area/polygon objects, and probably on better ways to communicate changes (for example, a way to upload just a single tag change for an object rather than a full new object, and a way to record edit operations so a history viewer could tell you "this way has been split" rather than "ah, this way has been shortened by 6 nodes and another way has been created that seems to have just these same nodes".
Things like that. But, as Andy said in another post, any non-trivial change in OSM has (a) a political component - selling your change to those who have to develop the software to support it - and (b) a management component - managing the implementation of the change, communicating, testing, and so on.

It is naive to believe you can have 30 people vote on a change and whoops, there it is.

Bye
Frederik

--
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"

_______________________________________________
Tagging mailing list
Tagging at openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
Tagging at openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging