Procedimiento de propuesta

Esta página describe el procedimiento de propuesta, que es una de las múltiples vías para introducir y debatir la creación de etiquetas para características. Las otras vías a menudo no suelen estar documentadas.

El procedimiento de propuesta fue diseñado para permitir a la comunidad de OSM discutir y votar una forma estándar de etiquetar características del mapa. OpenStreetMap no tiene ninguna restricción respecto al uso de etiquetas que pueden añadirse a los nodos, vías o áreas. Puedes usar cualquier etiqueta que desees. Sin embargo, resulta beneficioso llegar a un acuerdo sobre el conjunto de características y sus correspondientes etiquetas en orden a crear, interpretar y mostrar un mapa base común. También es común descubrir varias cuestiones durante el debate - puede que ya exista una forma de mapear una característica determinada o puede ser conveniente dar un formato diferente a la etiqueta propuesta para hacerla más clara.

Por favor, ten en cuenta: El resultado de la votación de una propuesta (incluyendo la aprobación o desaprobación de etiquetas) no tiene ninguna implicación para aquellas herramientas que usan y generan datos de OSM, tales como las representaciones de la capa estándar del mapa o los predefinidos del editor. No esperes que una propuesta aprobada se represente o agregue automáticamente a los predefinidos; esto queda a discreción de los mantenedores de hojas de estilo y autores de código. Además, nunca utilices el resultado de una votación como justificación para el reetiquetado a gran escala de objetos existentes. Véase el código de conducta de ediciones automatizadas para más detalles sobre este tema.

Esta página está diseñada para ayudar a cualquiera que esté considerando proponer una propuesta de etiqueta, con el objeto de acelerar el procedimiento de propuesta de etiquetas. No debe entenderse como un conjunto de reglas absolutas, sino como una guía.

Lista de propuestas

Todas las propuestas son categorizadas por el estado establecido en su plantilla de página de propuesta: ES:Proposals/cats

Antes de crear una propuesta

¿Ya existe?

1. Busca posible documentación previa en este wiki.
   Por ejemplo:
   • Si quieres una etiqueta para un hipódromo, considera buscar por «carreras», «caballos», etc.
   • Si quieres una etiqueta para una península, considera buscar por «cabo», «punta», etc.
   • Si quieres una etiqueta para una cervecería, considera buscar por «cerveza», «fabricación», «alcohol», «industrial», «planta», «fábrica», etc.
     
     <inputbox>

type=fulltext searchbuttonlabel=Buscar en este wiki placeholder=Nombre de característica o palabras claves </inputbox>
Si te encuentras con una propuesta abandonada y estás interesado en resucitarla, consulta Resucitar propuestas antiguas.
Si te encuentras con una propuesta rechazada previamente, recuerda que el que una característica haya sido rechazada no significa necesariamente que no pueda volver a proponerse. Algunas propuestas fracasan debido a una mala definición, por ser ambiguas o por carecer de información que justifique su importancia, o pueden volverse más significativas con el tiempo y, por tanto, más valiosas para un mapa.

1. Consulta los [[Template:LL|problemas de mapeo]] para ver una lista de problemas conocidos relacionados con el mapeo y etiquetado estándares.
2. Buscar una etiqueta en Taginfo para ver si hay algún otro uso.
3. Pregunta a los miembros de la comunidad por uno de los canales de contacto si existe.
4. También puede ser una buena idea enviar un correo electrónico a la lista de correo de etiquetado, describir la característica que quieres etiquetar y ver si hay etiquetas en uso pero difíciles de encontrar o aún no documentadas.

Significancia

¿La etiqueta que estás pensando proponer es digna de ser una nueva etiqueta? Considera los posibles usos para el mapa, y, específicamente, los datos que deseas agregar.

Esto resulta difícil de valorar: si deseas etiquetarlo, entonces normalmente es motivo suficiente para crear una etiqueta.

