Help:Style (Italiano)

Le seguenti convenzioni di stile sono volte a rendere gli articoli ordinati, ben organizzati e visivamente coerenti tra loro. Tutti i collaboratori di ArchWiki sono incoraggiati a seguirle nel modificare le pagine.

Articoli

Titolo

• Se l'argomento dell'articolo è comunemente conosciuto sia con il nome completo che con un acronimo, si preferisca usare il nome completo nel titolo dell'articolo. Evitare di includere nel titolo sia il nome completo che l'acronimo (ad esempio tra parentesi), ma piuttosto si crei un redirect per l'acronimo che reindirizzi alla pagina titolata con il nome completo.
• Si veda anche Help:Article naming guidelines.

Struttura

• Ordinare i vari elementi di un articolo come segue:

1. #Magic words (opzionali)
2. #Categorie
3. #Interlink
4. #Template di stato dell'articolo (opzionali)
5. #Articoli correlati (opzionale)
6. #Prefazione o introduzione
7. Tabella dei contenuti (automatica)
8. Sezioni specifiche dell'articolo

Magic words

• I behavior switch, e in generale tutte le magic word che modificano la maniera in cui è mostrato o si comporta un articolo senza aggiungere contenuto di per sé, devono essere aggiunte all'inizio del codice di ogni articolo.
  Questa regola si applica in particolare a {{DISPLAYTITLE:title}} e Template:Lowercase title, che fa uso del primo.

Categorie

• Ogni articolo dev'essere categorizzato in almeno una categoria tra quelle esistenti.
• Un articolo può appartenere a più di una categoria, ammesso che nessuna di esse sia contenuta, direttamente o indirettamente, in una delle altre categorie presenti.
• Le categorie devono essere specificate all'inizio del codice di ogni articolo, subito sotto le eventuali magic words.
  Nota: Questo metodo differisce da altri progetti MediaWiki come Wikipedia, i quali includono le categorie in fondo agli articoli.
• Non devono esserci righe vuote tra le categorie e la prima linea di testo (o gli interlink, se presenti), dato che introdurrebbero dello spazio bianco all'inizio dell'articolo.
• Vedere anche Recategorizing Pages.

Interlink

• Se l'articolo ha delle traduzioni nella wiki locale o in wiki di Arch Linux esterne, bisogna includere i relativi interlink subito sotto le categorie e sopra la prima linea di testo.
  Notare che effettivamente appariranno nell'apposita colonna alla sinistra della pagina.
• Non devono esserci righe vuote tra gli interlink e la prima linea di testo, dato che introdurrebbero dello spazio bianco all'inizio dell'articolo.
• Quando si aggiungono o modificano interlink, bisogna fare attenzione a ripetere tale azione per tutte le traduzioni dell'articolo già esistenti.
• Non aggiungere più di un interlink per ciascuna lingua in un articolo.
• Non aggiungere interlink per la medesima lingua dell'articolo.
• Gli interlink devono essere ordinati alfabeticamente secondo l'abbreviazione della lingua, non il nome locale, per cui ad esempio [[fi:Title]] viene prima di [[fr:Title]] nonostante "Suomi" verrebbe dopo "Français".
• Vedere anche Help:i18n e Aiuto:Interlink.

Template di stato dell'articolo

• I template di stato dell'articolo possono essere inclusi subito sotto le categorie (o gli interlink, se presenti) e subito sopra l'introduzione (o gli articoli correlati, se presenti).
• I template di stato dell'articolo possono anche essere usati all'interno delle sezioni, ove appropriato.
• I template di stato dell'articolo devono essere sempre accompagnati da qualche parola di spiegazione nell'apposito spazio (vedere gli esempi nelle varie pagine dei template), eventualmente aprendo anche una sezione nella pagina di discussione.

Articoli correlati

