FR:Vandalisme

From OpenStreetMap Wiki
(Redirected from FR:Vandalism)
Jump to navigation Jump to search
Vandalisme sous la forme de faux bâtiments

.

Le vandalisme est le fait d'ignorer les standards patiemment développés par la communauté internationale d’OpenStreetMap. Les simples erreurs d’éditions n'en font pas partie, mais elles doivent parfois être annulées en employant les mêmes outils que ceux utilisés pour combattre le vandalisme.

Types de vandalisme

  • Violation des droits d’auteurs (Copyright infringement).
  • Graffitis
    Graffiti dans les traces GPS (3 noms de points de repères).
  • Disputes dans la base de données d’OpenStreetMap (guerre des données) Disputes.
  • Disputes sur le wiki (guerre d’édition).
  • Utilisation inappropriée d’édition automatique (Bots).
  • Perturbateur persistant du bon fonctionnement de la base de données.
  • Harcèlement ou dénigrement, divulgation de données personnelles.

Les simples erreurs et erreurs de manipulation ne sont pas du vandalisme, même s'il peut être nécessaire de procéder à une annulation dans certains cas.

Réponse au vandalisme

Ligne de conduite

Le point de vue depuis la discussion de septembre 2009 : [1]

  • Nous devrions attendre de tous les contributeurs qu’ils tentent en permanence de faire des modifications qui soient à la fois bonnes, précises et bien recherchées.
  • Nous devons nous assurer que chaque contributeur équilibre favorablement la balance vers un meilleur jeu de données, et non l’inverse. Si une contribution comporte certains doutes, nous devons en aviser les autres contributeurs pour enquêter et y remédier.
  • Nous devons être conscient que l’erreur est humaine, que chacun a besoin de temps pour apprendre, et que même les nouveaux ont souvent besoin d’assistance et peuvent aussi y répondre.
  • Nous devons demander mais ne pouvons pas exiger des contributeurs qu’ils ajoutent des commentaires à leurs groupes de modifications et qu’ils créent une page personnelle utile avec quelques détails sur leurs centres d’intérêt et leurs connaissances. Le faire permettra d’éviter des retours aux versions précédentes mais favorisera au contraire les échanges d’aide si nécessaire.
  • Au cas où quelqu’un semble effectuer des modifications pouvant sembler étranges, on devra initialement supposer sa « bonne foi » mais devrions surveiller attentivement et en discuter avec d’autres si nécessaire.
  • Si on peut prouver qu’un nombre très significatif de modifications sont contre-productives, obscènes, ou considérées comme nuisibles à la réputation du projet, alors les groupes de modifications en question peuvent être immédiatement annulés et sans avoir à vérifier 100% du reste de ce groupe de modifications.
  • Si les modifications sont douteuses sans pouvoir être immédiatement prouvées comme incorrectes, alors nous devrions contacter la personne et collecter davantage d’informations. Si nous n’obtenons pas de réponse raisonnable (ou n’obtenons pas de réponse) et si les modifications douteuses continuent sans montrer que la balance penche vers des contributions clairement positives, alors nous devrions chercher à prouver au moins une modification incorrecte et parvenir à la décision prise dans une discussion qu’il est approprié d’annuler le groupe de modifications en question, et potentiellement tous les groupes de modifications de cette personne.
  • Si le problème persiste, nous pouvons bloquer virtuellement cette personnes dont les ajouts sont annulés sans inspection du mérite des changements, à moins que la personne contacte un administrateur pour montrer qu’elle a grandi et appris, et qu’elle souhaite qu’on lui donne une seconde chance.
  • Quiconque effectue de mauvaises modifications dans n'importe quelle partie du monde doit s’attendre à une réponse globale — il semble peu probable que quelqu’un vienne semer le désordre en Irlande tout en effectuant du bon travail en Islande : on ne veut généralement pas avoir à comprendre ce qui se passe dans la tête de chacun, on préfère juste protéger le bon travail en commun des autres contre les méfaits provoqués même au cas où quelques bonnes modifications figurent dans un large lot de non-sens.
  • Ceux qui annulent le travail des autres doivent s'attendre à devoir démontrer que cette annulation a été bien raisonnée et proportionnée aux problèmes constatés.
  • Parfois des modifications « nulles » — celles n’ayant pas d’autre but que de « toucher » l’élément — peuvent être effectuées par erreur par l’éditeur ou bien seront utiles pour mettre à jour une zone. Cependant un large nombre de modifications « nulles » peut être considéré comme un comportement perturbant.

