IT:Automated Edits code of conduct

From OpenStreetMap Wiki
Jump to: navigation, search
Lingue disponibili — Automated Edits code of conduct
Afrikaans Alemannisch aragonés asturianu azərbaycanca Bahasa Indonesia Bahasa Melayu Bân-lâm-gú Basa Jawa Baso Minangkabau bosanski brezhoneg català čeština dansk Deutsch eesti English español Esperanto estremeñu euskara français Frysk Gaeilge Gàidhlig galego Hausa hrvatski Igbo interlingua Interlingue isiXhosa isiZulu íslenska italiano Kiswahili Kreyòl ayisyen kréyòl gwadloupéyen kurdî latviešu Lëtzebuergesch lietuvių magyar Malagasy Malti Nederlands Nedersaksies norsk norsk nynorsk occitan Oromoo oʻzbekcha/ўзбекча Plattdüütsch polski português română shqip slovenčina slovenščina Soomaaliga suomi svenska Tiếng Việt Türkçe Vahcuengh vèneto Wolof Yorùbá Zazaki српски / srpski беларуская български қазақша македонски монгол русский тоҷикӣ українська Ελληνικά Հայերեն ქართული नेपाली मराठी हिन्दी অসমীয়া বাংলা ਪੰਜਾਬੀ ગુજરાતી ଓଡ଼ିଆ தமிழ் తెలుగు ಕನ್ನಡ മലയാളം සිංහල ไทย မြန်မာဘာသာ ລາວ ភាសាខ្មែរ ⵜⴰⵎⴰⵣⵉⵖⵜ አማርኛ 한국어 日本語 中文(简体)‎ 吴语 粵語 中文(繁體)‎ ייִדיש עברית اردو العربية پښتو سنڌي فارسی ދިވެހިބަސް

Il codice di condotta delle Modifiche Automatiche deve essere seguito tutte le volte che si effettuano delle Modifiche Automatiche al database OpenStreetMap. Queste regole si applicano sia a chi usa i bot, oppure script usati o creati per importare nuovi dati o per fare delle modifiche sistematiche al database con altri mezzi, senza effettuare un controllo su ogni singola modifica. Questa policy si applica anche a modifiche significative fatte usando funzioni tipo 'cerca e sostituisci' usando editor standard come JOSM.

Lo scopo di queste regole è di evitare che il database sia danneggiato. Tieni ben presente che può essere molto difficile se non impossibile annullare o fare il 'roll back' di modifiche non appropriate, in particolare se sono state fatte successive modifiche agli elementi interessati. Modifiche automatiche fatte senza attenzione possono perciò comportare per altre persone un lavoro pesante per sistemare il problema. Ignorare queste regole sarà considerato come vandalismo e sarà trattato come tale se si ripete.

Un intervento sulle modifiche automatiche è stato tenuto a SOTM 2016, dando un'utile panoramica sull'argomento.

Ambito

In generale, queste regole si applicano a tutte le modifiche in cui sono applicati dei cambiamenti agli oggetti nel database senza che sia fatto un controllo individuale da chi sta eseguendo le modifiche. Questo comprende:

  • modifiche fatte da Bot, che per definizione operano in autonomia senza intervento umano.
  • import di dati, compresi sia gli import completamente automatici sia quelli in cui viene utilizzato un editor standard;
  • altre modifiche al database fatte da script;
  • uso di funzioni trova-e-sostituisci negli editor standard come JOSM oppure ricerche usando servizi come Overpass API e modifiche conseguenti fatte senza il controllo sui singoli elementi;
  • cambiare i tag manualmente su larga scala senza un'adeguata revisione;

Anche se stai per modificare i tag di un grande numero di oggetti sistematicamente e non pensi che sia una modifica automatica che ricade sotto questo codice di condotta, è comunque una buona idea discutere prima le tue modifiche. Magari c'è consenso tra la comunità locale sugli attuali tag e tu non ne sei a conoscenza? Oppure hai male interpretato una pagina nella Wiki di OpenStreetMap? Discuterne in anticipo diminuisce la probabilità che tu ti arrabbi e che si discuta di annullare le tue modifiche.

Linee guida

Sii prudente!

