Segnalazione dei bug

From The Document Foundation Wiki
< QA
Jump to navigation Jump to search
This page is a translated version of the page QA/BugReport and the translation is 100% complete.
Other languages:
Bahasa Indonesia • ‎Deutsch • ‎English • ‎Nederlands • ‎Türkçe • ‎dansk • ‎español • ‎français • ‎galego • ‎italiano • ‎português do Brasil • ‎čeština • ‎Ελληνικά • ‎русский • ‎العربية • ‎فارسی • ‎中文(中国大陆)‎ • ‎中文(台灣)‎ • ‎日本語 • ‎한국어

Siamo lieti che siate arrivati qui. State per fornire un contributo importante a LibreOffice. Una segnalazione di bug ben fatta è molto utile ai nostri programmatori. Di seguito troverete alcune linee guida che vi semplificheranno questo processo.

Non tutti i bug passano per Bugzilla

Tutti i cani dovrebbero andare in paradiso⁠Wikipedia logo v3.svg, ma qualche segnalazione di bug dovrebbe essere veicolata al di fuori di Bugzilla. Queste includono:

Categoria di bug Dove segnalare il bug
Estensioni di LibreOffice All'autore dell'estensione
Infrastruttura di TDF/LibreOffice (sito web, mailing list, ecc.) Redmine
Compilazione di LibreOffice Mailing list degli sviluppatori
Unità di test di LibreOffice Mailing list degli sviluppatori

Prima di inviare un bug

Verificate che sia realmente un bug. La maggior parte delle volte, un bug è qualcosa che fa sì che il software abbia un comportamento che ragionevolmente un utente non vorrebbe avesse. Questo include il software che non fa quello che desideriate che faccia, che fa quello che non avete mai chiesto, o semplicemente che si chiude inaspettatamente in condizioni normali. Andando dietro le quinte, un bug può essere qualcosa che fa sì che il software, per fare le cose, impieghi molto più tempo e risorse di quanto dovrebbe.

Alcuni problemi potrebbero effettivamente essere il risultato di un profilo utente corrotto. Problemi con OpenGL e OpenCL sono solitamente bug validi. È molto utile se controllate le impostazioni OpenGL e OpenCL prima di scrivere la segnalazione del bug.

Ad un certo punto, quelli che sembrano bug sono in realtà più simili alle richieste di funzionalità, in cui sappiamo come il software dovrebbe funzionare in un mondo ideale, anche se la funzione che vogliamo non è ancora stata creata. Fortunatamente, non dovete preoccuparvi più di tanto di separare i bug dalle richieste di funzionalità. Se si tratta di qualcosa che interferisce con l'uso normale e valido dell'applicazione, segnalatelo come un bug.

Aiuta molto se sapete come orientarvi in LibreOffice, quindi avete una buona idea di cosa sia "normale, valido". Non volete passare molto tempo a segnalare ciò che pensate sia bug quando il problema è che non si sa ancora come utilizzare una determinata funzione. Prendete in considerazione la lettura della documentazione per l'utente e usate "molto" le app per familiarizzare con ciò che fanno normalmente.

Se conoscete LibreOffice abbastanza bene e vi imbattete in qualcosa che potrebbe essere un bug, ma anche solo qualcosa che non capite, potete postare una domanda sulla Mailing list degli utenti di LibreOffice o sul portale Ask di LibreOffice.

Ma supponiamo che quello che avete trovato sembri essere davvero un bug. Ecco cosa fare:

  1. Prendete note quindi non dimenticatevi di cosa stava succedendo nel momento in cui il bug è apparso. Cosa stavate facendo, cosa vi aspettavate che succedesse e che cosa è realmente accaduto? Come sapete che c'era qualcosa di sbagliato? Potete riprodurre il comportamento errato?
  2. Cercate l'esistenza di segnalazioni di bug simili:
    1. Andate a Componenti, e selezionate il componente (o il sottocomponente) appropriato.
    2. Se avete selezionato un componente: passate al sottocomponente appropriato, oppure all'Aiuto esteso nel caso in cui, in quella pagina, non troviate il sottocomponente.
    3. Se selezionate l'Aiuto esteso: selezionate il sottocomponente appropriato, oppure, se non lo trovate o non lo conoscete, l'[1] in fondo all'elenco.
    4. Se vedete un elenco di bug relativi a quel sottocomponente. In fondo alla pagina, selezionate Modifica la ricerca. Qui, potete modificare la ricerca secondo le vostre necessità.
    5. Se trovate una segnalazione di bug relativa al vostro problema, potete contribuire. Se invece non ne trovate una che riguardi il vostro problema, presentate una nuova segnalazione di bug.
  3. Se il bug si presenta solo su Ubuntu oppure è legato alla stampa, andate a #Maggiori informazioni.
  4. Se dopo tutto ciò, non trovate una segnalazione di bug relativa al problema, seguite le istruzioni in #Segnalare un bug.

