Proposal talk:Historic
Thanks for joining the discussion. Help and useful comments are much appreciated! You can best help me if you
- are kind
- keep comments clear and concise
- are constructive: If you dislike something, you can help me a lot if you offer an alternative that you think works better.
These are, of course, not requirements to participate in the discussion.
--Martianfreeloader (talk) 12:55, 11 October 2022 (UTC)
Historic cemetery
There is some reason why the value historic=cemetery is not included in this proposal. I discussed it some time ago on the tagging mailing list and we finally agreed to document the tag on the wiki while the use of the historic=* key was clarified. Why is historic=cemetery not considered in this proposal? --Dcapillae (talk) 13:47, 11 October 2022 (UTC)
- This tag is questionable. See Tag:historic=cemetery. Something B (talk) 14:04, 11 October 2022 (UTC)
- I know because I created that page including alternatives that were discussed on the tagging mailing list. Documenting a tag including other uses and viewpoints should not be a problem for eventual future approval. If I documented it in such detail, it was not to make it questionable and impossible to approve it, but precisely to facilitate the work of whoever decided to put order in the historic key.
On the other hand, other values included in this proposal are also questionable, following the points of view expressed in historic=cemetery. Dcapillae (talk) 14:15, 11 October 2022 (UTC)
Not useful to do this formality top-bottom
It is more beneficial to examine each tag one-by-one to approve them bottom-up, sorting out any issues in the process. One can possibly list out a page of issues for all of them.
"Approving" a de facto tag doesn't improve anything.
--- Kovposch (talk) 14:28, 11 October 2022 (UTC)
- Done. I've reduced to only propose the key itself. --Martianfreeloader (talk) 15:06, 11 October 2022 (UTC)
Values not included
The proposal includes the following text in the "Features/Pages affected" section.
Approve:
- historic=* together with the values listed above
Please remove the reference to "the values listed above" before opening the voting time. It is confusing. It was previously made clear that the values associated with the "historic" key is not related to the approval of this proposal. Thank you. --Dcapillae (talk) 12:10, 3 November 2022 (UTC)
- I'm sure that was just an oversight; I'll take that out now. B-unicycling (talk) 12:45, 3 November 2022 (UTC)
Reworking the key values
I support the general idea of legalizing the key however as stated by Dcapillae the values require quite a cleanup. At this point this key covers both material (e.g. historic=railway_car, historic=rune_stone), immaterial (e.g. historic=district, historic=battlefield and duplicating redundant tags (e.g. historic=church, historic=road). Also some current tags make it ambiguous if they should be applied a similar feature where it exists but has no apparent historic value (e.g. historic=anchor, historic=ship).
I see it in such a way that the key historic=* should be used to describe how a feature has historic value (even if not listed as an official heritage site) while what kind of a landmark it is should be tagged separately irrespective of historic value. Some of the current redundant tag pairs:
- building=* + historic=building
- building=church + historic=church
- building=wayside_shrine + historic=wayside_shrine
- man_made=cross + historic=wayside_cross
- highway=* + historic=road
- boundary=marker + historic=boundary_stone
- landuse=cemetery + historic=cemetery
I'd divide the current list of values into a set of immaterial and/or exclusively history-related ones (e.g. historic=archaeological_site) to be aproved within this proposal and another set of purely-material values to be reviewed later in separate proposals. --VileGecko (talk) 22:38, 14 November 2022 (UTC)
- A lot of these are not actually synonyms, for example a man_made=cross and a historic=wayside_cross are not the same. Crosses on top of hills/ mountains which require hiking and even climbing are not exactly wayside. Neither are Celtic crosses in the middle of a graveyard (moved=yes) or a field. Same for boundary=marker and historic=boundary_stone: A tree can be a boundary marker. And so on...B-unicycling (talk) 23:04, 14 November 2022 (UTC)
- Still most of the times they're the same with some exceptions. I'd rather have a larger category for crosses old or new, whether placed in a chuchyard, by a road or at the summit of a mountain (excluding cross-shaped tombstones) instead of having several separate categories for crosses with religious meaning, e.g.
- Also recently errected crosses often made of modern materials or with modern techniques have no place in the historic=* key in my opinion, (example 1, example 2, example 3).
- As for markers - this is another set of similar features which are now found in several different keys depending on their use: marker=*, boundary=marker, historic=boundary_stone, historic=milestone, highway=milestone, railway=milestone, waterway=milestone - all those are similar in appearance and materials and serve a similar purpose of denoting a point - freestanding or marking part of a line or an area. If a marker has historic significance then historic=yes should be added also denoting a period with historic:period=*. In addition if a marker is no longer used it should be tagged as disused=yes if it is still in its original place or moved=yes if it has been transfered to an exposition. Trees used as markers should be tagged both as natural=tree and marker=*. --VileGecko (talk) 11:48, 15 November 2022 (UTC)
intention of this proposal?
It is quite unclear what is the intention of this proposal:
- If it is just minor clarifications and formatting fixes to the wiki, that can be done without proposal.
- If it is just to rubber-stamp status of historic=* from "de-facto" to "approved" (As "Features/Pages affected" section seems to suggest), that is unneeded and even counterproductive IMHO (e.g. "de-facto" indicating million of uses has far greater weight to me than being merely "approved" which means few dozen people didn't find glaring serious problem with the proposal -- and because main use of proposal process is to find glaring holes in proposed changes; if no changes are proposed, then the voting process is quite useless waste of everyone's time).
- The "Rationale" section mentions a lot of tags of this key and their status. Why? Is the intention to change their status to "approved" too? It is not mentioned in the link to "Key:historic" in "Features/Pages affected" but use of auto-shown "=*" is ambiguous there. But if they are unrelated to the proposal, why bring it up? And if the intention is to set them to "Approved" too, then (apart from it being quite subterfuge!) is is not clearly (i.e. at all!) defined what happens if the proposal is rejected? Surely the status of all existing "in-use" ones should be degraded to "rejected" then?
- There is missing vote date in infobox.
- "Changelog" section also misses 1st voting start, 1st voting abort, 2nd voting start etc. milestones
- when first voting was aborted, all concerns raised by people so far should've been addressed and new RFC period started, before initiating another voting.
- if would be nice if "External discussions" page (called "comments" here?) had a link to specific discussion on tagging mailing list / second thread, a not just a generic pointer to the list itself.
- Also, what @Dieterdreist: and @ZeLonewolf: said in first round, esp. voting for key itself is unclear. I also do not see their concerns addressed at all!
- As voting was reset, I would think those whose votes have been nullified (@ZeLonewolf:, @Dieterdreist:, @Jrachi:, @Mateusz Konieczny:, @TSFX:) should've been personally invited to re-vote
- Also, on each re-initiation of proposal status (like re-initiaing the vote, rejection or approval of it, falling back to RFC etc) proponent should post a notice about it in all external places where it was discussed (e.g. discourse forum, tagging mailing list, etc)
--mnalis (talk) 23:38, 14 November 2022 (UTC)
- @Mnalis: If this proposal is in fact intended to be an omnibus approval of the enumerated values, then I don't really know where to begin. The proposal doesn't say why each of them merits approval, other than the fact that they're in use. historic=* isn't the only thematic top-level key, but it's the most heterogeneous one. This makes it difficult to come up with any generalizations about the values' suitability, compared to for instance the previous blanket approval of a key, marker=*, or the closest thing to a recent approval of a thematic key, hazard=*. On the other hand, if the intention was to sanction "user-defined values" of historic=*, basically turning it into a freeform key [1], then the proposal lacks an explanation of how it would coexist with or supersede other tags. For example, historic buildings are often tagged building=* historic=building; is the suggestion that building=* be deleted from these features? Could a mapper unilaterally decide that a historic fountain is best tagged historic=fountain instead of amenity=fountain? We don't have an approved tag for hitching posts yet, so could someone focused on historically significant hitching posts introduce historic=hitching_post instead of amenity=hitching_post, which is merely in use? #Not useful to do this formality top-bottom was ostensibly resolved by only proposing the key itself, but that doesn't come through clearly in the proposal text and makes the rationale even less relevant to the proposal. – Minh Nguyễn 💬 02:04, 15 November 2022 (UTC)
values are approved
The proposal writes about approved values, but what is actually approved are tags, i.e. key=value pairs. —Dieterdreist (talk) 08:55, 15 November 2022 (UTC)
Reopening of Voting
Has Voting on this proposal actually been reopened? I can see people adding votes recently, but the status of the page hasn't changed.