OpenStreetMap si basa sul consenso generale piuttosto che sul voto di maggioranza, perciò sii prudente nell'eseguire modifiche significative anche se la maggioranza approva la modifica. Tieni anche presente che la documentazione dei tag nella Wiki non è l'arbitro definitivo del modo "corretto" di assegnare i tag.

Le modifiche che tu proponi possono cambiare o modificare il lavoro di molti altri mappatori in luoghi che non ti sono familiari, e tra culture che non conosci. E' perciò importante che tu faccia ricerche e pianifichi il tuo lavoro in modo diligente e lo esegua con prudenza, in modo professionale.

Se le contestazioni rimangono civili in tutte le fasi, sappi ascoltare e sicuramente evita le edit wars. Se il problema non si può risolvere allora cerca l'aiuto di qualcuno che possa mediare.

Uso accettabile
  • La correzione di evidenti errori di battitura, per esempio cambiare hihgway=residential in highway=residential.
  • Correggere il tuo stesso lavoro. Se sai di aver fatto un errore sistematico allora puoi correggerlo con un processo automatico. Tieni comunque presente il rischio che il tuo processo potrebbe modificare più dati di quelli che volevi.
  • Modifiche utili che sarebbe noioso fare manualmente - approvate dalla comunità e discusse.
Uso problematico
  • Usare uno strumento per affermare uno standard, o la tua personale interpretazione di uno standard, quando potrebbero esserci giustificati motivi per altre interpretazioni o dove lo standard non rispecchia la pratica comune. In particolare è un problema quando una persona, o un piccolo gruppo di persone, stabiliscono uno standard di codifica e poi usano processi automatici per applicarlo nel database senza una consultazione appropriata. Tieni a mente che la Wiki non deve essere usata come la definizione dell'unico modo corretto di assegnare i tag, e che non è accettabile usare la wiki come giustificazione per modifiche massive ai dati senza una adeguata consultazione.
  • Importare dati sopra altri dati senza integrare opportunamente il nuovo contenuto con quanto preesistente o aderendo a regole diverse dalle linee guida per l'Import.
Altri approcci

Come alternativa alle modifiche automatiche, prendi in considerazione di sottoporre il presupposto problema a strumenti di controllo qualità come Keep Right o osmose, dove i dati problematici possono essere sottoposti al controllo di qualcuno che ha tempo e conoscenza locale per valutare la modifica più accuratamente.

Documenta e discuti i tuoi piani

Se hai in mente di fare una modifica automatica, prima discutine e documentala. La documentazione deve essere inserita nella wiki e la proposta discussa nelle opportune mailing list:

  • In talk (la mailing list generale)
  • oppure imports, quando discuti di import o di problemi di import precedenti
  • oppure se le tue modifiche riguardano solo una nazione o un territorio, usa la mailing list nazionale, i forum, o altri mezzi di comunicazione standard per il territorio interessato dalle modifiche
  • oppure se le tue modifiche riguardano solo una città o una piccola regione, la mailing list locale, i forum, o altri mezzi di comunicazione standard per il territorio interessato dalle modifiche
  • e se le tue modifiche riguardano un argomento specialistico, tipo le piattaforme petrolifere o il trasporto pubblico che hanno apposite liste, devi anche discutere le tue intenzioni nella specifica mailing list.

Se scopri che il tuo piano è largamente accettato tranne da pochi che non sono d'accordo, allora confrontati con questi ultimi per capire i motivi del loro dissenso. Se non trovi un accordo prendi in considerazione di fare un'eccezione per le loro modifiche o la loro zona. Se le critiche sono maggiori, forse dovresti ripensare i tuoi piani.

Qualsiasi successivo cambiamento o estensione dell'ambito delle modifiche che avevi proposto deve essere discusso nello stesso modo e richiede una nuova approvazione della comunità. Non è possibile avere una approvazione in bianco per un generico "Voglio correggere i tag con errori di ortografia".

