FR:Key:comment

La balise comment est utilisé pour décrire une liste de changement, et a été introduit avec l'API 0.6. C'est utilisé par les contributeurs comme un guide pour décrire la raison, ou ce qu'il y a de plus intéressant dans ce changement, le pourquoi du changement. Par exemple, quand un nœud balisé avec highway=bus_stop est déplacé, le commentaire de la liste de changement peut être "déplacement de l'arrêt bus du à des travaux de voiries récents" ou "déplacement de l'arrêt de bus, qui était mal placé". Cela permet d'aider les autres contributeurs à saisir le pourquoi d'un changement particulier.

La balise comment est visible sur le site web, notablement dans l'onglet Historique et d'autres vues impliquant une liste de changement. Ce n'est pas obligatoire de commenter une liste de changement. Elle est un message destiné à vos collègues contributeurs, disant ce que vous avez fait et pourquoi. Par conséquent ce message est une preuve de considération pour les autres contributeurs.

Ne pas prendre le temps d'ajouter un tel message, ou ajoutant des commentaires vides de sens, est considéré par certains comme grossier, voire irrespectueux par certains. D'un autre côté, beaucoup de commentaires des listes de changement ne seront jamais lues et certains considèrent que c'est une perte de temps que le passer à rédiger ce qui ne sera pas lu et que ce temps serait mieux employé à ajouter des données à OSM. Lisez la traduction de la page Good changeset comments pour en savoir plus sur les bonnes pratiques.

La distinction entre note et comment est qu'une note est généralement utilisé sur des nœuds/chemins/relations pour décrire un objet du terrain comme "l'arrêt de bus est bien ici mais le panneau est tombé en septembre 2009", alors que les commentaires sont utilisés avec les listes de changement.

Voir aussi

• note=* - pour ajouter des notes destinées à vous même ou aux autres contributeurs.
• description=* - pour ajouter un texte pouvant être lu par l'utilisateur final.

Orientation pour les développeurs d'éditeur d'OSM

En particulier quand il s'agit de liste de changement:

• les balises comment ne devraient pas être automatiquement générées. Si un projet consommateur de données souhaite générée des données automatiques, il peux le faire pour lui même.
• La balise comment n'est pas une obligation - par exemple un éditeur en direct n'ajoute pas des comment à chaque fois (cf. le mode direct de FR:potlatch). Toutefois, ces commentaires significatifs de changement sont très utiles, et c'est une bonne idée que votre logiciel fournisse un moyen de les ajouter facilement. Mais si votre logiciel les rendent obligatoires, il y a un risque que certains utilisateurs y réagissent de manière négative et y rédigent des commentaires inutiles.
• La balise comment doit être disponible dans l'éditeur si l'utilisateur souhaite l'utiliser.