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

[Florian LAINEZ]

Je comprends bien tes deux arguments : s'adapter à la communauté, mieux
vendre l'idée.

Au final on a 2 scénarios :
- la période de 2 ans est adaptée ou trop longue (la transition a eu lieu
depuis longtemps) : pas de problème, l'édition automatique édite donc un
nombre minime d'objets
- la période est trop courte : les outils et rendus ne se sont pas adaptés,
malgré toutes les précautions prises (les demandes d'évolution sont restées
sans suite).
Je pense que c'est l'essentiel de ma proposition : la communauté devrait
être plus sévère et défendre plus agressivement (je pèse mes mots) la
décision de dépréciation prise et non appliquée pendant 2 ans.
On peut même aller jusqu'à imaginer un mécanisme de "name and shame" pour
dénoncer les outils/rendus qui ralentissent à desseins le projet OSM, qui
ne respectent pas les décisions communautaires.
En bref, mettre en place ce calendrier de 2 ans, c'est plutôt large pour
que tout le monde s'adapte, ça convient à toutes les situations et si
quelqu'un ne bascule pas, on doit lui mettre la pression.

PS : je n'ai pas mentionné à dessein ton exemple d'arrêt de bus. On a créé
une exception pour ces cas compliqués, ils ne sont donc pas concernés par
la proposition.

Avec cela, on peut affiner le cycle de dépréciation.
Christian a proposé que l'ancien tag soit considéré comme une anomalie par
tous les outils dès le jour de la dépréciation et que les rendus assurent
la rétro-compatibilité durant 1 an, puis qu'une édition automatisée
survienne après 2 ans.
Si je me place du côté "éditeur de rendu", je me dis que, si le tag existe
encore durant la deuxième année, alors je n'ai pas envie de m'en passer.
Pour pallier à cela, je propose de prévoir une édition automatique au bout
d'un an pour ajouter le nouveau tag sur tous les objets pour lesquels
l'ancien tag est présent.

J'ai envie de rajouter un autre garde-fou : si la communauté n'a pas
terminé le plan de transition après un an, alors l'édition automatique
après 2 ans n'est plus recommandée (la communauté doit, pour être exigeante
envers les autres, être avant tout exigeante avec elle-même)

Good ?

Le dim. 12 déc. 2021 à 15:37, <osm.sanspourriel at spamgourmet.com> a écrit :

> On est d'accord mais c'est justement pour donner plus de visibilité que
> je propose que ceux qui proposent de déprécier doivent se poser la
> question de la durée de la période de transition (et on peut mettre un
> "2 ans maxi").
>
> Le faire "par défaut" comme tu le proposes a l'inconvénient de le rendre
> moins visible.
>
> 2 ans pour un schéma foutraque (public transport) c'est trop court mais
> pour de mauvaises raisons.
>
> Peut-être qu'on peut dire que la dépréciation entraine une transition de
> 2 ans qui peut être raccourci par inclusion d'un schéma de transition
> plus court dans la proposition de dépréciation.
>
> Ce qui permet de régler le problème dans tous les cas tout en le rendant
> plus visible.
>
> En laissant de plus des marges de manœuvre pour la communauté.
>
> De plus il faut s'attendre à des résistances de la communauté pour des
> éditions mécaniques "automatiques". Dire que la durée peut être discutée
> dans la proposition de dépréciation rend l'idée plus "vendable".
>
> Jean-Yvon
>
> Le 12/12/2021 à 14:00, Florian LAINEZ - winnerflo at free.fr a écrit :
> > Peut-être que c'est au niveau du processus de modification qu'il faut
> >> préciser le cycle de vie choisi pour la dépréciation.
> >>
> > C'est une solution "community friendly" mais elle passe néanmoins à côté
> de
> > l'enjeux que je tente de régler ici : une meilleure visibilité du cycle.
> Il
> > me semble donc important pour cette raison de rester sur une deadline
> fixe.
> > Pour éviter tout problème, j'ai choisi un très longue période (2 ans),
> > c'est une période suffisante pour gérer tous les cas.
>
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 

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