Proposal process: Difference between revisions

From MLEB Master
Jump to navigation Jump to search
Osm-Admin (talk | contribs)
No edit summary
Tag: Manual revert
Osm-Admin (talk | contribs)
Marked this version for translation
Line 4: Line 4:


<translate>
<translate>
<!--T:78-->
This page describes the '''proposal process''', which is one of multiple ways to introduce and discuss '''new [[tags]]''' for features and properties. The [[#Non proposed features|other ways]] are often undocumented. 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. The open voting process acts as supporting evidence that the proposal author has adequately reflected feedback from interested parties and meaningfully addressed objections posed.  The outcome of a proposal vote is a change in documentation on the wiki.
This page describes the '''proposal process''', which is one of multiple ways to introduce and discuss '''new [[tags]]''' for features and properties. The [[#Non proposed features|other ways]] are often undocumented. 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. The open voting process acts as supporting evidence that the proposal author has adequately reflected feedback from interested parties and meaningfully addressed objections posed.  The outcome of a proposal vote is a change in documentation on the wiki.


<!--T:79-->
As a documentation change, an approved proposal is not binding on any mapper, software developer, or data consumer.  However, tagging backed by an approved proposal is usually regarded as having survived a level of community vetting and scrutiny, and thus carries more weight when compared to alternative methods of mapping a feature. OpenStreetMap does not restrict mapping to tagging schemes backed by an approved proposal -- you can still use [[any tags you like]]. Nonetheless, there is benefit to mappers and data consumers alike in agreeing on a common data model and corresponding tags by reducing conflict between mappers, edit wars, and tagging disputes.
As a documentation change, an approved proposal is not binding on any mapper, software developer, or data consumer.  However, tagging backed by an approved proposal is usually regarded as having survived a level of community vetting and scrutiny, and thus carries more weight when compared to alternative methods of mapping a feature. OpenStreetMap does not restrict mapping to tagging schemes backed by an approved proposal -- you can still use [[any tags you like]]. Nonetheless, there is benefit to mappers and data consumers alike in agreeing on a common data model and corresponding tags by reducing conflict between mappers, edit wars, and tagging disputes.


<!--T:80-->
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''', such as the [[standard tile layer]] renderings or [[editor]] [[preset]]s.  An approved proposal will not be automatically rendered or added to presets; this is at the discretion of the developers and maintainers of those tools. Also, a vote result is '''never''' permission for large-scale re-tagging of existing objects. See [[automated Edits code of conduct]] for more about this topic.
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''', such as the [[standard tile layer]] renderings or [[editor]] [[preset]]s.  An approved proposal will not be automatically rendered or added to presets; this is at the discretion of the developers and maintainers of those tools. Also, a vote result is '''never''' permission for large-scale re-tagging of existing objects. See [[automated Edits code of conduct]] for more about this topic.


<!--T:81-->
This page is designed to assist anyone considering putting forward a tag [[proposal]], with the aim of speeding the tag proposing process. Like the proposal process itself, it attempts to describe the rough consensus that has accumulated over the years over the best ways to assess and document community consensus on mapping and tagging. It is not a set of absolute rules, but rather a helpful guide for community members.
This page is designed to assist anyone considering putting forward a tag [[proposal]], with the aim of speeding the tag proposing process. Like the proposal process itself, it attempts to describe the rough consensus that has accumulated over the years over the best ways to assess and document community consensus on mapping and tagging. It is not a set of absolute rules, but rather a helpful guide for community members.


== Proposal list ==
== Proposal list == <!--T:82-->
All proposals are categorised by the status set in its [[Template:Proposal Page|Proposal Page template]]:
All proposals are categorised by the status set in its [[Template:Proposal Page|Proposal Page template]]:


<!--T:83-->
{{:Proposals/cats}}
{{:Proposals/cats}}


==Before creating a proposal==
==Before creating a proposal== <!--T:84-->
=== Does it already exist? ===
=== Does it already exist? ===
#Search for possible documentation on this Wiki. <br />For example:
#Search for possible documentation on this Wiki. <br />For example:
Line 32: Line 37:
#It might also be a good idea to send an email to the [https://lists.openstreetmap.org/listinfo/tagging tagging mailing list], describe the feature you want to tag and see if there are tags in use but hard to find or not yet documented.
#It might also be a good idea to send an email to the [https://lists.openstreetmap.org/listinfo/tagging tagging mailing list], describe the feature you want to tag and see if there are tags in use but hard to find or not yet documented.


===Significance===
===Significance=== <!--T:85-->
Is the tag you are considering for proposal, worthy of a new tag? Consider possible uses for the map, and specifically the data you want to add.
Is the tag you are considering for proposal, worthy of a new tag? Consider possible uses for the map, and specifically the data you want to add.


<!--T:86-->
This is a difficult judgement to make: if you want to tag it, then that is generally reason enough to create a tag.
This is a difficult judgement to make: if you want to tag it, then that is generally reason enough to create a tag.


<!--T:87-->
* Is it a destination in itself?
* Is it a destination in itself?
** People may search for some locations, for example: a national park, a bus station, a street address or a rubbish dump, because they want to visit that location.
** People may search for some locations, for example: a national park, a bus station, a street address or a rubbish dump, because they want to visit that location.
Line 53: Line 60:
** Walkers would want to know surfaces/conditions of walking tracks.
** Walkers would want to know surfaces/conditions of walking tracks.


=== Compatibility with established practices ===
=== Compatibility with established practices === <!--T:88-->
OpenStreetMap has some established [[good practice]]s. Your proposal should follow those or at least explain why it does not do it. Please have a look at them.  
OpenStreetMap has some established [[good practice]]s. Your proposal should follow those or at least explain why it does not do it. Please have a look at them.  


<!--T:89-->
Specifically relevant for proposals might be
Specifically relevant for proposals might be
; [[Verifiability]]
; [[Verifiability]]
Line 65: Line 73:
: There are some conventions about naming [[key]]s and values. Following them will help mappers to estimate the meaning of your tags without reading the documentation. Using a [[Semi-colon value separator| semicolon]] should be considered especially carefully.  
: There are some conventions about naming [[key]]s and values. Following them will help mappers to estimate the meaning of your tags without reading the documentation. Using a [[Semi-colon value separator| semicolon]] should be considered especially carefully.  


<!--T:90-->
Skimming though [[Editing Standards and Conventions]] might be helpful as well. Please also consider the [[Good_practice#Map_what.27s_on_the_ground|On the Ground Principle]] (about current versus old data), {{key|fixme}} (for estimations), and [[names]] (names versus descriptions, avoiding abbreviations) if any of them might conflict with your ideas.
Skimming though [[Editing Standards and Conventions]] might be helpful as well. Please also consider the [[Good_practice#Map_what.27s_on_the_ground|On the Ground Principle]] (about current versus old data), {{key|fixme}} (for estimations), and [[names]] (names versus descriptions, avoiding abbreviations) if any of them might conflict with your ideas.


===Due Diligence===
===Due Diligence=== <!--T:91-->
Your proposal is more likely to be accepted by the community if you take steps to research and vet your proposal before presenting it in front of a global audience.  Some tips for success include:
Your proposal is more likely to be accepted by the community if you take steps to research and vet your proposal before presenting it in front of a global audience.  Some tips for success include:
* Research whether tagging for this feature (or similar) has been discussed before, by searching the [[Mailing_lists#Search_the_mailing_lists|mailing lists]] or other forums.  Consider what objections or concerns were raised in those discussions, and adjust your proposal if necessary to satisfy the concerns.  It may not be possible to please everyone, but you will have the best chance of success if you make the effort to address as many concerns as possible.  Provide links to these discussions in the "External Discussions" section; it shows that you have done your homework and are aware of past discussions that may have occurred.
* Research whether tagging for this feature (or similar) has been discussed before, by searching the [[Mailing_lists#Search_the_mailing_lists|mailing lists]] or other forums.  Consider what objections or concerns were raised in those discussions, and adjust your proposal if necessary to satisfy the concerns.  It may not be possible to please everyone, but you will have the best chance of success if you make the effort to address as many concerns as possible.  Provide links to these discussions in the "External Discussions" section; it shows that you have done your homework and are aware of past discussions that may have occurred.
Line 75: Line 84:
* Assume that the reader is not an expert in the topic or in the associated tagging.  Give a brief introduction suitable for non-experts that allows them to understand the feature being described, the state of existing (inadequate) tagging, and how your proposal fills that gap.  Do not assume prior knowledge, especially when proposing additions or changes to complex tagging schemes.
* Assume that the reader is not an expert in the topic or in the associated tagging.  Give a brief introduction suitable for non-experts that allows them to understand the feature being described, the state of existing (inadequate) tagging, and how your proposal fills that gap.  Do not assume prior knowledge, especially when proposing additions or changes to complex tagging schemes.


== Creating a proposal ==
== Creating a proposal == <!--T:92-->
You can easily create a pre-formatted proposal here.
You can easily create a pre-formatted proposal here.


<!--T:93-->
'''Read these instructions ''before'' creating the page.'''  
'''Read these instructions ''before'' creating the page.'''  


<!--T:94-->
# Create the page using the tool below. The tool does not ''immediately'' create the page, but opens the editor for the page that will be created if saved.  
# Create the page using the tool below. The tool does not ''immediately'' create the page, but opens the editor for the page that will be created if saved.  
# Making no edits, '''immediately''' save to convert the substituted values to text. <br>[[File:Save proposal first.png|border|frameless|761x761px]]
# Making no edits, '''immediately''' save to convert the substituted values to text. <br>[[File:Save proposal first.png|border|frameless|761x761px]]
Line 86: Line 97:
# Follow the instructions in the comments under each of the headings to draft the proposal documentation.
# Follow the instructions in the comments under each of the headings to draft the proposal documentation.


<!--T:95-->
'''Create here:'''
'''Create here:'''
<div style="float:left;">
<div style="float:left;">
Line 99: Line 111:
</div>{{Clear}}
</div>{{Clear}}


<!--T:96-->
If you edit using the Wikicode editor instead of the Visual Editor, what is displayed will be a bit different. Instructions still apply: (1) create page (2) save to generate text, (3) edit page to fill the template and save again.
If you edit using the Wikicode editor instead of the Visual Editor, what is displayed will be a bit different. Instructions still apply: (1) create page (2) save to generate text, (3) edit page to fill the template and save again.


<!--T:97-->
If you have technical trouble with creating a proposal page, feel free to ask for help by sending a message to the [https://lists.openstreetmap.org/listinfo/tagging tagging mailing list], you can ask for technical help also elsewhere.
If you have technical trouble with creating a proposal page, feel free to ask for help by sending a message to the [https://lists.openstreetmap.org/listinfo/tagging tagging mailing list], you can ask for technical help also elsewhere.


<!--T:98-->
Optionally let people know of your new proposal by [https://lists.openstreetmap.org/listinfo/tagging subscribing to tagging mailing list] and [mailto:tagging@openstreetmap.org sending a mail].
Optionally let people know of your new proposal by [https://lists.openstreetmap.org/listinfo/tagging subscribing to tagging mailing list] and [mailto:tagging@openstreetmap.org sending a mail].


=== Proposal page template ===
=== Proposal page template === <!--T:99-->
You may also create a proposal directly by copying and pasting into a new page
You may also create a proposal directly by copying and pasting into a new page


<!--T:100-->
Create a new wiki page such as ''Proposed_features/your_proposition_name'' ([https://www.mediawiki.org/wiki/Help:Starting_a_new_page MediaWiki Help:Starting a new page]) and then fill in the proposal page template and page details described below. Set the status to <code>Draft</code> and set the <code>draftStartDate={{#time: Y-m-d}}</code> value (YYYY-MM-DD):
Create a new wiki page such as ''Proposed_features/your_proposition_name'' ([https://www.mediawiki.org/wiki/Help:Starting_a_new_page MediaWiki Help:Starting a new page]) and then fill in the proposal page template and page details described below. Set the status to <code>Draft</code> and set the <code>draftStartDate={{#time: Y-m-d}}</code> value (YYYY-MM-DD):


<!--T:101-->
''Place the following wiki text at the top of the page, and fill in the brief summary content fields:'' (See also: {{t|Proposal_Page}})
''Place the following wiki text at the top of the page, and fill in the brief summary content fields:'' (See also: {{t|Proposal_Page}})
<syntaxhighlight lang="moin">
<syntaxhighlight lang="moin">
Line 128: Line 145:
}}
}}


== Proposal ==
== Proposal == <!--T:102-->
<!-- A short statement of what you propose, including a list of what tag(s) are being proposed to be added, changed, or deprecated -->
<!-- A short statement of what you propose, including a list of what tag(s) are being proposed to be added, changed, or deprecated -->


<!--T:103-->
<!-- Which Database Elements (nodes, ways, areas, relations) each of the tags can be used on could be included here or under the Tagging heading, or both. -->
<!-- Which Database Elements (nodes, ways, areas, relations) each of the tags can be used on could be included here or under the Tagging heading, or both. -->


== Rationale ==
== Rationale == <!--T:104-->
<!-- Explanation of why the proposal is needed, and why you chose the specific key and value of the tag. Compare with similar tags or previous proposals, if relevant. Consider significance and potential uses of the data.-->
<!-- Explanation of why the proposal is needed, and why you chose the specific key and value of the tag. Compare with similar tags or previous proposals, if relevant. Consider significance and potential uses of the data.-->


<!--T:105-->
<!-- Keep the tag short while still being logical and descriptive enough to need little explanation. Avoid tag names which might cause confusion with a  different tag. British English terms are preferred, when possible -->
<!-- Keep the tag short while still being logical and descriptive enough to need little explanation. Avoid tag names which might cause confusion with a  different tag. British English terms are preferred, when possible -->


== Tagging ==
== Tagging == <!--T:106-->
<!--  
<!--  
A table, list, or set of subheadings explaining each tag:
A table, list, or set of subheadings explaining each tag:
Line 148: Line 167:
-->
-->


== Examples ==
== Examples == <!--T:107-->
<!-- Examples of what elements should be tagged: real-world images, openstreetmap.org screenshots, links to OpenStreetMap elements that use the proposed tagging. -->
<!-- Examples of what elements should be tagged: real-world images, openstreetmap.org screenshots, links to OpenStreetMap elements that use the proposed tagging. -->


== Rendering ==
== Rendering == <!--T:108-->
<!-- Optional rendering suggestion, if relevant -->
<!-- Optional rendering suggestion, if relevant -->


== Features/Pages affected ==
== Features/Pages affected == <!--T:109-->
<!-- List of wiki pages that would be edited if the proposal is approved -->
<!-- List of wiki pages that would be edited if the proposal is approved -->


== External discussions ==
== External discussions == <!--T:110-->
<!-- Links to mailing lists, other forums where this proposal has been discussed... -->
<!-- Links to mailing lists, other forums where this proposal has been discussed... -->


== Comments ==
== Comments == <!--T:111-->
<!-- There must be at least 2 weeks set aside for comment on the proposal. Do not go to a vote without addressing the comments and fixing any problems with the proposal. The wiki talk page is used for comments, it is linked from the proposal page for those unfamiliar with wikis. -->
<!-- There must be at least 2 weeks set aside for comment on the proposal. Do not go to a vote without addressing the comments and fixing any problems with the proposal. The wiki talk page is used for comments, it is linked from the proposal page for those unfamiliar with wikis. -->


<!--T:112-->
Please comment on the [[{{TALKPAGENAME}}|discussion page]].
Please comment on the [[{{TALKPAGENAME}}|discussion page]].
</syntaxhighlight>
</syntaxhighlight>


== Propose ==
== Propose == <!--T:113-->
Once the proposal contents are fully described, you can propose it to the community.
Once the proposal contents are fully described, you can propose it to the community.
=== Propose ===
=== Propose ===
Line 179: Line 199:
# Consider sending your proposal to some additional [[contact channels]] to further increase community feedback and knowledge of it (not everyone subscribes to the tagging mailing list).
# Consider sending your proposal to some additional [[contact channels]] to further increase community feedback and knowledge of it (not everyone subscribes to the tagging mailing list).


=== Respond ===
=== Respond === <!--T:114-->
Look through comments that arise from the mailing lists, chats, and the proposal Wiki Talk page.  
Look through comments that arise from the mailing lists, chats, and the proposal Wiki Talk page.  


<!--T:115-->
When a discussion in a section created by another user on the proposal's Talk page is considered "resolved", you can add the [[Template:Resolved|<code><nowiki>{{Resolved|1=message}}</nowiki></code>]] Template directly below the section heading with an included message.
When a discussion in a section created by another user on the proposal's Talk page is considered "resolved", you can add the [[Template:Resolved|<code><nowiki>{{Resolved|1=message}}</nowiki></code>]] Template directly below the section heading with an included message.


<!--T:116-->
Adjust, even if it means changing key parts or tags, and continue to build a strong proposal according to community feedback so that it has a good chance of passage once voted on.
Adjust, even if it means changing key parts or tags, and continue to build a strong proposal according to community feedback so that it has a good chance of passage once voted on.


<!--T:117-->
Note that it is not necessary to implement all suggestion and requests. While many will be useful, it is possible to receive recommendations contradictory with each other, some can be also misguided.
Note that it is not necessary to implement all suggestion and requests. While many will be useful, it is possible to receive recommendations contradictory with each other, some can be also misguided.


<!--T:118-->
If there are many changes to the proposal, it may be a good idea to document them in a timeline in a separate section called <code>Changes</code> for reference.
If there are many changes to the proposal, it may be a good idea to document them in a timeline in a separate section called <code>Changes</code> for reference.


== Voting ==
== Voting == <!--T:119-->
''You still have to be subscribed to the Tagging mailing list for these steps.''
''You still have to be subscribed to the Tagging mailing list for these steps.''


=== Requirements before ===
=== Requirements before === <!--T:120-->
Make sure these your proposal meets these requirements before initiating voting.
Make sure these your proposal meets these requirements before initiating voting.
* At least two weeks have passed since start of a RFC.
* At least two weeks have passed since start of a RFC.
Line 200: Line 224:
* The proposal is in its final state. It '''cannot''' be changed once voting starts.
* The proposal is in its final state. It '''cannot''' be changed once voting starts.


=== Initiate ===
=== Initiate === <!--T:121-->
# Set these parameters in the [[Template:Proposal page|<code>Proposal page</code>]] template at the top of the page:
# Set these parameters in the [[Template:Proposal page|<code>Proposal page</code>]] template at the top of the page:
## <code>|status = Voting</code>  
## <code>|status = Voting</code>  
Line 208: Line 232:


<syntaxhighlight lang="moin">
<syntaxhighlight lang="moin">
== Voting ==
== Voting == <!--T:122-->
{{Proposed feature voting}}
{{Proposed feature voting}}


<!--T:123-->
<!-- Cheat sheet:
<!-- Cheat sheet:
{{vote|yes}} OPTIONAL MESSAGE HERE --~~~~
{{vote|yes}} OPTIONAL MESSAGE HERE --~~~~
Line 216: Line 241:
{{vote|abstain}} YOUR COMMENTS HERE --~~~~
{{vote|abstain}} YOUR COMMENTS HERE --~~~~


<!--T:124-->
Place your vote below, at the end of the list. -->
Place your vote below, at the end of the list. -->
</syntaxhighlight>
</syntaxhighlight>


=== Notify ===
=== Notify === <!--T:125-->
# [mailto:tagging@openstreetmap.org?subject=Feature%20Proposal%20-%20Voting%20-%20%3CFEATURE%20NAME%3E&body=Voting%20has%20started%20for%20%3CPROPOSAL%20NAME%3E.%0D%0A%0D%0A%3CLINK%20TO%20PROPOSAL%20ON%20WIKI%3E Send (mailto link)] a notice that voting has started to the Tagging mailing list.<br>''Or copy:''
# [mailto:tagging@openstreetmap.org?subject=Feature%20Proposal%20-%20Voting%20-%20%3CFEATURE%20NAME%3E&body=Voting%20has%20started%20for%20%3CPROPOSAL%20NAME%3E.%0D%0A%0D%0A%3CLINK%20TO%20PROPOSAL%20ON%20WIKI%3E Send (mailto link)] a notice that voting has started to the Tagging mailing list.<br>''Or copy:''
## To: <code>tagging{{@}}openstreetmap.org</code>
## To: <code>tagging{{@}}openstreetmap.org</code>
Line 226: Line 252:
# Consider posting a notice for voting on some of the other [[contact channels]] as well.
# Consider posting a notice for voting on some of the other [[contact channels]] as well.


=== Requirements during ===
=== Requirements during === <!--T:126-->
Make sure these requirements are met during voting.
Make sure these requirements are met during voting.
* The proposal is never changed.
* The proposal is never changed.
Line 234: Line 260:
* A list of active votes can be found at [[:Category:Proposals with "Voting" status]].
* A list of active votes can be found at [[:Category:Proposals with "Voting" status]].


== Post-vote ==
== Post-vote == <!--T:127-->
* If you have no time to do the cleanup after the voting has ended:
* If you have no time to do the cleanup after the voting has ended:
: Mark the proposal status as <code>status=Post-Vote</code>.  
: Mark the proposal status as <code>status=Post-Vote</code>.  


<!--T:128-->
: (See [[:Category:Proposals without post-vote cleanup]] for features needing clean-up. If you have a minute, pick up a broom and clean up!)
: (See [[:Category:Proposals without post-vote cleanup]] for features needing clean-up. If you have a minute, pick up a broom and clean up!)


<!--T:129-->
* After the voting period, make a summary of the voting by filling out the parameters of the {{T|Proposed feature voting}} template:
* After the voting period, make a summary of the voting by filling out the parameters of the {{T|Proposed feature voting}} template:
<syntaxhighlight lang="moin">
<syntaxhighlight lang="moin">
Line 252: Line 280:
</syntaxhighlight>
</syntaxhighlight>


<!--T:130-->
* It is a good idea to [mailto:tagging@openstreetmap.org send] out an update to the tagging mailing list:  
* It is a good idea to [mailto:tagging@openstreetmap.org send] out an update to the tagging mailing list:  
** <Subject:> "Feature Proposal - Approved - (Feature Name)"
** <Subject:> "Feature Proposal - Approved - (Feature Name)"
** <Subject:> "Feature Proposal - Rejected - (Feature Name)"
** <Subject:> "Feature Proposal - Rejected - (Feature Name)"


===Approved===
===Approved=== <!--T:131-->
If the proposal has found enough support, the status can be set to <code>Approved</code> (both in result parameter in {{T|Proposed feature voting}} and in status parameter of {{T|Proposal Page}} at top of the page).
If the proposal has found enough support, the status can be set to <code>Approved</code> (both in result parameter in {{T|Proposed feature voting}} and in status parameter of {{T|Proposal Page}} at top of the page).


<!--T:132-->
:Old version applying to proposal votes started before 2021-03-10: A rule of thumb for "enough support" is ''at least 8 approval votes and at least 75 % approval'', (a simple way of counting is that a minimum of 3 yes votes for every no vote is sufficient), but other factors may also be considered (such as whether a feature is already in use).
:Old version applying to proposal votes started before 2021-03-10: A rule of thumb for "enough support" is ''at least 8 approval votes and at least 75 % approval'', (a simple way of counting is that a minimum of 3 yes votes for every no vote is sufficient), but other factors may also be considered (such as whether a feature is already in use).


<!--T:133-->
:[[Proposed features/change vote counting rules - remove dead rule|New version applying to proposal votes started on 2021-03-10 or later]]: "Enough support" is at least 8 approval votes and at least 75 % approval. A simple way of counting is that a minimum of 3 yes votes for every no vote is sufficient.
:[[Proposed features/change vote counting rules - remove dead rule|New version applying to proposal votes started on 2021-03-10 or later]]: "Enough support" is at least 8 approval votes and at least 75 % approval. A simple way of counting is that a minimum of 3 yes votes for every no vote is sufficient.


<!--T:134-->
: The explicit abstentions do not count as a vote (e.g. 10 vote "yes", 1 vote "no", 10 "abstain but have comments" would be approved), but all suggestions should be taken into account before a proposal is approved or rejected in order to resolve any deficiencies in the original proposal (if they exist).
: The explicit abstentions do not count as a vote (e.g. 10 vote "yes", 1 vote "no", 10 "abstain but have comments" would be approved), but all suggestions should be taken into account before a proposal is approved or rejected in order to resolve any deficiencies in the original proposal (if they exist).


<!--T:135-->
: Before you decide to reject a proposal because of lack of support, it may be worthwhile to [mailto:tagging@openstreetmap.org send] out a new vote request to the mailing list.
: Before you decide to reject a proposal because of lack of support, it may be worthwhile to [mailto:tagging@openstreetmap.org send] out a new vote request to the mailing list.


<!--T:136-->
See [[/historic notes]] for list of substantial changes in the past. Older proposals are still considered "approved" if they met the standard in place at the time.
See [[/historic notes]] for list of substantial changes in the past. Older proposals are still considered "approved" if they met the standard in place at the time.


<!--T:137-->
Clean up the proposal:
Clean up the proposal:
* Do not move the proposal page!
* Do not move the proposal page!
Line 281: Line 316:
** Do '''not''' remove entries from [[Map Features]] even if your new feature that has been voted on is intended to replace them. It is not considered good style to remove things from Map Features while they are still in use. You can remove things from Map Features if they are not in a significant use. See also [[Deprecated features]].
** Do '''not''' remove entries from [[Map Features]] even if your new feature that has been voted on is intended to replace them. It is not considered good style to remove things from Map Features while they are still in use. You can remove things from Map Features if they are not in a significant use. See also [[Deprecated features]].


===Rejected===
===Rejected=== <!--T:138-->
If the vote fails, do not despair. Many proposals were rejected, modified and succeeded. Sometimes proposal fail because some people noticed issues during vote.  
If the vote fails, do not despair. Many proposals were rejected, modified and succeeded. Sometimes proposal fail because some people noticed issues during vote.  


<!--T:139-->
* The status should be set to <code>Rejected</code>.
* The status should be set to <code>Rejected</code>.
* Note any reasons why rejected on the feature proposal page.
* Note any reasons why rejected on the feature proposal page.
* Rejected features may be resubmitted, modified, and new vote started. You can also move back to the RFC process, or at least send some message to give chance of feedback without voting against.
* Rejected features may be resubmitted, modified, and new vote started. You can also move back to the RFC process, or at least send some message to give chance of feedback without voting against.


== Abandoned, Canceled, Obsoleted, Undefined ==
== Abandoned, Canceled, Obsoleted, Undefined == <!--T:140-->
* Proposals should be set to <code>Abandoned</code> if they have a long time of inactivity (at least 3 months) on the wiki pages (including all languages and discussion pages) and are also not added to the OSM database. A proposal that's unchanged in the wiki for a while might just be tested in daily mapping practice and thus may be very alive.  
* Proposals should be set to <code>Abandoned</code> if they have a long time of inactivity (at least 3 months) on the wiki pages (including all languages and discussion pages) and are also not added to the OSM database. A proposal that's unchanged in the wiki for a while might just be tested in daily mapping practice and thus may be very alive.  
* The person proposing a feature can cancel it by setting the status to <code>Canceled</code>.
* The person proposing a feature can cancel it by setting the status to <code>Canceled</code>.
Line 295: Line 331:
* For proposals with unknown status, set the status to <code>Undefined</code>.
* For proposals with unknown status, set the status to <code>Undefined</code>.


<!--T:141-->
{{anchor|archiving proposals}}<!-- used in WikiProject Cleanup#Historical content -->
{{anchor|archiving proposals}}<!-- used in WikiProject Cleanup#Historical content -->
Note that abandoned/inactive proposal may be for tag that is in active use. In such case [[creating a tag page]], applying {{T|Archived proposal}} on the proposal page and hiding proposal text may be the best solution. It keeps history available but users are directed to the active documentation.
Note that abandoned/inactive proposal may be for tag that is in active use. In such case [[creating a tag page]], applying {{T|Archived proposal}} on the proposal page and hiding proposal text may be the best solution. It keeps history available but users are directed to the active documentation.


<!--T:142-->
See [[Proposed features/street vendor=yes]] and [[Proposed features/scaled down streets that may be used for traffic safety education or as a type of a playground|traffic park one]] for examples where it was used.
See [[Proposed features/street vendor=yes]] and [[Proposed features/scaled down streets that may be used for traffic safety education or as a type of a playground|traffic park one]] for examples where it was used.


==Non proposed features==
==Non proposed features== <!--T:143-->
Non-proposed features are mapping features which did not undergo the proposal process.  
Non-proposed features are mapping features which did not undergo the proposal process.  


<!--T:144-->
Even if OSM has a completely [[Any tags you like|free data model]] (that is, you don't need anyone's permission), we try to moderate the [[Map features]] list for several reasons:
Even if OSM has a completely [[Any tags you like|free data model]] (that is, you don't need anyone's permission), we try to moderate the [[Map features]] list for several reasons:
* landing page for newbies: so it has to be clear and self-explanatory in every language
* landing page for newbies: so it has to be clear and self-explanatory in every language
Line 308: Line 347:
* keep list/categories short: even a design decision, we want to avoid an uncontrolled explosion of features and keys
* keep list/categories short: even a design decision, we want to avoid an uncontrolled explosion of features and keys


<!--T:145-->
Generally, new [[keys]] should always be discussed before being added to [[Map features]]. To increase participation in discussion, especially for new values of major keys like {{key|highway}} it is a good idea to formally propose them. Any new tag which replaces an established tag also requires a proper discussion, proposal process is a good way to achieve this.
Generally, new [[keys]] should always be discussed before being added to [[Map features]]. To increase participation in discussion, especially for new values of major keys like {{key|highway}} it is a good idea to formally propose them. Any new tag which replaces an established tag also requires a proper discussion, proposal process is a good way to achieve this.


== Reviving old proposals ==
== Reviving old proposals == <!--T:146-->
There are many old proposals that never reached vote stage and where the original authors have abandoned them. What can be done by a new unrelated person interested in making identical or a similar proposal?
There are many old proposals that never reached vote stage and where the original authors have abandoned them. What can be done by a new unrelated person interested in making identical or a similar proposal?


<!--T:147-->
* restart the old proposal - it is a good idea if you completely agree with it. Consider contacting the original author whenever it is OK for you to resurrect it - and wait some time for reply. Send it again to request for comment (RFC) stage and continue to proceed like with any other proposal.  
* restart the old proposal - it is a good idea if you completely agree with it. Consider contacting the original author whenever it is OK for you to resurrect it - and wait some time for reply. Send it again to request for comment (RFC) stage and continue to proceed like with any other proposal.  
* make a new proposal reusing content from the old one. Simply create a new page, feel free to copy existing content (you are allowed to do this, just mention source of text in the changeset comment). Mention inspiration/source of the proposal, but feel free to make any changes to it that you want. And proceed like with any new proposal. You can also do this with your own proposals.
* make a new proposal reusing content from the old one. Simply create a new page, feel free to copy existing content (you are allowed to do this, just mention source of text in the changeset comment). Mention inspiration/source of the proposal, but feel free to make any changes to it that you want. And proceed like with any new proposal. You can also do this with your own proposals.


=== Examples ===
=== Examples === <!--T:148-->


<!--T:149-->
* [[Proposed features/man made=bridge]] is case of a simple reviving - person who started vote fully agreed with the original author, proposal was not modified
* [[Proposed features/man made=bridge]] is case of a simple reviving - person who started vote fully agreed with the original author, proposal was not modified
* [[Proposed features/scuba diving2]] was based on a previously proposed but not finalised [[Proposed features/scuba diving]], proposals were made by different people
* [[Proposed features/scuba diving2]] was based on a previously proposed but not finalised [[Proposed features/scuba diving]], proposals were made by different people
* [https://wiki.openstreetmap.org/w/index.php?oldid=1206637 healthcare=blood_donation proposal] was based on the earlier proposal made by the same person that was rejected
* [https://wiki.openstreetmap.org/w/index.php?oldid=1206637 healthcare=blood_donation proposal] was based on the earlier proposal made by the same person that was rejected


== Proposal process wiki history ==
== Proposal process wiki history == <!--T:150-->
You can find the history for this page [{{fullurl:{{FULLPAGENAME}}|action=history}} there] (as usual).
You can find the history for this page [{{fullurl:{{FULLPAGENAME}}|action=history}} there] (as usual).


== Proposal status overview list ==
== Proposal status overview list == <!--T:151-->
* <code><span style="background:#EEE">[[:Category:Proposals with "Draft" status|draft]]</span></code>: the proposal is in the initial starting period of writing down corresponding information
* <code><span style="background:#EEE">[[:Category:Proposals with "Draft" status|draft]]</span></code>: the proposal is in the initial starting period of writing down corresponding information
* <code><span style="background:#EEE">[[:Category:Proposals with "Proposed" status|proposed]]</span></code>: the proposal contents is fully described and it is proposed to the community
* <code><span style="background:#EEE">[[:Category:Proposals with "Proposed" status|proposed]]</span></code>: the proposal contents is fully described and it is proposed to the community
Line 338: Line 380:
* <code><span style="background:#EEE">[[:Category:Proposals with undefined or invalid status|undefined]]</span></code>: the proposal has unknown status
* <code><span style="background:#EEE">[[:Category:Proposals with undefined or invalid status|undefined]]</span></code>: the proposal has unknown status


<!--T:152-->
''See also:'' [[Tag_status#Status_values|Tag status values]]
''See also:'' [[Tag_status#Status_values|Tag status values]]


== Lists of proposals ==
== Lists of proposals == <!--T:153-->
* [[:Category:Proposals by status|Lists of proposals by status]]
* [[:Category:Proposals by status|Lists of proposals by status]]


== See also ==
== See also == <!--T:154-->
* [[User:Joto/How to invent tags]]
* [[User:Joto/How to invent tags]]
* [[Creating a page describing key or value]]
* [[Creating a page describing key or value]]

Revision as of 21:57, 1 May 2022

Template:Languages Template:Otheruses Template:Otheruses

This page describes the proposal process, which is one of multiple ways to introduce and discuss new tags for features and properties. The other ways are often undocumented. 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. The open voting process acts as supporting evidence that the proposal author has adequately reflected feedback from interested parties and meaningfully addressed objections posed. The outcome of a proposal vote is a change in documentation on the wiki.

As a documentation change, an approved proposal is not binding on any mapper, software developer, or data consumer. However, tagging backed by an approved proposal is usually regarded as having survived a level of community vetting and scrutiny, and thus carries more weight when compared to alternative methods of mapping a feature. OpenStreetMap does not restrict mapping to tagging schemes backed by an approved proposal -- you can still use any tags you like. Nonetheless, there is benefit to mappers and data consumers alike in agreeing on a common data model and corresponding tags by reducing conflict between mappers, edit wars, and tagging disputes.

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, such as the standard tile layer renderings or editor presets. An approved proposal will not be automatically rendered or added to presets; this is at the discretion of the developers and maintainers of those tools. Also, a vote result is never permission for large-scale re-tagging of existing objects. See automated Edits code of conduct for more about this topic.

This page is designed to assist anyone considering putting forward a tag proposal, with the aim of speeding the tag proposing process. Like the proposal process itself, it attempts to describe the rough consensus that has accumulated over the years over the best ways to assess and document community consensus on mapping and tagging. It is not a set of absolute rules, but rather a helpful guide for community members.

Proposal list

All proposals are categorised by the status set in its Proposal Page template:

Proposals/cats

Before creating a proposal

Does it already exist?

  1. Search for possible documentation on this Wiki.
    For example:
    • You want a tag for a racecourse; consider searching for "racing", "horse", etc.
    • You want a tag for a peninsula; consider searching for "headland", "point", etc.
    • You want a tag for a brewery; consider searching for "beer", "manufacturing", "alcohol", "industrial", "plant", "works", etc.

      <inputbox>

type=fulltext searchbuttonlabel=Search this Wiki placeholder=Feature name or keywords </inputbox>
If you come across an Abandoned proposal and are interested in reviving it, see Reviving old proposals.
If you come across a previously Rejected proposal, being a rejected feature does not necessarily mean it should not be proposed again. Some proposals fail due to a poor definition, being ambiguous or lacking information to justify their significance, or becoming more significant over time and thus more map-worthy.

  1. Check Mapping issues to see a list of known issues relating to mapping and tagging standards.
  2. Search for the tag on Taginfo to see if there is any usage otherwise.
  3. Ask community members in one of the Contact channels if it exists.
  4. It might also be a good idea to send an email to the tagging mailing list, describe the feature you want to tag and see if there are tags in use but hard to find or not yet documented.

Significance

Is the tag you are considering for proposal, worthy of a new tag? Consider possible uses for the map, and specifically the data you want to add.

This is a difficult judgement to make: if you want to tag it, then that is generally reason enough to create a tag.

  • Is it a destination in itself?
    • People may search for some locations, for example: a national park, a bus station, a street address or a rubbish dump, because they want to visit that location.
  • How many of the item do you think there will be in the world?
    • For instance, you want to map an aero-engine factory - there are very few aero-engine factories in the world, so rather than creating a specific tag, this may be better served by using an existing man_made tag and specifying product=aero_engines.
  • How large is the item?
    • Large items can assist with navigation.
  • Is it useful for research/study?
    • A geography student may want to determine the total area of national parks in a given region.
    • A sociology student may want to map correlation between number/location of Porsche dealerships and houses greater than 600 m2 in area.
    • A history student may want to show the locations of all battles in a given war.
  • Does it assist in route-planning?
    • It is useful to know which junctions are traffic lights and which are roundabouts as this can affect journey times.
    • Truck drivers need to know the maximum height allowed under bridges, or the maximum weight allowed through population centres.
    • Traffic calming structures can affect journey times, routing software will generally not use roads with these on.
    • Walkers would want to know surfaces/conditions of walking tracks.

Compatibility with established practices

OpenStreetMap has some established good practices. Your proposal should follow those or at least explain why it does not do it. Please have a look at them.

Specifically relevant for proposals might be

Verifiability
Tags that are approved are usually features or properties that an individual mapper can confirm to be correct or false. A tag is verifiable if independent users would make the same observation.
This means that statistical properties (like peak vehicles per hour on a road) and subjective content (reviews, rankings) are not included in OpenStreetMap. Temporary, historic or speculative future developments are also excluded.
One feature, one OSM element
A single real world object should be represented with one element only.
Syntactic conventions for new tags
There are some conventions about naming keys and values. Following them will help mappers to estimate the meaning of your tags without reading the documentation. Using a semicolon should be considered especially carefully.

Skimming though Editing Standards and Conventions might be helpful as well. Please also consider the On the Ground Principle (about current versus old data), Template:Key (for estimations), and names (names versus descriptions, avoiding abbreviations) if any of them might conflict with your ideas.

Due Diligence

Your proposal is more likely to be accepted by the community if you take steps to research and vet your proposal before presenting it in front of a global audience. Some tips for success include:

  • Research whether tagging for this feature (or similar) has been discussed before, by searching the mailing lists or other forums. Consider what objections or concerns were raised in those discussions, and adjust your proposal if necessary to satisfy the concerns. It may not be possible to please everyone, but you will have the best chance of success if you make the effort to address as many concerns as possible. Provide links to these discussions in the "External Discussions" section; it shows that you have done your homework and are aware of past discussions that may have occurred.
  • Consider asking a trusted colleague or two in the community to review your proposal. Private dialogue before the Request For Comments (RFC) is extremely helpful in identifying and fixing problems. If the tagging for this feature was discussed on the mailing list in the past, consider a sending private email asking for feedback from one or more of the participants in that discussion. They may have expertise in that area, and the private dialogue will not only make your proposal stronger, but will help you build rapport with the active members of the tagging community.
  • If you are not a native speaker of British English, be sure to research what the thing you are describing is called in the British vernacular. It can be helpful to find UK-based web sites that discuss the topic in order to understand how it is phrased and used.
  • Research similar tagging schemes in order to ensure that your proposed tagging is consistent with other similar features and usages, and include those comparisons in the "rationale" section of the proposal.
  • Assume that the reader is not an expert in the topic or in the associated tagging. Give a brief introduction suitable for non-experts that allows them to understand the feature being described, the state of existing (inadequate) tagging, and how your proposal fills that gap. Do not assume prior knowledge, especially when proposing additions or changes to complex tagging schemes.

Creating a proposal

You can easily create a pre-formatted proposal here.

Read these instructions before creating the page.

  1. Create the page using the tool below. The tool does not immediately create the page, but opens the editor for the page that will be created if saved.
  2. Making no edits, immediately save to convert the substituted values to text.
    File:Save proposal first.png
  3. Click on Edit in the upper-right heading.
  4. Click on the Proposal Page template at the top of the page and click edit. Then input the specific details of the proposal for each of the parameters.
    File:Edit proposal page template next.png
  5. Follow the instructions in the comments under each of the headings to draft the proposal documentation.

Create here:

<inputbox> type=create break=no width=26 placeholder=Proposal name preload=Template:Proposal prefix=Proposed_features/ useve=true </inputbox>

Template:Clear

If you edit using the Wikicode editor instead of the Visual Editor, what is displayed will be a bit different. Instructions still apply: (1) create page (2) save to generate text, (3) edit page to fill the template and save again.

If you have technical trouble with creating a proposal page, feel free to ask for help by sending a message to the tagging mailing list, you can ask for technical help also elsewhere.

Optionally let people know of your new proposal by subscribing to tagging mailing list and sending a mail.

Proposal page template

You may also create a proposal directly by copying and pasting into a new page

Create a new wiki page such as Proposed_features/your_proposition_name (MediaWiki Help:Starting a new page) and then fill in the proposal page template and page details described below. Set the status to Draft and set the draftStartDate={{#time: Y-m-d}} value (YYYY-MM-DD):

Place the following wiki text at the top of the page, and fill in the brief summary content fields: (See also: Template:T) <syntaxhighlight lang="moin"> Template:Proposal Page

Proposal

Rationale

Tagging

Examples

Rendering

Features/Pages affected

External discussions

Comments

Please comment on the discussion page. </syntaxhighlight>

Propose

Once the proposal contents are fully described, you can propose it to the community.

Propose

  1. Set these parameters in the Proposal page template at the top of the page:
    1. status = Proposed
    2. rfcStartDate = {{#time: Y-m-d}}
  2. Subscribe to the Tagging mailing list.
  3. Send (mailto link) an RFC (Request For Comments) to the Tagging mailing list.
    Or copy:
    1. To: taggingTemplate:@openstreetmap.org
    2. Subject: Feature Proposal - RFC - <PROPOSAL NAME>
    3. Body: <DESCRIPTION OF PROPOSAL> <LINK TO PROPOSAL ON WIKI> Please discuss this proposal on its Wiki Talk page.
  4. Consider sending your proposal to some additional contact channels to further increase community feedback and knowledge of it (not everyone subscribes to the tagging mailing list).

Respond

Look through comments that arise from the mailing lists, chats, and the proposal Wiki Talk page.

When a discussion in a section created by another user on the proposal's Talk page is considered "resolved", you can add the {{Resolved|1=message}} Template directly below the section heading with an included message.

Adjust, even if it means changing key parts or tags, and continue to build a strong proposal according to community feedback so that it has a good chance of passage once voted on.

Note that it is not necessary to implement all suggestion and requests. While many will be useful, it is possible to receive recommendations contradictory with each other, some can be also misguided.

If there are many changes to the proposal, it may be a good idea to document them in a timeline in a separate section called Changes for reference.

Voting

You still have to be subscribed to the Tagging mailing list for these steps.

Requirements before

Make sure these your proposal meets these requirements before initiating voting.

  • At least two weeks have passed since start of a RFC.
  • All discussions have been resolved on the Talk page.
  • All major and minor disagreements about the proposal have been resolved.
    Remember, the community is voting on all parts of your proposal. If someone disagrees with at least one part of your proposal, they will often vote Template:Oppose. Others will then read why that person voted no and they will likely vote no too. This can cause an almost-perfect proposal to flop.
    If this happens even when all parts of your proposal were resolved, do not be discouraged from continuing the proposal. Usually you only have to fix a minor part of your proposal. Once fixed, the proposal is now very-likely to be approved during the second round of voting.
  • The proposal is in its final state. It cannot be changed once voting starts.

Initiate

  1. Set these parameters in the Proposal page template at the top of the page:
    1. |status = Voting
    2. |voteStartDate = {{#time: Y-m-d}}
    3. |voteEndDate = {{#time: Y-m-d|now + 14 days}}
  2. Add this to the bottom of the page:

<syntaxhighlight lang="moin">

Voting

Template:Proposed feature voting

</syntaxhighlight>

Notify

  1. Send (mailto link) a notice that voting has started to the Tagging mailing list.
    Or copy:
    1. To: taggingTemplate:@openstreetmap.org
    2. Subject: Feature Proposal - Voting - <PROPOSAL NAME>
    3. Body: Voting has started for <PROPOSAL NAME>. <LINK TO PROPOSAL ON WIKI>
  2. Consider posting a notice for voting on some of the other contact channels as well.

Requirements during

Make sure these requirements are met during voting.

  • The proposal is never changed.
  • Monitor the validity of all votes. One person voting with multiple accounts is not allowed, asking people outside OpenStreetMap community to vote is not allowed.
  • People should not just vote Template:Oppose, they should give a reason for their proposal, and/or (preferably) suggestions.
  • It is acceptable for author of the proposal to end the vote earlier as a rejected, so that the proposal can be re-worked.
  • A list of active votes can be found at Category:Proposals with "Voting" status.

Post-vote

  • If you have no time to do the cleanup after the voting has ended:
Mark the proposal status as status=Post-Vote.
(See Category:Proposals without post-vote cleanup for features needing clean-up. If you have a minute, pick up a broom and clean up!)
  • After the voting period, make a summary of the voting by filling out the parameters of the Template:T template:

<syntaxhighlight lang="moin"> Template:Proposed feature voting </syntaxhighlight>

  • It is a good idea to send out an update to the tagging mailing list:
    • <Subject:> "Feature Proposal - Approved - (Feature Name)"
    • <Subject:> "Feature Proposal - Rejected - (Feature Name)"

Approved

If the proposal has found enough support, the status can be set to Approved (both in result parameter in Template:T and in status parameter of Template:T at top of the page).

Old version applying to proposal votes started before 2021-03-10: A rule of thumb for "enough support" is at least 8 approval votes and at least 75 % approval, (a simple way of counting is that a minimum of 3 yes votes for every no vote is sufficient), but other factors may also be considered (such as whether a feature is already in use).
New version applying to proposal votes started on 2021-03-10 or later: "Enough support" is at least 8 approval votes and at least 75 % approval. A simple way of counting is that a minimum of 3 yes votes for every no vote is sufficient.
The explicit abstentions do not count as a vote (e.g. 10 vote "yes", 1 vote "no", 10 "abstain but have comments" would be approved), but all suggestions should be taken into account before a proposal is approved or rejected in order to resolve any deficiencies in the original proposal (if they exist).
Before you decide to reject a proposal because of lack of support, it may be worthwhile to send out a new vote request to the mailing list.

See /historic notes for list of substantial changes in the past. Older proposals are still considered "approved" if they met the standard in place at the time.

Clean up the proposal:

  • Do not move the proposal page!
  • Create the permanent feature description page:
    • A new page for the feature should be created/updated and the relevant map features template (depending on whether it is a key, a value, or a relation) should be applied. Follow the standard set by the Key:highway key and its values.
    • Add a link back to the proposal by using the statuslink parameter of the feature template.
    • Add a link to the permanent feature page in the proposal page using Template:Approved feature link.
    • Archive the proposal using Template:Archived proposal.
  • Add the completed feature to the map feature page:
    • Add entry to Map Features page if that is useful (for example approved niche tag may be not listed there).
    • Add entry to Changelog page.
    • Do not remove entries from Map Features even if your new feature that has been voted on is intended to replace them. It is not considered good style to remove things from Map Features while they are still in use. You can remove things from Map Features if they are not in a significant use. See also Deprecated features.

Rejected

If the vote fails, do not despair. Many proposals were rejected, modified and succeeded. Sometimes proposal fail because some people noticed issues during vote.

  • The status should be set to Rejected.
  • Note any reasons why rejected on the feature proposal page.
  • Rejected features may be resubmitted, modified, and new vote started. You can also move back to the RFC process, or at least send some message to give chance of feedback without voting against.

Abandoned, Canceled, Obsoleted, Undefined

  • Proposals should be set to Abandoned if they have a long time of inactivity (at least 3 months) on the wiki pages (including all languages and discussion pages) and are also not added to the OSM database. A proposal that's unchanged in the wiki for a while might just be tested in daily mapping practice and thus may be very alive.
  • The person proposing a feature can cancel it by setting the status to Canceled.
  • For proposals that have been obsoleted by another proposal, set the status to Obsoleted.
  • For proposals which are inactive but not abandoned, set the status to Inactive. For example used for tags (keys) which has reached 'defacto'-status based on this proposal without voting process (consider to also add the template: Template:T)
  • For proposals with unknown status, set the status to Undefined.

Template:Anchor Note that abandoned/inactive proposal may be for tag that is in active use. In such case creating a tag page, applying Template:T on the proposal page and hiding proposal text may be the best solution. It keeps history available but users are directed to the active documentation.

See Proposed features/street vendor=yes and traffic park one for examples where it was used.

Non proposed features

Non-proposed features are mapping features which did not undergo the proposal process.

Even if OSM has a completely free data model (that is, you don't need anyone's permission), we try to moderate the Map features list for several reasons:

  • landing page for newbies: so it has to be clear and self-explanatory in every language
  • avoid feature conflicts: during a vote all eyes can keep duplicates away
  • keep list/categories short: even a design decision, we want to avoid an uncontrolled explosion of features and keys

Generally, new keys should always be discussed before being added to Map features. To increase participation in discussion, especially for new values of major keys like Template:Key it is a good idea to formally propose them. Any new tag which replaces an established tag also requires a proper discussion, proposal process is a good way to achieve this.

Reviving old proposals

There are many old proposals that never reached vote stage and where the original authors have abandoned them. What can be done by a new unrelated person interested in making identical or a similar proposal?

  • restart the old proposal - it is a good idea if you completely agree with it. Consider contacting the original author whenever it is OK for you to resurrect it - and wait some time for reply. Send it again to request for comment (RFC) stage and continue to proceed like with any other proposal.
  • make a new proposal reusing content from the old one. Simply create a new page, feel free to copy existing content (you are allowed to do this, just mention source of text in the changeset comment). Mention inspiration/source of the proposal, but feel free to make any changes to it that you want. And proceed like with any new proposal. You can also do this with your own proposals.

Examples

Proposal process wiki history

You can find the history for this page there (as usual).

Proposal status overview list

  • draft: the proposal is in the initial starting period of writing down corresponding information
  • proposed: the proposal contents is fully described and it is proposed to the community
  • voting: the proposal is currently being voted on as part of the approval process
  • post-vote: the proposal voting is done and the voting cleanup isn't finished
  • approved: the proposal has successfully (found enough support) completed the approval process
  • rejected: the proposal is rejected (found not enough support) during the approval process
  • abandoned: the proposal has a long time of inactivity (at least 3 months) on the wiki pages (including all languages and discussion pages) and is also not added to the OSM database
  • canceled: the proposal is canceled by the person how did create the proposal
  • obsoleted: the proposal is obsoleted by another proposal
  • inactive: the proposal is inactive but not abandoned
  • undefined: the proposal has unknown status

See also: Tag status values

Lists of proposals

See also