• Presenta una semplice lista di link ad articoli interni correlati.
• Opzionalmente incluso subito sotto le categorie (o gli interlink, o i template di stato dell'articolo, se presenti).
• Può essere composto solamente da Template:Related articles start (Italiano), Template:Related, Template:Related2 e Template:Related articles end. Leggere anche le linee guida nelle pagine di tali template.
• Usare la sezione "Altre risorse" per una lista più completa e dettagliata che includa anche descrizioni e link interwiki o esterni.

Prefazione o introduzione

• Descrive l'argomento dell'articolo.
  Piuttosto che parafrasare o scrivere la propria (magari troppo soggettiva) descrizione di un particolare software, si può usare la descrizione dell'autore originale, che di solito può essere trovata sulla pagina home o about del sito ufficiale del progetto, se esistente. Un esempio è MediaTomb.
• Inclusa subito sopra la prima sezione dell'articolo.
• Non creare esplicitamente una sezione ==Introduzione== o ==Prefazione==: lasciare invece che appaia sopra il primo titolo di sezione. Quando c'è un numero sufficiente di sezioni nell'articolo, tra la prefazione e la prima sezione viene mostrata automaticamente la tabella dei contenuti.
• Vedere anche Writing Article Introductions.

Titoli di sezione

• I livelli dei titoli di sezione devono cominciare dal secondo (), infatti il primo livello è riservato per i titoli degli articoli.
• Evitare di saltare livelli quando si creano sottosezioni, perciò una sottosezione di un livello 2 avrà un titolo di livello 3 e così via.
• I titoli di sezione usano le maiuscole come le normali frasi: Una nuova sezione e non Una Nuova Sezione.
• Evitare di usare link nei titoli, dato che creano una discontinuità di stile ed inoltre non sono facilmente individuabili. In genere il testo del link si può trovare anche nel contenuto della sezione, altrimenti è possibile usare semplici frasi del tipo Si veda anche My new page.
  Per lo stesso motivo, si eviti anche di usare qualunque altro tipo di markup (html o wiki), inclusi i #Template di formattazione del codice. Leggere anche Help:Style/Formatting and punctuation.
• Vedere anche Effective Use of Headers.

Linee vuote

• Evitare di inserire più linee vuote consecutive per aumentare lo spazio bianco tra paragrafi o sezioni.
• Si veda Help:Editing#Line breaks per maggiori informazioni.

Template di formattazione del codice

• Usare per rappresentare, nelle righe del testo, corte linee di codice, nomi di file, nomi di comandi, nomi di variabili e simili, ad esempio:
  Eseguire nella console.
• Usare per rappresentare in un blocco separato singole o multiple linee di codice (input o output della linea di comando e contenuto dei file), ad esempio:

$ sh ./hello_world.sh

Per corte linee di codice è anche ammesso iniziarle con uno spazio invece di usare (vedere Help:Editing (Italiano)).

• Usare quando si ha bisogno di rappresentare sia l'input che l'output della linea di comando, ad esempio:

• Quando si ha bisogno di rappresentare il contenuto di un file e si teme che possa essere difficile per i lettori capire a quale file si riferisca tale codice, è anche possibile usare {{hc|nomefile|contenuto}} per mostrare il nome del file nell'intestazione, ad esempio:

• Cosnultare anche Help:Template per maggiori informazioni e per risolvere i problemi legati ad alcuni caratteri nei template, come o |.

Testo da linea di comando

• Usare come prompt per comandi da utente normale; usare come prompt per comandi da root.
• La frase introduttiva per un comando dovrebbe in genere terminare con i .
• Preferire l'uso di invece di scrivere $ sudo command a meno che non sia strettamente necessario.
• Non presupporre che l'utente usi o un'altra applicazione per ottenere i permessi di root (ad esempio , ).
• è ridondante e dev'essere evitato. L'unica eccezione si ha quando sudo è invocato con l'opzione : in questo caso si può usare il prompt delle altre linee nello stesso blocco di comandi, o ricadere su .
• Non aggiungere commenti nella stessa cornice di un comando (ad esempio )
• Evitare di scrivere linee di codice eccessivamente lunghe: usare dei metodi per spezzare le linee quando possibile.

Richieste di modifica di file

• Non presupporre l'uso di specifici editor di testo (nano, vim, emacs, ...) nel richiedere modifiche a file di testo, a parte quando necessario.
• Non usare comandi impliciti per richiedere modifiche a file di testo, a meno che sia strettamente necessario. Ad esempio al posto di sarebbe meglio scrivere:

Aggiungere le seguenti linee a :

Tasti della tastiera

• Il modo standard per rappresentare tasti della tastiera negli articoli è usare istanze di Template:ic.
• I tasti delle lettere devono essere rappresentati in minuscolo: . Per rappresentare lettere maiuscole, usare Shift+a invece che o .
• La maniera corretta per rappresentare combinazioni di tasti è fare uso del simbolo , senza spazi addizionali a destra o sinistra, in una singola istanza del template: .
  Ctrl + c, +, sono rappresentazioni non conformi, pertanto dovrebbero essere evitate.
• I seguenti sono esempi standard per rappresentare alcuni tasti speciali:
  • (non )
  • (non o Control)
  • (non )
  • (non o )
  • Invio (non , o )
  • Esc (non o )
  • (non )
  • Ins (non o )
  • Canc (non o )

Pacchetti ufficiali

• Si prega di evitare di usare esempi di comandi di pacman per dare istruzioni per l'installazione di pacchetti ufficiali: questo è stato stabilito sia per semplicità (ogni utente di Arch dovrebbe conoscere l'articolo su pacman a memoria) sia per evitare errori come o eventuali discussioni senza fine come la scelta tra e . A maggior ragione non si deve suggerire l'uso di frontend o wrapper per pacman per installare pacchetti ufficiali.
  Si usi invece una frase simile alla seguente:
  Installare , disponibile nei repository ufficiali.
  Oppure, se il nome dell'applicazione è diverso da quello del pacchetto:
  MyApplication può essere installato con il pacchetto my-app-pkg, disponibile nei repository ufficiali.
  Le istruzioni per l'installazione di una lista di pacchetti potrebbero apparire come:
  Installare , e , disponibili nei repository ufficiali.
  È ovviamente consentito adattare la formulazione alle specifiche necessità di ciascun articolo.