Di solito si documentano le modifiche che si vogliono fare in una pagina wiki in inglese con nome "Automated edits/username" (dove username è il nome utente OSM dell'account con cui saranno eseguite le modifiche (pensa adesso al nome, così non dovrai rinominare la pagina dopo), e aggiungila a Category:Automated edits log.

La documentazione deve riportare:

  • Chi sta facendo le modifiche (preferibilmente il vero nome e come contattarti, l'ideale è l'indirizzo email)
  • Il motivo delle modifiche e perché sono importanti
  • Una descrizione dettagliata dell'algoritmo che sarà usato per decidere quali oggetti cambiare e come
  • Informazioni sulle consultazioni che sono state fatte, con link a mailing list/forum o pagine wiki di discussione
  • Quando la modifica è stata fatta, o con quale frequenza sarà ripetuta
  • Informazioni su come "chiamarsi fuori" (richiedere che i dati da me inseriti rimangano inalterati rispetto alla modifica in oggetto)
  • I bot approvati devono avere una pagina wiki con il nome del bot come titolo. Devono anche avere un nome utente con lo stesso nome, con chiari collgamenti tra nome utente e la pagina wiki.

Manda in esecuzione con prudenza

Dovresti:

  • Eseguire solo un piccolo numero di modifiche con un nuovo bot prima di fare la richiesta, e aspettare i feedback prima di procedere con modifiche più consistenti.
  • Assicurarti che stai operando sui dati più recenti. Assicurati di non sovrascrivere accidentalmente qualcosa che è stato appena modificato da qualcun altro, se stai usando un file planet precedente.
  • Assicurarti di avere tutti i dati di cui potresti aver bisogno nel caso dovessi annullare le tue modifiche se qualcosa andasse storto.
  • Pianificare attentamente i tuoi changeset. Se il tuo bot crea un changeset per ogni singola modifica, diventa molto difficile decifrare quello che è stato fatto. Lo stesso problema c'è se il tuo bot crea un unico changeset per un sacco di modifiche in tutto il pianeta. Modifiche raggruppate per piccole aree sono più facili da controllare per i mappatori (per es. "corretti i tag delle highway nella contea di Orange").
  • Assicurarti che ci sia un modo per identificare che una certa modifica è stata fatta dal tuo script. Puoi creare un account specifico per l'esecuzione dello script, o puoi usare un tag "source, "created_by", o "note" o similari.
  • Usare un tag "comment" al changeset che descriva le modifiche di quel changeset in modo chiaramente comprensibile. Devi anche aggiungere il tag mechanical=yes (o bot=yes), e mettere il link alla pagina wiki o alla pagina utente che documenta le modifiche nel tag description=* (per es. description=https://wiki.openstreetmap.org/wiki/Mechanical Edits/John Doe#Tag Fixup January 2013).
  • Fornire una soluzione per i mappatori che "si chiamano fuori" dalle tue modifiche, cioè se qualcuno ti contatta e ti chiede di smetterla di fare modifiche automatiche su elementi modificati da lui, devi soddisfare la richiesta, e devi modificare il tuo software o la tua procedura per lasciare in futuro quegli oggetti invariati.
  • Per modifiche molto grandi (centinaia di migliaia o più), controlla con gli amministratori (prova IRC) per assicurarti che le tue modifiche non interferiscano con altre operazioni degli amministratori di sistema, o controlla i grafici Munin per scoprire a che ora i server non sono troppo impegnati.

Risoluzione di controversie

E' sempre possibile che qualcuno sia scontento delle modifiche, anche dopo una discussione esaustiva. Sii preparato a questa situazione, e tratta tutte le lamentele in modo serio ed educato. Se hai seguito queste regole allora il tuo account non sarà bloccato non appena qualcuno si lamenta, ma potresti dover cambiare o sospendere quello che stai facendo se qualcuno avversa il tuo operato e/o i suoi effetti collaterali.

Le tue modifiche possono essere annullate anche se hai seguito queste regole; questo non garantisce che le tue modifiche saranno accettate. Il Data Working Group indagherà e agirà di conseguenza su problemi che non possono essere risolti seguendo la linea di condotta sopra descritta, e potrebbero sia bloccare immediatamente l'account sia mandare un messaggio di ammonimento (a seconda di quanto intensa sia l'attività di modifiche). Tutte le modifiche automatiche che non seguono queste regole sono passibili di essere velocemente annullate non appena sono scoperte. Nei casi dove le modifiche in violazione di queste regole sono così strettamente mescolate con modifiche "normali" da rendere difficile distinguerle, è possibile che l'annullamento delle modifiche problematiche causi anche danni collaterali alle modifiche "normali".

Vedi anche