D'abord il faut séparer :
- l'action du robot de "rédaction" qui peut être aussi bien celle de
masquer que de démasquer certaines infos;
- de son résultat : le fait que la version est effectivement masquée
dans son état actuel.
Ici le message est destiné à avertir qu'une version n'est pas visible.
Il ne s'agit pas réellement de dire que le bot a pris une décision
quelle qu'elle soit ni qui l'a prise et pour quelle raison (la raison
est donnée en suivant le lien).
Le message étant générique, il n'y a pas nécessité de dire que c'est à
cause du changement de licence (ce qui n'est pas vrai pour tout le
monde, car des utilisateurs ont ben accepté la seconde licence mais
ont malgré tout été masqués, ce qui me semble excessif quand en même
temps on accepte des imports de sources à qui on demande de passer en
ODbL sans les obliger pour autant à accepter pour elles-mêmes des
"Contributor Terms" qui ne les concerne pas et à laquelle elles n'ont
pas à s'engager (c'est plutôt à ceux qui effectuent des modifs ou
imports dans la base de s'engager à respecter les licences et
attributions).
Pour moi la décision de masquer les contributions de ceux qui ont
accepté la licence mais refusé les CT est excessive (et inutile). Il
suffisait juste de leur bloquer l'accès en modification sans impacter
les données existantes qui ont été saisies en acceptant alors des
termes parfaitement valides auparavant. Il n'y a pas de changement de
licence pour ceux là, il n'y avait aucune raison de les masquer.
Je note que des exceptions ont été mises mais uniquement pour
certaines sources comme UMP-PL, mais pas en tenant compte de la lience
ODbL déjà acceptée ni du fait que les CT ont été refusés par un
utilisateur, et de fait certaines seulement de leurs contributions ont
été restaurées après avoir vérifié l'origine ou la compatibilité des
données qu'ils avaient bien indiqué correctement, mais on continue à
masquer toutes les autres contributions faites ailleurs par ces mêmes
utilisateurs.
Pour moi ce problème a été résolu à l'envers et en dépit du bon sens,
car avant meêm de commencer la "rédaction" de leurs contributions, on
ne leur a même pas demandé si ils plaçaient leurs anciennes
contributions ou non sous une nouvelle licence additionelle afin de
pouvoir les garder même en leur absence pour la suite du projet.
Pour moi il y a des tas de trucs totalement inutiles dans les CT. La
seule application du droit normal du copyright et des licences
suffisait. Mais les engagements demandés aux contributeurs sont
supérieurs à ceux que l'on demande aux sources (qu'on importe sans
réserve), et on les prive inutilement de leurs droits (et de leurs
mérites passés sur le projet, comme si tout d'un coup ils étaient
totalement indésirables alors qu'ils étaient les bienvenus avant).
Enfin tant pis pour les morts qui n'ont pas pu répondre, on les a
oublié et enterrés définitivement. Aucun respect. Et cela va à
l'encontre de l'objectif à long terme du projet qui ne devrait pas
renier son héritage (sachant qu'on pourra toujours modifier ce qui
devra l'être au moment utile, mais pas ainsi de façon aussi
massacrante et mal perçue par ceux qu'on a trop vite oubliés mais qui
ne sont plus là pour seulement pouvoir répondre).
Pour moi il était entièrement suffisant de mettre en place dans la
base un filtre sur la compatibilité des licences, sans ôter aucune
donnée. On en revient au problème initial qui est qu'OSM veut tout
mélanger dans la même base comme si c'était une seule et même couche,
et qui ne permet pas de clairement séparer les sources et de les
sélectionner à la demande en fonction des usages, avec une bien
meilleure cohérence des données au sein de chaque source (ou de chaque
projet collectif qui aurait pu se créer autour d'une thématique plus
facile à suivre et à éditer, ainsi qu'à évaluer au plan qualité sur un
jeu de données plus facile à analyser par des outils automatiques, et
permettant même ensuite des outils facilitant les transitions ou
adaptations de données d'un jeu de données à l'autre).
Pour moi l'OpenData ne consiste pas à mélanger toutes les données car
les modèles uniformes ne satisferont jamais aux besoins de tout le
monde en même temps et introduiront toujours des ambiguïtés si on
prend l'ensemble comme un tout indivisible, alors que la plupart des
problèmes sont facilement résolus sur le rapprochement de seulement un
ensemble réduit de jeux de données, chacun ayant des conventions qu'on
fait progressivement converger autant que possible mais sans imposer
nécessairement une solution unique tout de suite qui changera le
lendemain pour correspondre aux besoins d'un autre groupe devenu plus
influent mais qui n'a pas participer aux traveaux de convergence avec
d'autres jeux de données.
La conséquence de cela est la grande difficulté à traiter de façon non
ambiguë des tas de données dans la base, mais aussi leur
sous-utilisation effective au final (pour les rendus ou l'analyse ou
les applications dérivées) quand les rapprochements possibles sont
très disparates. On beau faire alors, on ne cesse de corriger selon
les besoins des uns ou des autres, de façon souvent contradictoire et
le processus de convergence cesse à un certain point au milieu d'une
quantité importante de "bruit" aléatoire.
Le 26 juillet 2012 18:28, Christian Rogel
<christian.ro...@club-internet.fr> a écrit :
>
> Le 26 juil. 2012 à 14:41, Philippe Verdy a écrit :
>
>
>
> J'approuve aussi le terme "masqué" qui répond bien à ce que fait
> effectivement le bot (qui se charge de cacher toutes les contributions
> d'un ou plusieurs utilisateurs, pour un ou plusieurs motifs qui seront
> précisés dans la page accessible par le lien %{redaction_link}.
>
>
> On peut mettre "masqué" pour être très pédagogique, mais, il ne s'agit plus
> de traduction, mais d'extraction d'une propriété occasionnelle du bot, parmi
> 2 ou 3 autres.
>
> "Redacted" ne signifie pas "masqué", par quelque bout qu'on le prenne et la
> focale est alors complètement décalée. Pourquoi pas.
>
> J'avais cru qu'il s'agissait de traduire.
>
>
> Christian Rogel
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