• I link ai pacchetti menzionati sono obbligatori e dovrebbero essere creati usando Template:Pkg, ad esempio .
• Gli esempi riportati sopra fanno inoltre uso di un link implicito all'articolo di pacman (Italiano) (ad esempio [[pacman (Italiano)|Installare]] ...) ed uno a Official repositories (Italiano) (): il loro uso è raccomandato almeno per la prima occorrenza di una richiesta di installazione, specialmente negli articoli che hanno maggiore probabilità di essere consultati da principianti di Arch.
• Se il pacchetto è ospitato in core, extra o community, si eviti di fare riferimento al nome del repository, facilitando così la manutenzione dato che non è infrequente che un pacchetto sia spostato in un repository differente. Se però il pacchetto è ospitato in un repository ufficiale che non è abilitato di default (multilib, testing ecc.), è preferibile menzionarlo, usando una frase simile alla seguente:
  Installare , disponibile nel repository ufficiale multilib.

Pacchetti dell'AUR

• Si prega di evitare di usare esempi su come installare pacchetti dell'AUR, né con il metodo ufficiale né menzionando l'uso di un AUR helper: ogni utente che installa pacchetti non ufficiali deve aver letto l'articolo Arch User Repository (Italiano) ed essere cosciente di tutte le possibili conseguenze sul proprio sistema.
  Si usi invece una frase simile alla seguente:
  Installare , disponibile nell'Arch User Repository.
  È ovviamente consentito adattare la formulazione alle specifiche necessità di ciascun articolo, leggere la sezione sui #Pacchetti ufficiali per ulteriori esempi.
• I link ai pacchetti menzionati sono obbligatori e dovrebbero essere creati usando Template:AUR, ad esempio .
• È sempre necessario specificare che il pacchetto non è ufficiale, anche linkando all'articolo Arch User Repository (Italiano) o a uno dei suoi redirect, per esempio AUR (Italiano).