Segnalare un bug

Presentate una specifica segnalazione per ciascun bug, anche se i sintomi dal punto vista dell'utente sembrano identici. Problemi diversi, con radici diverse, comparsi in diverse versioni di LibO, potrebbero dover essere risolti da persone diverse, per versioni diverse e in momenti diversi. È impossibile rintracciarli in una singola segnalazione di bug.

Andate a Bugzilla.

Accedi

Se vi viene chiesto di autenticarvi, accedete con il vostro account Bugzilla.

Componente

In Componente, scegliete il componente.

Se non siete sicuri di quale sia il componente che genera il problema, scegliete il componente LibreOffice. Qualcuno esaminerà la segnalazione di bug in un secondo momento e sceglierà un componente più preciso. (Per maggiori informazioni riguardo lo smistamento, che riesamina i bug per valutare quali sono i più importanti, da mettere in cima alla lista, date un'occhiata a "BugTriage".)

Se si tratta di un problema urgente (parti non funzionanti, regressione, ecc.) e siete utenti esperti che conoscono il team di sviluppo, potete assegnare la segnalazione di bug a uno degli sviluppatori elencati sulla pagina FindTheExpert.

Dettagli

Se esiste una sezione Sotto-componente, selezionate il sottocomponente.

Se non sapete quale sia il sottocomponente appropriato, andate in Componenti. Dalla pagina, fate clic sul componente appropriato. Leggete le descrizioni di tutti i sottocomponenti sulla pagina di quel componente. Se non vedete un sottocomponente adatto, fate clic su Aiuto esteso e leggete le descrizioni dei sottocomponenti in quella pagina.

Scegliete la versione dell'applicazione in cui è apparso il bug. Per verificare quale versione di LibreOffice state usando, selezionate Aiuto ▸ Informazioni su LibreOffice

In Sistema operativo o SO, scegliete il sistema operativo del computer che stavate usando quando avete incontrato il bug.

Se c'è una sezione Hardware, compilatela.

Se esiste una sezione Gravità, ignoratela a meno che non abbiate esperienza. Selezionando Blocker non si risolverà il bug più velocemente. Se desiderate conoscere le definizioni degli stessi nella sezione Gravità, si veda questa tabella.

Potete ignorare la sezione ultima versione funzionante conosciuta.

Oggetto

Controllate nella tabella "Possibili bug correlati" nella pagina di segnalazione dei bug e in aggiunta nella Tabella dei duplicati per vedere se il problema non è stato ancora segnalato.

Nella sezione "Oggetto" (nota anche come Riepilogo):

  • Non includere informazioni già note dai campi.
    • Rendete maiuscoli i sottocomponenti.
    • Se il sottocomponente può essere confuso con parti di una parola (ad esempio, l'interfaccia utente UI è parte della parola q ui t), racchiudete il sottocomponente con parentesi quadre.
    • Utilizzate al massimo due sottocomponenti.
    • Utilizzate i sottocomponenti esattamente come appaiono nell'elenco, ma potete integrarli nella frase della riga dell'oggetto come “WIKIHELP [UI] non disponibile in tutte le lingue”.
  • Riassumete il problema in modo abbastanza preciso.
    • esempio errato: “File è interrotto”
    • esempio migliore: “Menu File > Salva come non disponibile (in grigio)”
  • Evitate forme abbreviate tipo “doesn’t” o “isn’t” per semplificare la ricerca nel sommario; usate invece forme complete, come “does not” o “is not”.
  • Se il problema scritto nel rapporto è che LibreOffice "si interrompe" o smette di rispondere ("si blocca"), aggiungete la parola "CRASH" al sommario, in modo che questi bug possano essere individuati e tracciati facilmente.

Descrizione e allegati

Nella sezione Descrizione lunga o Descrizione, fornite una descrizione più dettagliata del problema:

  • elencate i passi per riprodurre il bug;
  • usate una lista numerata; e
  • indicate il metodo esatto per farlo accadere. Per esempio, invece di scrivere “Aprite un documento”, scrivete piuttosto “In un nuovo foglio elettronico vuoto di LibO, usate menu File > Apri (finestra di dialogo LibO) > scegliete tipo “documento di testo” > selezionate il documento di esempio allegato > fate doppio clic”.

Se state usando un LibreOffice pre-compilato su Linux, elencate le esatte versioni dei pacchetti di LibreOffice nel vostro sistema di gestione dei pacchetti. Se state usando Windows, elencate il nome esatto del programma di installazione e da dove è stato scaricato.

  • Potrebbe essere utile includere informazioni sulla localizzazione installata e utilizzata (lingua dell'interfaccia utente, linguaggio dei documenti).
  • Indicate se state usando un LibreOffice a 32-bit su un sistema a 64-bit (Linux).
  • Includete l'origine del pacchetto se non è la build ufficiale di LibreOffice.

Scrivete il comportamento previsto e il comportamento effettivo.

Potete includere un allegato, come una immagine della videata o un documento di esempio. Il modo tipico per avere una immagine della videata è premere il pulsante "Stamp" sulla tastiera. A seconda del sistema operativo, potrebbe essere necessario aprire un'applicazione di modifica delle immagini (come Paint su Windows) e fare Modifica - Incolla in esso.

  • Se create immagini della videata, cambiate la lingua in inglese prima di crearle. Potete farlo in Strumenti ▸ Opzionio ▸ Impostazioni lingua ▸ Lingua.
  • Potete rendere più utili le immagini della videata aggiungendo commenti ed evidenziando le aree rilevanti con LibreOffice Draw.
  • Se volete allegare più di una immagine, dovreste raccoglierle tutte in un documento (copia / incolla su un documento di LibreOffice Draw) e allegarli come PDF. Aggiungete un breve commento ad ogni schermata per dire cosa volete dimostrare con questa.
  • Se allegate un documento campione che presenta il bug che state segnalando, vi preghiamo di rendere il documento il più minimale possibile. Ad esempio, per i bug di Writer, il documento dovrebbe idealmente avere un solo paragrafo. Per semplificare la ricerca del testo del documento in fase di debug, utilizzate un testo facilmente riconoscibile, come AAAAAAAAAA ₂ ZZZZZZZZZZ per un bug attivato da quel carattere.
  • È preferibile caricare gli allegati singolarmente. Tuttavia, se desiderate allegare più di una mezza dozzina di documenti, create un file .zip contenente tutti i documenti e allegate tale .zip.
  • Se l'allegato è troppo grande per essere allegato in Bugzilla (più grande di 1 MB) potete usare la Pagina sperimentale di caricamento.

Stato

L'unico caso in cui dovreste cambiare lo stato in NUOVO è, se qualcuno ha già confermato il bug altrove (Ask, mailing list, alcuni forum). In questi casi, fornite un collegamento alla discussione con la conferma.

Invia

Fate clic su "Invia" e il rapporto verrà aggiunto al database di Bugzilla.

Se Bugzilla sembra scoraggiante

Se il sistema di tracciamento dei bug di Bugzilla vi sembra scoraggiante o troppo difficile da capire, dovreste pubblicare il vostro problema qui:

Anche se pubblicate il vostro problema su quei canali, il vostro obiettivo dovrebbe essere quello di ottenere una buona segnalazione di bug su bugzilla. Questi canali potrebbero aiutarvi a farlo. Notate che segnalare problemi sui social media (Facebook, Twitter, ecc.) in genere non è produttivo, poiché raramente ciò porterà a una buona segnalazione di bug che finisca su bugzilla (si veda anche:99 modi per rovinare un progetto open source, top 5).

Dopo aver inviato un bug

Se nessuno ha esaminato la vostra segnalazione entro un tempo adeguato (24 ore per un bug critico, 14 giorni per una richiesta di miglioramento), considerate la possibilità di chiedere a qualcun altro sulla mailing list users@global.libreoffice.org, o su canale IRC #libreoffice IRC://, di riprodurre la vostra segnalazione di bug.

Aggiunta di commenti ai bug

  • Evitate di pubblicare dei commenti tipo "anche io", che non contengono ulteriori informazioni utili.
    L'eccezione a questo è quando si commenta un bug che finora è rimasto UNCONFIRMED. In tal caso, fornire le fasi di riproduzione (o confermare quelle fornite dalla segnalazione originale) e spostare il problema sullo stato NEW. Notate che se non ci sono passaggi chiari per riprodurlo, il problema potrebbe tornare rapidamente a NEEDINFO, quindi è essenziale trovare uno scenario di riproduzione buono e semplice.
  • Evitate di aggiungere commenti sulla riga “Abbiamo 1000 postazioni qui e solo questo bug ci impedisce di migrare”, poiché non contiene informazioni aggiuntive rilevanti per il QA o per la priorità del problema.

LibreOffice è OpenSource e il vostro aiuto nel risolvere problemi rilevanti per la vostra situazione particolare è il benvenuto. Potete:

  • Impiegare e/o insegnare ai vostri sviluppatori a lavorare su LibreOffice. Saremo felici di guidarli: si vedano le pagine degli sviluppatori.
  • Finanziare individui o aziende per lavorare su problemi specifici - si veda l'elenco di sviluppatori certificati.
  • Contattate la Document Foundation per farvi aiuta nel caso in cui abbiate solo una piccola quantità di fondi e vogliate collaborare, coordinare o mettere in comune le vostre risorse con altri nella stessa situazione per finanziare correzioni o miglioramenti specifici.

Buone segnalazioni

Requisiti minimi

  1. Versione del sistema operativo/LibreOffice;
  2. elencazione dei passi riproducibili;
  3. allegati semplici se utili;
  4. risultati osservati/attesi.

Buoni esempi

  • tdf#85004 - Writer: arresto anomalo quando si fa clic sull'icona Promemoria sulla barra degli strumenti di navigazione
  • tdf#87907 - DIALOG: L'anteprima della pagina nella finestra di stampa si aggiorna all'apertura dei dettagli di stampa
  • tdf#74839 - EDITING: La posizione dei connettori collegati a un gruppo non viene aggiornata quando si modifica il contenuto del gruppo

Esempi di segnalazioni meno buone

Le segnalazioni possono non essere ideali per una serie di motivi. Di seguito alcuni dei problemi più comuni:

Paragrafi di testo

Descrivere una segnalazione di bug in paragrafi di testo è uno dei problemi più comuni. Gli sviluppatori non hanno il tempo di leggere i paragrafi di testo. I passi chiari, concisi e enumerati sono sempre migliori.

Una segnalzione, cinque bug

Una segnalazione dovrebbe contenere solo un singolo bug. Raggruppare bug o elencare un intero elenco di problemi con un singolo documento è assolutamente inutile. Per trovare sviluppatori che affrontino i problemi, è meglio dare loro un unico problema su cui concentrarsi. È improbabile che vi imbattiate in un bug che presenta più problemi elencati

Dettagli / passaggi mancanti

Tutte le segnalazioni di bug dovrebbero riportare come minimo:

  1. il sistema operativo e la versione di LibreOffice;
  2. passi chiaramente riproducibili;
  3. il risultato che vi aspettate;
  4. il risultato ottenuto;
  5. un semplice allegato, quando utile.

Aggiunta di informazioni superflue

Aggiungere molti dettagli extra che non sono rilevanti è un altro problema comune. Gli esempi includono:

  1. “questo è bloccante”;
  2. una lunga lista di motivi per cui è bloccante;
  3. “Non potete usare LibreOffice a causa di questo bug”;
  4. “LibreOffice fa schifo” (o qualsiasi variante);
  5. passerò ad usare la concorrenza se non lo correggete.

Allegati complessi

Gli allegati dovrebbero essere il più semplici possibile. Prendetevi il ​​tempo necessario per ridurre gli esempi al minimo indispensabile. Questo aiuta enormemente a diagnosticare i problemi.

Supporre che gli sviluppatori sappiano tutto

Non date per scontato che gli sviluppatori sappiano di cosa state parlando. Descrivete chiaramente i passi, in ogni fase del percorso.

Ulteriori informazioni