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

Dim 19 Déc 11:17:32 UTC 2021

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>