Repository non ufficiali

• Nel suggerire l'uso di un repository non ufficiale per installare un pacchetto precompilato, non fornire istruzioni su come abilitare il repository, ma assicurarsi che tale repository sia incluso in Unofficial user repositories e quindi semplicemente creare un link ad esso. Si prega inoltre di evitare di usare esempi di comandi di pacman. Ad esempio:

Installare package dal repository example.

Se il pacchetto è disponibile anche in AUR:

Installare dall'Arch User Repository o dal repository example.

Se il pacchetto è disponibile in AUR con un nome differente:

Installare dall'Arch User Repository o builtpackage dal repository example.

È consentito adattare la formulazione alle specifiche necessità di ciascun articolo.

• Il link a Unofficial user repositories è obbligatorio e deve puntare all'appropriata sezione del repository, ad esempio [[Unofficial User Repositories#example|example]].

Operazioni con i moduli del kernel

• Fornire esempi su come caricare, rimuovere, mettere in blacklist o eseguire una qualunque altra operazione di base con i moduli è una pratica deprecata: la formulazione standard prevede una lista dei moduli da aggiungere, eventualmente facendo notare dipendenze o conflitti con altri moduli, una descrizione delle azioni che devono essere eseguite e un link a Kernel modules (Italiano).

Operazioni con i demoni

• Fornire esempi su come abilitare (enable), avviare (start) o eseguire una qualunque altra operazione di base con i demoni è una pratica deprecata: la formulazione standard prevede una lista dei demoni da aggiungere, eventualmente facendo notare dipendenze o conflitti con altri demoni, una descrizione delle azioni che devono essere eseguite e un link a systemd (Italiano).

Template Nota, Attenzione, Suggerimento

• Template:Nota dovrebbe essere usato per informazioni che in qualche modo divergono da ciò che il lettore si aspetterebbe più naturalmente di trovare in una parte di un articolo. Questa definizione include anche note che danno informazioni più dettagliate su un particolare e che altrimenti sarebbero considerate un po' estranee all'articolo. Un altro esempio si ha quando è necessario esporre un annuncio temporaneo come per esempio il cambio di nome di un pacchetto.
  Una Nota può anche essere usata per sottolineare importanti informazioni che potrebbero essere facilmente trascurate da lettori non molto competenti sull'argomento.
• Template:Attenzione dovrebbe essere usato per descrivere procedure che potrebbero avere conseguenze negative come essere particolarmente difficili ad essere annullate o addirittura danneggiare il sistema. I template Attenzione dovrebbero generalmente indicare sia le varie possibili conseguenze negative, sia le condizioni a causa delle quali esse potrebbero verificarsi o al contrario essere evitate.
• Template:Suggerimento dovrebbe indicare un metodo o una procedura che potrebbe essere utile e portare beneficio per alcuni lettori, benché assolutamente non necessaria per completare l'operazione in esame, e pertanto tranquillamente trascurabile.
• Quando due o più template Nota, Attenzione o Suggerimento devono apparire uno dopo l'altro in un certo punto di un articolo, è preferibile raggruppare i loro contenuti in una lista dentro un unico template, evitando di mettere i template uno sopra l'altro, a meno che essi non siano per niente correlati uno con l'altro. Ad esempio:

Shell

• Non presupporre che l'utente stia usando una shell in particolare (ad esempio Bash), tranne quando effettivamente necessario: cercare di essere il più possibile neutrale riguardo alle shell nello scrivere o editare gli articoli.

Metafora dell'ipertesto

• Cercare di creare link reciproci tra il proprio articolo e quanti più altri possibile, utilizzando le varie parole-chiave nel testo.
• Per i termini tecnici come chiamata di sistema che non sono trattati in nessun articolo dell'ArchWiki, creare un link alla relativa pagina di Wikipedia.
• Nel creare link ad altri articoli della wiki, non usare gli URL completi, ma sfruttare la speciale sintassi per i link interni: . Questo metodo permetterà inoltre al software wiki di tenere traccia dei link interni, facilitando così la manutenzione.
  Leggere Help:Editing (Italiano)#Collegamenti per informazioni più dettagliate e usi più avanzati della sintassi dei link interni.