• ¿Es un destino en sí mismo?
  • La gente puede querer buscar algunos lugares, por ejemplo: un parque nacional, una estación de autobuses, una dirección de una calle o un vertedero, porque quieren visitar ese lugar.
• ¿Cuántos elementos como ese crees que habrá en el mundo?
  • Por ejemplo, si deseas mapear una fábrica de aerogeneradores - hay muy pocas fábricas de aerogeneradores en el mundo, por lo que en lugar de crear una etiqueta específica, sería más útil emplear una etiqueta «man_made» y especificar «product=aero_engines».
• ¿Qué tamaño tiene el elemento?
  • Los elementos grandes pueden ayudar con la navegación.
• ¿Es útil para la investigación o el estudio?
  • Un estudiante de Geografía puede querer determinar el área total de los parques nacionales en una determinada región.
  • Un estudiante de Sociología puede querer mapear correlaciones entre número y ubicaciones de concesionarios de Porsche y casas de más de 600 m² de superficie.
  • Un estudiante de Historia puede querer mostrar la ubicación de todas las batallas de una determinada guerra.
• ¿Ayuda en la planificación de rutas?
  • Es útil saber qué cruces tienen semáforos y cuáles son rotondas, ya que puede afectar a los tiempos de viaje.
  • Los camioneros necesitan conocer la altura máxima permitida bajo los puentes, o el peso máximo permitido a través de los centros de población.
  • Las estructuras de calmado de tráfico pueden afectar a los tiempos de viaje: los softwares de enrutamiento por lo general no utilizan rutas que tengan estas estructuras.
  • Los caminantes pueden querer conocer los tipos de superficie y las condiciones de los caminos.

Compatibilidad con prácticas establecidas

OpenStreetMap tiene algunas buenas prácticas establecidas. Tu propuesta debe seguir esas indicaciones o al menos explicar por qué no lo hace. Por favor, échales un vistazo. Especialmente relevante para crear propuestas podrían ser:

Verificabilidad

Las etiquetas aprobadas son generalmente características o propiedades que un mapeador individual puede confirmar que son correctas o falsas. Una etiqueta es verificable si usuarios independientes hicieran la misma observación.

Esto significa que las propiedades estadísticas (como el número máximo de vehículos por hora en una carretera) y el contenido subjetivo (revisiones, clasificaciones) no se incluyen en OpenStreetMap. También se excluyen los desarrollos futuros temporales, históricos o especulativos.

Una característica, un elemento de OSM

Un solo objeto del mundo real debe ser representado con un único elemento.

Convenciones sintácticas para nuevas etiquetas

Existen algunas convenciones sobre nombrado de claves y valores. Seguirlas ayudará a los mapeadores a estimar el significado de tus etiquetas sin leer la documentación. El uso de un punto y coma debería considerarse cuidadosamente.

Echar un vistazo a las Convenciones y estándares de edición también puede ser útil. Por favor, ten en cuenta también el principio sobre el terreno (sobre los datos actuales frente a los antiguos), Template:Key (para estimaciones) y nombres (nombres frente a descripciones, evitar abreviaturas), para evitar que alguno de ellos pueda entrar en conflicto con tus ideas.

Diligencia debida

Es más probable que tu propuesta sea aceptada por la comunidad si tomas medidas para investigar y examinar tu propuesta antes de presentarla ante una audiencia global. Algunos consejos para tener éxito son:

