Le 18 octobre 2012 21:53, Pierre Béland <[email protected]> a écrit : > surtout pas que tous viennent de façon désordonnée et passionnée exprimer > leur point de vue. Ça ne fera pas avancer le débat.
Tout le monde ne vas pas s'adresser front baissé directement au DWG. Malgré tout, les listes publiques de discussion sont là pour connaitre le sentiment d'une communauté plus large, afin que les quelques uns qui vont négocier habilement avec le DWG rapportent le sentiment général (tout en permettant d'avoir derrière lui une trace de ce sentiment général partagé par un plus grand nombre, pour conforter certains arguments). Mais c'est vrai que les propos échangés ici sont trop agressifs et ne peuvent pas tous servir directement pour la négociation. Encore une fois, on (la communauté et le DWG) a besoin d'ambassadeurs comme intermédiaires de confiance, acceptés par les deux parties, sans pour cela demander à tout le monde de s'adresser directement au DWG qui, rapidement, se retrouve submergé et ne peut plus rien faire d'autre que le statu quo de sa position puisqu'il ne sait plus comment s'adresser autrement à chacun étant donné les trop nombreux avis contradictoires qu'il reçoit : pour se simplifier sa tâche il choisit évidemment alors de ne plus s'adresser à tout le monde, mais prends les problèmes isolément avec quelques utilisateurs qui sont pour lui un problème (même s'ils ont le soutien large de leur communauté, celle-ci ayant le gros défaut d'être inaudible et incompréhensible et ne souhaitant pas non plus négocier pour aplanir les angles). Je reste malgré tout convaincu que la "solution" du double compte ne sert strictement à rien et en tout cas pas du tout à la veille de la qualité. Techniquement elle ne tient pas la route et OSM a évolué depuis longtemps depuis l'introduction des changesets qui permettent la séparation et l'identification des imports tout en ne nécessitant aucun changement de compte utilisateur. Je note même que la politique imposée par le DWG n'oblige **même pas** à identifier les seconds comptes pour les associer sans équivoque avec le compte principal (il ne fait qu'une "recommandation", ce qui rend cette obligation du double compte encore plus inutile et inapplicable en pratique). Si le problème est la taille des changesets pour faciliter les reverts (sans trop de conflits d'édition à résoudre) c'est qu'une solution technique reste à développer dans les éditeurs (particulièrement dans JOSM, puisque dans Potlatch les changesets sont limités en durée, comme en volume par la capacité des navigateurs à repondre efficacement, et parce que Potlatch ne permet pas réellement d'importer des données externes mais sert surtout à travailler sur des zones déjà tracées sur un fond d'imagerie où forcément tout s'intègre immédiatement). Le problème de qualité pourtant est aigu avec Potlatch, puisque n'importe qui ne fait que des modifications locales sans tenir compte de ce qui s'y connecte, et efface ou modifie trop facilement des données qui n'avaient pas besoin d'être modifiées (ce sont des erreurs humaines essentiellement dont la gravité reste cependant localisée, car Potlatch en revanche ne permet pas de modifications en masse par des moyens automatisés). L'autre sérieux problème de qualité vient de l'API de modification directe de la base de données. Cela concerne un peu JOSM, mais surtout ce qu'on peut faire avec des bots si ceux-ci sont opérés par des vandales. Une bonne solution contre ça serait de développer une interface nécessitant une identification sécurisée des utilisateurs et du logiciel qu'ils utilisent. Les bots sont à autoriser spécifiquement et de façon plus fine que les utilisateurs régulier de JOSM. JOSM n'est pas un outil automatique, il y a encore un opérateur humain qui voit et contrôle l'essentiel des modifs faites avant leur envoi, même s'il est facile de programmer un bot pour générer un fichier .osm qu'un opérateur humain chargera dans JOSM pour l'envoyer tel quel au serveur. Mais un vrai bot opéré par un vandale n'a pas besoin de JOSM. Il ira nettement plus vite et plus facilement en programmant son bot pour laisser encore moins de traces, en utilisant l'API directement. Le bot vandale aussi pourra envoyer des changesets en grand nombre, avec autant de comptes utilisateur qu'il voudra, et passera les radars basés sur les tailles de changeset (quelques parades existent mais ne peuvent pas se baser sur l'identifiant utilsiateur, ni la taille de changeset, mais sur la détection des adressses IP source permettant de savoir que les divers comptes utilisateurs sont liés et que les divers changesets malveillants peuvent être alors retrouvés). Le bot ne répondra pas non plus aux messages envoyés aux comptes utilisateurs qu'il utilise, ou bien les comptes utilisés (spammeurs) seront déjà identifiés sur d'autres sites comme malveillants (pour ça on a des blacklists publiques d'adresses mail ou de domaines ou de blocs d'adresses IP correspodnant à des proxies anonymiserrs, regardez ce qui est fait sur Wikipédia par exemple pour les détecter). Cela pourra aussi constituer des lignes défensives de nature technique (qui ne dispenseront pas non plus une supervision humaine collective). _______________________________________________ Talk-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-fr