• Eccetto in rari casi, non si dovrebbe lasciare un articolo senza che questo fornisca link a qualche altro, né si dovrebbero creare pagine orfane, cioè articoli che non sono linkati da nessun'altra pagina.
• Prima di scrivere una procedura specifica in un articolo, o descrivere qualcosa in particolare, controllare sempre che non esista già una pagina che tratta quella parte in dettaglio: in quel caso, creare un collegamento a quell'articolo invece di duplicare il suo contenuto.
• Se la documentazione ufficiale per l'argomento del proprio articolo è ben scritta e aggiornata, preferire scrivere solamente adattamenti specifici per Arch, e linkare alla documentazione ufficiale per le informazioni generiche.
• Non usare link interwiki per collegamenti alle pagine locali nella stessa lingua dell'articolo editato, infatti non sarebbero mostrati nelle pagine Special:WhatLinksHere. Ad esempio usare in un articolo in Italiano è sbagliato, mentre è corretto.
  Usare questo tipo di link tra lingue differenti è invece accettabile, dato che renderebbe più facile spostare gli articoli su una wiki esterna nel caso questa sia creata.
  Infine, notare la differenza di questo tipo di link con gli #Interlink, i quali non hanno i all'inizio.

Stile del codice

• Nell'aggiungere comandi o script, usare uno stile di codice coerente per tutto l'articolo, eventualmente anche riferendosi ad altri articoli, specialmente se ce ne sono di correlati. Se disponibili, rispettare le regole di stile ufficiali o più diffuse per il linguaggio utilizzato.
• Evitare funzionalità obsolete del linguaggio di programmazione/scripting che si sta usando: ad esempio usare la sintassi $() per la sostituzione dei comandi nella shell invece della sintassi .

Versioni del kernel supportate

• Non rimuovere note o adattamenti relativi a versioni del kernel maggiori o uguali alla versione minima tra l'attuale e il kernel sulla più recente immagine d'installazione.

Sezioni "Trucchi e consigli"

• Suggerimenti avanzati o esempi dell'utilizzo del software.
• Il titolo standard è Trucchi e consigli.
• I vari trucchi e consigli devono essere organizzati in sottosezioni.

Sezioni "Risoluzione di problemi"