Annulation normale (revert)

Si l'étendue du vandalisme est locale et son impact sur la communauté en général est limité, veuillez alors prendre poliment contact avec la personne concernée au moyen de la messagerie OSM en supposant de bonnes intentions et attendre environ 24 à 48 heures pour une réponse. Si une réponse adéquate n’a pas été reçue, il peut alors être approprié de discuter du problème sur une liste de diffusion appropriée (normalement la liste locale, nationale ou régionale) ou avec des personnes de confiance. Si certaines modifications peuvent être prouvées comme contre-productives et si les modifications utiles ne sont pas évidentes, alors les groupes de modification en question devraient être annulés.

Annulation rapide (Speedy revert)

Si un nombre significatif de contributions peut être définitivement prouvé comme malveillant, obscène ou litigieux ou que ces modifications peuvent nuire à la réputation du projet, alors il est important d’y répondre immédiatement et annuler d’abord et poser des questions ensuite au contributeur qui y répondra en parallèle. Il peut également être approprié de contacter en même temps le Groupe de travail de la base de données.

Soyez avisé qu’il est désormais possible (depuis août 2009) de n’annuler que les changements qui ne suppriment pas les éléments qui ont été ajoutés, améliorés ou corrigés par d’autres.

Blocage temporaire

Si, après avoir été contacté par l'intermédiaire de discussions sur les modifications litigieuses et / ou de messages le contributeur ne modifie pas son comportement, le Groupe de travail de la base de données (DWG) peut instaurer un blocage temporaire de l'utilisateur. Ceci n'est ni une présomption de culpabilité ni un bannissement du projet. Il s'agit plutôt d'une mesure visant à attirer l'attention du contributeur, car il doit se connecter au site OSM et lire le message de blocage avant de pouvoir poursuivre l'envoi de modifications via l'API.

La durée du blocage temporaire peut aller de 0 à 96 heures. Le DWG peut également imposer que l'utilisateur se connecte et lise le message de blocage avant que le blocage ne soit levé, ce quelle que soit la durée du blocage. Les membres du DWG commencent souvent par un blocage de 0 heures imposant la lecture de ce message comme mesure initiale pour les contributeurs en conflit qui ne répondent pas. Un historique des blocages est disponible ici(en).

Exclusion permanente

Voir la politique d'exclusion de la Fondation OSM pour plus d'informations.

Outils et liens

Il existe des outils permettant d'annuler des contributions spécifiques dans la mesure où les objets impactés n'ont pas subis de changements ultérieurs. Ces outils sont souvent difficiles à utiliser et requièrent de bonnes connaissances techniques pour ne pas causer de problèmes ultérieurement.

Gouvernance

Lorsque c’est possible, la communauté locale OpenStreetMap devrait résoudre les cas de vandalisme au moyen des processus ci-dessus.

Groupe de travail sur la base de données

Article principal : Data working group

Le Groupe de travail sur la base de données (Data working group ou DWG) est autorisé par la Fondation à traiter des cas plus sérieux de vandalisme et à les rapporter au bureau lors de ses réunions mensuelles. Dans les rares cas où l’approche communautaire n’aboutit pas le problème devrait être signalé au DWG par courriel à (data@osmfoundation.org).

Développement

Il existe de nombreux outils et techniques qui peuvent être utilisés pour gérer les problèmes de vandalisme. Les solutions possibles incluent :

  • Listes blanches et listes noires — pour la détection automatique ou le recensement automatique des modifications suspectes.
  • Retour aux données précédentes (data rollback) — la communauté peut effectuer cette tâche en utilisant des outils qui ont été testés.
  • Suppression des données — la communauté peut effectuer cette tâche en utilisant des outils qui ont été testés.
  • Annulation des modifications
  • Suppression des historiques — requière des privilèges élevés.
  • Annulations simples
  • Données avec historique ultérieur.

Liens externes

[Geotribu] Carto-vandalisme dans OpenStreetMap : mythe ou réalité ?, Quy Thy Truong

Voir aussi