[OSM-talk-fr] [Proposition] Améliorer le processus de dépréciation des tags

[Christian Quest]

Le 09/12/2021 à 09:18, Florian LAINEZ a écrit :
> Hello,
> Aujourd'hui, lorsque l'on souhaite changer un tag, un vote a lieu. Le processus
> à suivre <https://wiki.openstreetmap.org/wiki/Proposal_process> est assez
> long et compliqué mais le résultat aboutit à un consensus de la communauté
> : l'ancien tag sera déprécié (c'est à dire abandonné), le nouveau sera
> utilisé à la place.
> Néanmoins les changements ne sont pas toujours effectifs et la lisibilité
> de ces changements reste à désirer. Pour les utilisateurs des données et
> les personnes qui développent des éditeurs, ça peut parfois être l'enfer.
>
> Suite à une discussion sur Telegram hier, François, Donat et moi sommes
> arrivés à la conclusion qu'il est donc nécessaire de faire une proposition
> d'évolution concernant la manière dont les tags sont dépréciés.
> *Notre draft de proposition est ici :
> https://wiki.openstreetmap.org/wiki/Proposed_features/Deprecated_and_unsupported_status
> <https://wiki.openstreetmap.org/wiki/Proposed_features/Deprecated_and_unsupported_status>*
>
> En résumé, on vise à
> 0. ne rien changer au processus de décision des propositions en lui-même
> 1. donner plus de visibilité au processus post-vote avec une nouvelle
> période transitoire de 2 ans durant lesquelles le nouveau et l'ancien tags
> restent tous les deux utilisés
> 2. tuer de manière plus déterminée les anciens tags : après 2 ans, seul le
> nouveau tag est utilisé et il est recommandé de supprimer l'ancien tag, en
> autorisant le tir à vue
>
> On peut maintenant imaginer plusieurs degrés de radicalité dans notre
> proposition, et c'est ce dont j'aimerai discuter avec vous.
> En effet on va introduire d'importants changements, notamment :
> - Faire cohabiter l'ancien et le nouveau tag durant 2 ans porte atteinte au
> principe de "Un item, un objet OSM
> <https://wiki.openstreetmap.org/wiki/FR:Un_item,_un_objet_OSM>"
> L'idée étant que les utilisateurs de la donnée puissent continuer à
> utiliser l'ancien tag sans problème durant 2 ans.

En règle générale, le même objet OSM peut porter les 2 tags, ancien et 
nouveau et cette règle me semble respectée.


> - Autoriser voir encourager les éditions manuelles / (semi-)automatisées
> après la période transitoire de 2 ans porte atteinte au principe de "any
> tags you like <https://wiki.openstreetmap.org/wiki/Any_tags_you_like>" qui
> est sûrement improprement traduit "créer un attribut qui manque
> <https://wiki.openstreetmap.org/wiki/FR:Cr%C3%A9er_un_attribut_qui_manque>".
> Cela va aussi sûrement faire hurler ceux qui souhaitent garder un contrôle
> strict des éditions automatisées, aujourd'hui cadrées de très près par un
> code de conduite très contraignant
> <https://wiki.openstreetmap.org/wiki/FR:Code_de_conduite_des_modifications_automatis%C3%A9es>
> .
>
> Malgré cela, je reste convaincu que nous devons faire une proposition de
> réforme qui peut être perçue comme majeure dans le monde d'OSM.
>
> Nos prochaines étapes :
> - évaluer la (non-)efficacité de l'abandon d'anciens tags par le passé
> (François va faire une première analyse ce week-end)
> - réfléchir à la transition des tags déjà dépréciés (Donat tu veux
> commencer à te pencher sur le sujet ?)
> - affiner la proposition, notamment à la vue des exceptions aux règles
> proposées ci-dessus
>
> Étant donné que c'est un changement assez conséquent, j'aimerai que l'on en
> discute dans la communauté FR avant d'internationaliser le débat.
> Merci par avance pour vos idées et retours d'expérience sur le sujet.
>
Le changement est-il aussi conséquent que ça ?

C'est juste aller au bout du cycle de dépréciation et de remplacement.

Comme calendrier, je verrai bien:

- à partir du vote de changement/dépréciation: l'ancien tag est 
considéré comme une anomalie, et donc ajout des propositions de 
remplacement dans les outils QA, les validateurs, etc

- 1 an pendant lequel l'ancien tag est encore officiellement supporté 
(par exemple par le rendu osm.org), ensuite il ne l'est plus, ce qui 
pousse à basculer vers le nouveau

- au bout de 2 ans, mass edit


Plus globalement, l'entretien de la base sur le long terme nécessitera 
de plus en plus d'automatisation car le nombre de contributeurs augment 
moins vite que la quantité de données dans la base. On va donc 
mécaniquement se retrouver à avoir de plus en plus de données qui seront 
de plus en plus obsolètes, sauf si on s'outille pour leur entretien et 
qu'on automatise les tâches où une action humaine n'apporte rien.

-- 
Christian Quest - OpenStreetMap France