Yes, we can collaboratively work on any page. From my understanding, people used “draft” for proposals which they thought were not yet “finished”, and changed it to “proposed” after they sent out the RFC. I do not see the problem with this status, even if it remains for a long time, and if we change the initial status from draft to proposed, we will probably have abandoned proposals where we now have abandoned drafts.
Generally most of the people editing the wiki are very pushy for a clear status of the pages, and either bring the proposals to voting or set them to abandoned (typically other people’s proposals).
Why couldn’t we keep some drafts for years until someone picks up the proposal or decides that its content is already implemented in the meantime even if it wasn’t voted and remained a draft.
I have no problem with PROPOSALS using statuses like draft/voting/rejected
but what is the point of Cs:Key:wikimedia_commons - OpenStreetMap Wiki sitting with draft status? Or Tag:path=desire - OpenStreetMap Wiki ?
Even if their proposals are in this status: status of tags is different (de facto for the first one,in use for the second one)
What do you think about including a tag state chart like this?
This could be a clear idea of the valid status, and the transitions (if any) between them.
This chart makes me confused.
- What means placing statuses at the same altitude?
- What means coloring statuses at the same colors?
- There are needed lifecycle chart for EVERY status, including “de facto”, “inactive” “deprecated” and “obsoleted”.
- There are needed description for differences between “in use”, “de facto” and “undefined”.
- Also, I can’t understand, what difference is between “inactive” and “deprecated”. What do you mean?
P.S. Also, I must say, It is very nice-looking chart. 
P.P.S. Sometimes new tag can be spreaded “de facto” by author and friends, then added to editor soft, and only after this two stages - proposed in wiki.
I would have expected “imported” to be in red color.
The arrows to “abandoned” should also go in the other direction, the same is true for “canceled”. And you can always repropose an abandoned or failed proposal, so rejected could also have arrows to draft (because you shouldn’t repropose a failed proposal without trying to improve it before)
Sometimes, “in use” tags are formally proposed later on…
Thank you Pavel for these observations. I think you hit the issue regarding the definition on the wiki. In fact, I took all these status from the following pages on the wiki, but I made some assumptions that are probably wrong:
Let’s start with the colors:
I recognize that for this first chart version I didn’t use the exact same colors as in the wiki.
For the last 5 status on the table, they do not specify a color in the wiki; however, they are represented in the wiki as this:
- “de facto” the same as “approved”.
- “deprecated” the same as “rejected”.
- “discardable” the same as “rejected”.
- “imported” with grey letter and no fill.
- “in use” with black letter and no fill.
Also, I see these differences between the definition and how they are represented:
- “proposed” has black letters on dark gray fill on pages.
- “rejected” has black letters on very dark gray fill on pages. As stated in the Tag Status page.
- “abandoned” with the same color as in “rejected”.
- “obsolete” (without the final d) in the same color as in “rejected”.
Also, there is a key with status “imaginary”. Just one entry that we could ignore.
You can check the colors by looking at: Category:Feature descriptions by status - OpenStreetMap Wiki
Let’s decide and document which should be the colors. What I propose is to change the “Proposal process” page with the currently used colors. What do you think?
Category:Feature descriptions with incorrect status value - OpenStreetMap Wiki is now listing also pages which set status to draft
There were no comments in Talk:Wiki - OpenStreetMap Wiki - but it seems clearly problematic status for tag and if people protest it is easy to revert.
“draft” clearly remains as a valid status for proposals
Regarding the arrows, I agree with you. I made this table to be sure the “origin” and “destinations”. Please let me know what you think.
There are many status that do not point anywhere.
In fact, the problem I see is that we have mixed “proposals” with “tags”. A proposal status is completely different from a tag status. That’s why you have issues identifying invalid tag status. Also, I had issues drawing the state chart, that finally nobody understands.
Now, what I propose is to have 2 sets of status based on this table:
I propose to have just these tag status:
- undefined
- in use
- de facto
- approved
- deprecated
- discardable
And these “connections”:
Some nitpicking:
tags may be deprecated without formal proposal
proposal with draft status may be also about tag that is deprecated discardable or obsolete or any other. The same goes for all other proposal statuses like approved or rejected.
Nearly all proposals with approved status have relate tags in approved status, but tags may be later deprecated and so on.
Also, this table changes what undefined means - previously such tags would be typically tagged in use (see Template:Tag status values - OpenStreetMap Wiki ) Is it intentional?
Your discarbable definition mismatches actual use. Is it intentional?
Regarding the deprecation, who or what decides to deprecate a tag? I think this should follow a formal process. Otherwise, anyone can deprecate a tag just because he does not agree with it.
Regarding the tag status like: obsolete or rejected, they do not reflect a status on its own, but the associated proposal status. I think this creates a conflict between both kind of status, and these status should be independent.
Undefined status is defined like “unclear situation”. But is it unclear based on its related “proposal”, or in the quantity of mapped objects or the years being used? Because, undefined tags are in fact used on the map, and this status could be considered at the same level as “in use” or “de facto”: They are used in the map without an approved proposal.
Regarding “de facto” the definition says “heavily used”. But what is heavily? Also, it use the word “widespread”, but what does exactly mean? more than a country? A similar problem to the “undefined” status.
Finally, for discardable it was a mistake from my side.
Again, what do you think about simplifying the status for tags?
At least discussion on a public place with significant OSM user population (tagging mailing list for example) where everyone agrees should be also OK
Yes, there is no clear and mechanical definition here and I do not expect it to be possible
In general I agree (though I prefer to eliminate them one by one - with draft as the current target), rather than at the same time remove some and redefine others
deprecation only works if you can convince a vast majority of users to not use the tag anymore (or at least the major gatekeepers like carto, josm and id devs). Our wiki is descriptive and not prescriptive, most people do not look up tags frequently, so even if the wiki stated a tag was deprecated, it would have little effect unless the idea was generally shared. So even with formal deprecation through wiki voting there is no guarantee that a tag actually becomes deprecated, you need significant community buy in for this.
IMHO defacto means there is significant usage, ideally also tool support, and no competing/alternative tags with significant usage, and ideally no known critique against the tags.
Ok, let’s do it slowly. Regarding current “draft” status which is marked as invalid, how can I correct them? To which status they should be changed? which criteria should I use?
Looking through Category:Feature descriptions with incorrect status value - OpenStreetMap Wiki
-
move to proposal namespace, reformat and request deletion of redirect for proposals with basically no use and mismatching tagging in general and stuck in this state: Revision history of "Proposed features/Key:woody species 100m" - OpenStreetMap Wiki and Key:woody species 100m - OpenStreetMap Wiki
-
updated outdated translation page: Difference between revisions of "FR:Key:wikimedia commons" - OpenStreetMap Wiki
-
mark used ones as
in useDifference between revisions of "Tag:tower:type=diving" - OpenStreetMap Wiki (and do the same with translated pages)
For some I am unsure what would be the best action, but that can be reviewed later.
I am trying to follow your guidelines, but this is very complicated. There are cases like this one amenity=car_wash - OpenStreetMap Wiki :
It seems this is a problem due to the initial Data Item creation. What should we do? Delete the status for “limited to language” and leave just one state?
Should we delete all these language restrictions? Personally I do not see any valid usage? The status is the same no matter the language.
Another thing: what about when there is a status in the Data Item which is different to the values on the wiki page (valueDescription)? What do you think about deleting the status from the wiki page and leave the one from the Data Item? Specially when there are conflicts.
It seems this is a problem since the initial Data Item creation. What should we do? Delete the status for “limited to language”?
with amenity=car_wash I’d go for defacto everywhere, draft just makes no sense.
I partly agree it mostly doesn’t make sense to have different status in different languages, it is just a relict from outdated translations, and languages aren’t countries or regions, they are valid everywhere.
And can I assume the English page is the “correct” one?
I have written some queries for the SQLite database from TagInfo, and they can give me the pages that have status differences between English pages and other languages: User:Angoca - OpenStreetMap Wiki
Personally I ignore data items completely and fill correct data in infoboxes of wiki pages.
Sometimes I remove invalid/broken info from data items.