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

Dim 19 Déc 12:23:27 UTC 2021

je ne sais pas qui m'a balancé dans le weekly-osm ;) mais du coup, ça y
est, les anglophones s'incrustent dans la discussion
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Deprecated_and_unsupported_status

Le dim. 19 déc. 2021 à 12:17, Florian LAINEZ <winnerflo at free.fr> a écrit :

> Hello,
>
> George je te trouve très sage : tes idées sont excellentes, n'hésite pas à
> modifier la proposition directement la prochaine fois.
> Concernant la liste, je l'ai rajouté dans le tableau directement :
> https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dschool#Documentation
> À vous de la compléter !
>
> Du coup j'ai réalisé que l'on ne devait pas modifier les pages de
> discussion, c'est donc une nouvelle exception que j'ai mentionné dans le
> modèle
> <https://wiki.openstreetmap.org/wiki/Deprecated_features_follow-up#Documentation>
> :
> "Update every other mentioning the car
> <https://wiki.openstreetmap.org/wiki/Key:car>=* tag (listed here
> <https://wiki.openstreetmap.org/w/index.php?title=Special:WhatLinksHere/Key:car&limit=100>)
> excluding the discussion pages"
>
> Yves, tu es la seconde personne à proposer d'adapter le délai selon chaque
> cas.
> Je comprends le pourquoi : c'est plus pratique et adapté *pour la
> communauté.*
> Mais je ne suis toujours pas convaincu que les avantages surpassent les
> inconvénients.
> Le principal, j'insiste là-dessus, étant la lisibilité, la prédictibilité,
> c'est à dire la capacité *pour tout utilisateur des données / développeur
> d'outil* de prévoir *à l'avance* la date de bascule.
> Je vais créer quand j'aurai le temps un schéma pour illustrer de manière
> plus détaillée mon propos. Quelque chose de plus parlant que ça
> https://wiki.openstreetmap.org/wiki/Proposed_features/Deprecated_and_unsupported_status#Transition_plan
> (que j'ai créé hier).
>
> Quant à la durée de 2 ans : je n'ai pas de soucis à en discuter, ça me
> paraît tout simplement le meilleur compromis pour l'instant.
> En vérité, si la proposition est appliquée et fonctionne bien pendant
> quelques années, cela pourra avoir un sens de la diminuer à 1 an voire 6
> mois dans le futur.
>
> Comme l’a rappelé Jean-Yvon, un moyen universel et efficace est
>> l’utilisation des DataItems (la version OSM du mécanisme Wikidata).
>>
> Je suis hyper d'accord. Je suis un gros promoteur des data items. En
> attendant que tous les outils utilisent les data items, cette proposition
> inclut le mécanisme visant à aller faire des demandes dans chaque outil
> pour déprécier les tags. Pour moi c'est une étape intermédiaire. Dans
> quelques années, on se fera plus pressant pour universaliser les data items
> dans tous les projets downstream. D'ici là, assurons-nous qu'ils soient à
> jour et utilisables en l'état.
>
> PS : sur proposition de Donat j'ai rajouté un lien vers tous les
> repositories dans le modèle de tableau
> https://wiki.openstreetmap.org/wiki/Deprecated_features_follow-up#Tools
>
> Le dim. 19 déc. 2021 à 10:15, Yves P. <yves.pratter at gmail.com> a écrit :
>
>>
>> > Le 9 déc. 2021 à 09:18, Florian LAINEZ <winnerflo at free.fr> a écrit :
>> >
>> > 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 ans me parait trop long. Suite à lecture du fil, il faut probablement
>> donner un délai adapté à chaque réforme.
>>
>> > 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
>>
>> Après vérification que les principaux outils ont effectivement basculés,
>> je suis favorable à une édition de masse.
>> Ça même donc à la remarque primordiale de Noémie :
>>
>> > Le 9 déc. 2021 à 12:45, Noémie Lehuby via Talk-fr <
>> talk-fr at openstreetmap.org> a écrit :
>> >
>> > Mais je pense au contraire que le point primordial n'est pas de
>> dégommer à vue à la fin de la période mais plutôt de faire en sorte que les
>> nouvelles données soient supportées systématiquement à la fin de cette
>> période.
>> > La période de transition serait alors surtout une période de migration,
>> au moins pour les outils (doc, éditeurs, rendu et réutilisations).
>> Oui :)
>>
>> > Si on se dit juste "on tue le tag dans 2 ans" sans mettre en place un
>> plan de migration crédible, j'ai un peu peur qu'il ne se passe pas grand
>> chose pendant ces deux ans (vu que l'ancien tag est potentiellement
>> majoritaire dans les données et encore ok) puis qu'on fasse un edit auto
>> mais que les vieux tags reviennent parce que certains éditeurs continuent
>> de les proposer et que la doc est contradictoire en fonction de là où tu
>> regardes.
>> C’est un des problèmes.
>>
>> Les principaux étant :
>> - la saisie (pas possible ou trop lourde suivant l’éditeur)
>> - les rendus qui n’incitent pas à utiliser le tag (cf. tags healtcare) ou
>> provoquent de mauvaises pratiques (taguer pour le rendu)
>>
>> > Idéalement, une page de process de migration devrait être créée sur le
>> wiki après le vote pour lister les choses à faire et permettre de suivre
>> l'avancement.
>> > Comme il y a déjà un paragraphe Features/Pages affected (List of wiki
>> pages that would be edited if the proposal is approved) dans les Proposals,
>> il pourrait y avoir un paragraphe pour la doc, les éditeurs, les rendus, etc
>> > avec une note "si vous connaissez d'autres outils que ceux mentionnés
>> ici qui utilisent ce tag, merci de les ajouter dans cette liste et/ou de
>> leur envoyer cette page pour leur indiquer que le tag arrive en fin de vie"
>> > Sachant que si on souhaite faire une période de transition, deux
>> évolutions sont potentiellement à prévoir dans les éditeurs : une pour
>> ajouter la nouvelle manière et signaler que l'ancienne est en fin de vie si
>> l'outil le permet, puis une pour supprimer l'ancienne à la fin de la
>> période de transition. Donc avoir une liste exhaustive des outils concernés
>> semble assez primordiale pour que ça soit effectif.
>> Oui c’est très important.
>>
>> Comme l’a rappelé Jean-Yvon, un moyen universel et efficace est
>> l’utilisation des DataItems (la version OSM du mécanisme Wikidata).
>> Une éditeur ou un outil QA qui l’utilisent pourront automatiquement
>> signaler un tag déprécié.
>>
>> Si un développeur ne veut pas ou ne peut pas mettre à jour une appli, un
>> rendu… on aura au moins une base de connaissance centralisée pour lister
>> les tags et outils impactés, ceux qui sont ou pas à jour.
>>
>> Note : Il y a une ébauche de liste qui existe avec les projets associés à
>> un tag dans TagInfo.
>> Le problème c’est que chaque développeur doit proposer une liste et la
>> tenir à jour.
>> De plus vu la complexité de certains tags ou usages de tags, c’est
>> parfois difficile de dire précisément comment un tag est réellement
>> supporté par une appli, un rendu.
>>
>> Regardez par exemple les descriptions dans TagInfo <
>> https://taginfo.openstreetmap.org/tags/information=guidepost#projects>
>> pour le tag information=guidepost.
>> Par toujours simple à comprendre pour un humain, quasi impossible pour
>> une machine.
>> Dans le cas des rendus, les icônes utilisées sont parfois affichées,
>> parfois non.
>>
>> __
>> Yves
>>
>>
>> _______________________________________________
>> Talk-fr mailing list
>> Talk-fr at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> --
>
> *Florian Lainez*
> @overflorian <http://twitter.com/overflorian>
>

-- 

*Florian Lainez*
@overflorian <http://twitter.com/overflorian>