• Domande frequenti riguardo al software, o soluzioni a problemi comuni (confrontare con #Sezioni "Problemi noti").
• Il titolo standard è Risoluzione di problemi; usare l'Inglese Troubleshooting non è considerato conforme a queste linee-guida.
• È anche possibile riportare soluzioni temporanee per bug conosciuti, ma in tal caso è fortemente preferibile fornire un link al bug report, e nel caso questo non esista ancora si consiglia di crearlo, in maniera da aumentare le possibilità che il bug venga corretto in maniera appropriata.
  Linkare a un bug report porta grandi benefici sia ai lettori che a coloro che mantengono l'articolo:
  • Per i lettori, la Wiki non è un vicolo cieco: viene invece data loro la possibilità di trovare maggiori informazioni, più vicine alla fonte, che magari potrebbero non aver trovato con i propri metodi di ricerca.
  • Per i redattori della Wiki, viene resa più facile la manutenzione riducendo gli sforzi necessari per controllare se il bug riportato è stato risolto nel frattempo; questo può anche dare modo ad un lettore di aggiornare autonomamente l'articolo nel caso trovi informazioni più recenti nel bug report.

Sezioni "Problemi noti"

• Elencano bug conosciuti o problemi di utilizzo per cui ancora non esiste una soluzione (confrontare con #Sezioni "Risoluzione di problemi").
• Il titolo standard è Problemi noti.
• Se esiste un bug report per il problema, è fortemente preferibile includere un link ad esso; nel caso non esista, bisognerebbe provvedere a riportarlo, in maniera da aumentare le probabilità che il bug venga corretto.

Sezioni "Altre risorse"

• Una lista di link a pagine di riferimento e fonti per informazioni addizionali.
• Dovrebbe essere una lista in cui ogni voce comincia con .
• Il titolo standard è Altre risorse, è meglio evitare altri titoli simili come Link esterni, Vedere anche ecc.

Contenuti non ammessi

• Si prega di non aggiungere la propria firma agli articoli, né di ringraziare o citare gli autori di un articolo: l'ArchWiki è un'opera di tutta la comunità, e la cronologia di ogni articolo è sufficiente per riconoscere i meriti di coloro che vi hanno contribuito.
  Ciononostante, è buona norma riportare le fonti usate per scrivere un articolo: a questo scopo è possibile usare la sezione "Altre risorse".
• Il caricamento dei file è disabilitato per gli utenti normali, e non è ammesso includere negli articoli le immagini esistenti. In alternativa è possibile includere collegamenti a immagini o gallery esterne, e se c'è bisogno di disegnare semplici schemi è possibile usare un editor ASCII come Asciiflow. Giustificazione:
  • Manutenzione: Arch è rolling release, e le immagini renderebbero molto più complicato l'aggiornamento degli articoli.
  • Necessità: Arch non sviluppa né mantiene alcuna applicazione con interfaccia grafica, per cui non è necessario mostrare alcuno screenshot.
  • Moderazione: il caricamento libero di immagini richiederebbe di spendere del tempo per rimuovere immagini sovradimensionate o inappropriate.
  • Accessibilità: supporto per connessioni lente, browser testuali, screen reader e simili.
  • Efficienza: le immagini sprecano banda della connessione dei server e spazio su disco.
  • Semplicità: gli articoli senza immagini appaiono più semplici e ordinati.

Registro linguistico

• Gli articoli devono essere scritti mantenendo un linguaggio formale, professionale e conciso.
• Ricordarsi di non dare risposta solo al come, ma anche al perché. Le spiegazioni devono sempre cercare di insegnare qualcosa invece di fornire solamente istruzioni.
• Evitare di rivolgersi al lettore in seconda persona ("installa/installate questo programma", "apri/aprite il tuo/vostro file manager" etc.). In alternativa è consigliato usare forme infinite ("installare questo programma", "aprire il proprio file manager"), impersonali ("si installi questo programma", "si apra il proprio file manager") o passive ("dev'essere installato questo programma", "dev'essere aperto il proprio file manager").
• Evitare abbreviazioni non necessarie: ad esempio invece di "repo," "distro," e "config," preferire "repository," "distribuzione," e "configurazione."
• Scrivere obiettivamente: non includere commenti personali negli articoli, usare le pagine di discussione per tale scopo. In generale, non scrivere in prima persona.

Suggerimento: Gli utenti impegnati nella traduzione di articoli in Italiano potrebbero essere interessati a leggere anche ArchWiki Translation Team (Italiano)#Linee guida.

Pagine di discussione

• Aggiungere le nuove discussioni in fondo alle pagine di discussione, con un titolo di sezione appropriato. A questo scopo è anche possibile usare la targhetta sul bordo superiore di ogni pagina di discussione.
• Indentare le proprie risposte utilizzando sequenze di all'inizio di ogni linea di testo.
• Non editare i propri post se qualcuno ha già replicato, altrimenti si farà perdere il filo della discussione rendendo più difficile per gli altri dare ulteriori risposte. È solamente consentito marcare con una linea parole o frasi (usando i tag ), ma la relativa spiegazione dev'essere fornita con un normale post.
• Terminare sempre i propri interventi con la firma dell'utente ().
• Le pagine di discussione non possono essere categorizzate.
• Bisognerebbe ricordarsi di marcare con una linea i titoli delle discussioni terminate, usando i tag .
  Le discussioni terminate saranno cancellate qualche tempo dopo essere state marcate.
• Leggere anche Help:Editing (Italiano)#Pagine di discussione.

Pagine delle categorie

• Ogni categoria dev'essere a sua volta adeguatamente categorizzata sotto almeno una categoria-madre, escluse le categorie di base.
  Le categorie di base sono Category:DeveloperWiki, [[:Category:Languages] e Category:Sandbox.
• Una categoria può essere categorizzata sotto più di una categoria-madre, ammesso che nessuna di queste sia a sua volta categoria-madre (o in generale "antenato") di una delle altre.
• Evitare relazioni circolari: due categorie non possono essere "antenati" reciproci.
• Non categorizzare una categoria sotto sé stessa (categoria auto-categorizzata).
• Le categorie devono essere incluse in cima al testo sorgente di ogni pagina di categoria.
• Le categorie non possono fare redirezioni.

Pagine di redirezione

• Le pagine di redirezione devono contenere solamente il codice per la redirezione, niente di più.
• Redirigere solamente agli articoli interni; non usare redirezioni con link interwiki.

Pagine dei template

• Leggere Help:Template.

Pagine degli utenti

• Le pagine nel namespace User non possono essere categorizzate.
• Le pagine nel namespace User possono essere linkate solamente da altre pagine nei namespace User o talk, a meno che sia stata fornita autorizzazione dagli Amministratori per fare diversamente.

Regole generali

Oggetto

• Le modifiche fatte ogni giorno agli articoli sono coraggiosamente controllate da pochi appassionati volontari, che è necessario aiutare ricordandosi di riempire sempre il campo dell'"Oggetto" con una spiegazione per ogni edit.
  • Se la modifica è minore, ad esempio correzioni ortografiche o grammaticali o la semplice riformulazione di una frase, una breve descrizione della propria modifica è perfettamente sufficiente.
  • Se si sta effettuando una modifica rilevante, ad esempio l'aggiunta, spostamento, modifica o rimozione di contenuti, oltre a fare un riassunto della modifica è necessario spiegare il motivo per cui è stata fatta, magari fornendo un link alla relativa discussione sulla wiki o ad un thread sul forum, se esistente.
  • Non è necessario fornire spiegazioni per le modifiche alle pagine di discussione, infatti il motivo dovrebbe essere comunque evidente.
    Quando però si rimuovono discussioni che erano già state chiuse, una piccola giustificazione è richiesta (ad esempio "discussione chiusa", "risolto" ecc.) ed includere anche il titolo della discussione medesima potrebbe aiutare a ritrovarla nella cronologia nel caso ci sia bisogno di riaprirla in futuro.

• Nell'effettuare modifiche rilevanti ad uno o più articoli, è bene cercare di dividere il proprio lavoro in più modifiche separate, basandosi sui vari passi logici necessari per completare l'operazione.
  Specialmente quando si spostano intere sezioni (sia nello stesso articolo che tra articoli differenti), è bene evitare di modificarne il contenuto nel medesimo edit, altrimenti si renderà più difficile controllarne il conseguente diff.

Tag HTML

• L'uso di tag HTML è generalmente da evitare: meglio preferire l'uso del markup della wiki o i template quando possibile: a tal proposito leggere Help:Editing (Italiano) e gli articoli correlati.
• Quando si è tentati di usare , usare sempre al suo posto. Invece di usare o , usare sempre .
• Evitare in particolare i commenti HTML (<!-- commento -->): è molto probabile che una nota aggiunta in un commento HTML possa essere mostrata esplicitamente nella pagina di discussione dell'articolo.
  Valutare se aggiungere un template di stato dell'articolo appropriato al posto del commento.
• Usare solo quando necessario: per cominciare un nuovo paragrafo o spezzare una linea basta inserire una linea vuota subito sotto.
  Le più comuni eccezioni a questa regola si hanno quando è necessario spezzare una linea in una voce di una lista, e non è possibile usare una sotto-voce, oppure dentro un template, e non è possibile usare una lista.