• Investiga si el etiquetado de esta característica (o similar) ha sido discutido antes, buscando en las listas de correo u otros foros. Considera qué objeciones o preocupaciones se plantearon en esas discusiones, y ajusta tu propuesta si es necesario para satisfacer las preocupaciones. Puede que no sea posible complacer a todo el mundo, pero tendrás las mayores posibilidades de éxito si te esfuerzas por responder a tantas preocupaciones como sea posible. Proporciona enlaces a estas discusiones en la sección «External discussions»; esto demuestra que has hecho tus deberes y que estás al tanto de las discusiones anteriores que puedan haber tenido lugar.
• Considera pedir a uno o dos colegas de confianza de la comunidad que revisen tu propuesta. El diálogo privado antes de la petición de comentarios o RFC (Request for Comments, en inglés) es extremadamente útil para identificar y solucionar problemas. Si el etiquetado de esta característica se discutió en la lista de correo en el pasado, considera la posibilidad de enviar un correo electrónico privado solicitando la opinión de uno o más de los participantes en esa discusión. Es posible que tengan experiencia en esa área, y el diálogo privado no solo hará que tu propuesta sea más sólida, sino que te ayudará a establecer una relación con los miembros activos de la comunidad de etiquetado.
• Si no eres nativo del inglés británico, asegúrate de investigar cómo se denomina en la lengua vernácula británica lo que estás describiendo. Puede ser útil encontrar sitios web basados en el Reino Unido que discutan el tema para entender cómo se formula y utiliza.
• Investiga esquemas de etiquetado similares para asegurarte de que tu propuesta de etiquetado es coherente con otras características y usos similares, e incluye esas comparaciones en la sección «Rationale» de la propuesta.
• Asume que el lector no es un experto en el tema o en el etiquetado asociado. Presenta una breve introducción adecuada para los no expertos que les permita entender la característica que se describe, el estado del etiquetado existente (inadecuado) y cómo tu propuesta llena ese vacío. No des por sentado que tienen conocimientos previos, especialmente cuando propongas adiciones o cambios en esquemas de etiquetado complejos.

Creación de la propuesta

Puedes crear fácilmente una propuesta preformateada aquí.

Lee estas instrucciones antes de crear la página.

1. Crea la página usando la herramienta de abajo. La herramienta no crea inmediatamente la página, sino que abre el editor de la página que se creará si se guarda.
2. Sin hacer ediciones, guarda inmediatamente para convertir los valores sustituidos en texto.
   File:Save proposal first es.png
3. Haz clic en Editar en el encabezado superior derecho.
4. Haz clic en la plantilla de página de propuesta en la parte superior de la página y clic en Editar. A continuación, introduce los detalles específicos de la propuesta para cada uno de los parámetros.
   File:Edit proposal page template next es.png
5. Sigue las instrucciones de los comentarios bajo cada uno de los encabezados para redactar la documentación de la propuesta.

Crear aquí:

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

Si editas usando el editor de wikicódigo en lugar del editor visual, lo que se mostrará será un poco diferente. Las instrucciones siguen siendo válidas: (1) crear la página (2) guardar para generar el texto, (3) editar la página para llenar la plantilla y guardar de nuevo.

Si tienes problemas técnicos para crear una página de propuestas, no dudes en pedir ayuda enviando un mensaje a la lista de correo de etiquetado o pedir ayuda técnica en cualquier otro lugar.

Opcionalmente, da a conocer a la gente tu nueva propuesta a través de la lista de correo sobre etiquetado y enviando un correo.

Plantilla de página de propuesta

También puedes crear una propuesta directamente copiando y pegando en una nueva página.

Crea una nueva página wiki tal como Proposed_features/tu_nombre_de_proposición (Ayuda de MediaWiki:Comenzar una nueva página) y luego rellena la plantilla de página de propuesta y los detalles de la página que se describen a continuación. Establece el estado en Draft e introduce el valor (AÑO-MES-DÍA) en draftStartDate={{#time: Y-m-d}}.

Coloca el siguiente texto wiki en la parte superior de la página y rellena los campos de contenido de resumen breve (véase también Template:T): <syntaxhighlight lang="moin"> Template:Proposal Page

External discussions

<! --Enlaces a la lista de correo u otros foros donde la propuesta haya sido discutida -->

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

</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

• 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
• healthcare=blood_donation proposal was based on the earlier proposal made by the same person that was rejected

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

• Lists of proposals by status

See also

• User:Joto/How to invent tags
• Creating a page describing key or value