How to Report Bugs in LibreOffice

From The Document Foundation Wiki
< QA
Jump to: navigation, search
This page is a translated version of the page QA/BugReport and the translation is 21% complete.

Outdated translations are marked like this.
Other languages:
العربية • ‎Deutsch • ‎Ελληνικά • ‎English • ‎español • ‎français • ‎galego • ‎italiano • ‎日本語 • ‎Nederlands • ‎português do Brasil • ‎русский • ‎Türkçe • ‎中文(中国大陆)‎ • ‎中文(简体)‎ • ‎中文(台灣)‎

Glad you made it here. You are about to make an important contribution to LibreOffice. A good bug report is very helpful for our developers. Below, you'll find some guidance to make this process easier.

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:

Class of Bugs Where to file the bug
LibreOffice Extensions With the extension author
TDF/LibreOffice Infrastructure (websites, mailing lists, etc.) Redmine
Building LibreOffice Developer mailing list
LibreOffice Unit Tests Developer mailing list

Prima di inviare un bug

Verificare che sia realmente un bug. La maggior parte delle volte, un bug è qualcosa che fa sì che il software si comporti in un modo che un utente ragionevole non vorrebbe che si comportasse. 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 in condizioni normali. Andando dietro le quinte, un bug può essere qualcosa che fa sì che il software impieghi molto più tempo e usa molte più risorse per fare cose di quanto dovrebbe.

Confirm that it really is a bug. Most of the time, a bug is something that makes the software behave in a way that a reasonable user would not want it to behave. This includes the software not doing what you want it to do, doing what you never asked it to do, or just plain crashing under normal use. Going behind the scenes, a bug may be something that causes the software to take a lot longer and use a lot more resources doing stuff than it should.

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 le app "molto" per familiarizzare con ciò che fanno normalmente.

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

Ma diciamo che quello che avete trovato sembra davvero un bug. Ecco cosa fare dopo:

  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 per l'esistenza di segnalazioni di bug simili:
    1. Andate a Componenti, e selezionate il componente (o il sottocomponente) appropriato.
    2. Se selezionate un componente: passate al sottocomponente appropriato, oppure l'Aiuto esteso nel caso non troviate il sottocomponente in quella pagina.
    3. Se selezionate l'Aiuto esteso: selezionate il sottocomponente appropriato, oppure dall'elenco [1] della lista se non trovate o non conoscete il sottocomponente appropriato.
    4. Se vedete una lista di bug con quel sottocomponente. Sul fondo della pagina, selezionate Modifica la ricerca. Qui, potete modificare la ricerca secondo le vostre necessità.
    5. Se trovate una segnalazione del bug che riguarda il vostro problema, potete contribuire. Se non trovate una segnalazione del bug relativo al vostro problema, presentate una nuova segnalazione del bug.
  3. Se il bug si presenta solo su Ubuntu oppure è legato alla stampa, andate #Maggiori informazioni.
  4. Dopo tutto ciò, se non trovate una segnalazione del bug relativo alla cosa, seguite le istruzioni in #Segnalare un bug.
    1. If you selected Extended Help: select the appropriate subcomponent, or the [1] at the bottom of the list if you did not find or do not know the appropriate subcomponent.
    2. You will see a list of bugs with that subcomponent. At the bottom of the page, select Edit Search. There, you can modify the search according to your needs.
    3. If you find a bug report that concerns your problem, you can contribute to it. If you don’t find a bug report that concerns your problem, file a new bug report.
  1. If the bug only occurs on Ubuntu or is related to printing, go to #More Information.
  2. After all that, if it does not look like there is a bug report about this issue, follow the instructions at #Submitting a bug.

Segnalare un bug

Presentate una segnalazione separata del bug per ciascun bug, anche se i sintomi dal punto vista utente sembrano identici. Problemi diversi con radici diverse che apparivano in diverse versioni di LibO potrebbero dover essere risolti da persone diverse, per versioni diverse e in momenti diversi. È impossibile rintracciarlo in una singola segnalazione di bug.

File a separate bug report for each bug you run into, even if the symptoms from a user’s point of view seem identical. Different problems with different roots that appeared in different LibO versions might have to be fixed by different people, for different versions, and at different times. It is impossible to track that in a single bug report.

Andate Bugzilla.

Accedi

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

If you are prompted to sign in, log in with your Bugzilla account.

Componente

In Componente, scegliete il componente.

In Component, choose the component.

Se non siete sicuri 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 più importanti da mettere in cima alla lista, date un'occhiata a "BugTriage".)

Se si tratta di un problema urgente (parti rotte, 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.

If there is a Sub-component section, select the subcomponent.

Se non sapete quale sia il sottocomponente appropriato, andate 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 Guida estesa 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 stai usando, seleziona 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 conosciuta come stabile.

Oggetto

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

Check in possibly related Bugs table on the bug-reporting page and additionally in the Duplicates Table to see whether the problem really has not been reported yet.

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

  • Non includere informazioni già note dai campi.
  • Includete i nomi dei sottocomponenti dai Componenti.
    • 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 blocca" o smette di rispondere ("si blocca"), aggiungete la parola "CRASH" al sommario, in modo che questi bug possano essere individuati e tracciati facilmente.
    • If the subcomponent can be confused with parts of a word (for example, UI is part of the word quit), surround the subcomponent with square brackets.
    • Use at most two subcomponents.
    • Use subcomponents exactly as they appear in the list, but you may integrate them into the subject line sentence like “WIKIHELP [UI] not available in all languages”.
  • Summarize the problem fairly precisely.
    • bad example: “File is broken”
    • better example: “Menu File > Save as not available (greyed out)”
  • Avoid short forms like “doesn’t” or “isn’t” to ease queries for strings in the Summary; instead, use the full form, such as “does not” or “is not”.
  • If the problem written in the report is that LibreOffice crashes or stops responding (“hangs”), add the word CRASH to the Summary, so that these bugs can be located and tracked easily.

Descrizione e allegati

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

In the Long Description or Description section, give a lengthier, factual description of the problem:

  • 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 e vuoto foglio elettronico di LibO, usate menu File > Apri (finestra di dialogo LibO) > scegliete tipo “documento di testo” > selezionate semplice documento 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.

  • Includere informazioni sulla localizzazione installata e utilizzata (lingua dell'interfaccia utente, linguaggio dei documenti) potrebbe essere utile.
  • Indicate se state usando un LibreOffice a 32-bit su un sistema a 64-bit (Linux).
  • Includere 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 fare in questo modo in Strumenti ▸ Opzionio ▸ Impostazioni lingua ▸ Lingua.
  • Potete rendere più utili le immagini della videata aggiungendo commenti e contrassegnando 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 esso.
  • Se allegate un documento campione che presenta il bug che state segnalando, ti 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 traccia di debug, utilizzate un testo facilmente riconoscibile, come AAAAAAAAAA a ZZZZZZZZZZ per un bug attivato da quel carattere.
  • È preferibile caricare gli allegati singolarmente. Tuttavia, se desiderate allegare più di una mezza dozzina di documenti, <! - (un kit di test completo, ad esempio) -> 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 ilPagina di caricamento sperimentale.
  • If you want to attach more than one screenshot, you should collect them all in one document (copy / paste to a LibreOffice Draw document) and attach as a PDF. Please add a short comment to each screenshot to tell what you want to demonstrate with it.
  • If you attach a sample document that exhibits the bug you are reporting, please make the document as minimal as possible. For example, for Writer bugs, the document should ideally have just a single paragraph. To make it easy to find the text from your document in debug tracing, use some very easily recognizable text, like AAAAAAAAAA ₂ ZZZZZZZZZZ for a bug that is triggered by that character.
  • It is preferable to upload attachments individually. However, if you want to attach more than half a dozen documents, create a .zip file containing all documents and attach that .zip.
  • If your attachment is too big to be attached in Bugzilla (bigger than 1 MB) you can use the Experimental upload page.

Stato

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

The only time you should change the status to NEW is, if someone already confirmed the bug elsewhere (Ask, mailing list, some forum). In these cases, provide a link to the discussion with the confirmation.

Invia

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

Click Submit, and your report will be added to the Bugzilla database.

Se Bugzilla sembra scoraggiante

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

If the Bugzilla bug tracking system seems daunting or too hard to understand, you should post your problem here:

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 in questo. Notate che segnalare problemi sui social media (Facebook, Twitter, G + ecc.) non è produttivo in generale poiché raramente porterà a una buona segnalazione di bug che termina con bugzilla (si veda anche:99 modi per rovinare un progetto open source, top 5).

Dopo aver inviato un bug

If nobody has reviewed your report within an appropriate time (24 hours for a critical bug, 14 days for an enhancement request), consider asking someone else to reproduce your bug report on the users@global.libreoffice.org mailing list or IRC channel #libreoffice connect via webchat.

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

  • Avoid posting “me too” comments which contain no additionally useful information.
    The exception to this is when you comment on a bug that has been UNCONFIRMED so far. In that case, please provide reproduction steps (or confirm the ones given by the original reporter) and move the issue to status NEW. Note that if there are no clear reproduction steps, the issue might quickly move back to NEEDINFO, so finding a good and simple reproduction scenario is essential.
  • Refrain from adding comments along the line of “we have 1000 seats here and only this bug prevents us from migrating”, as it contains no additional information relevant to QA or to the priority of the issue.

Aggiunta di commenti ai bug

  • Evitate di pubblicare "anche io" commenti che non contengono ulteriori informazioni utili.
    L'eccezione a questo è quando si commenta un bug che è stato finora UNCONFIRMED. In tal caso, fornire le fasi di riproduzione (o confermare quelle fornite dalla segnalazione originale) e spostare il problema sullo stato NEW. Notare che se non ci sono passaggi di riproduzione chiari, 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.
  • Contatti La Document Foundation vi aiuta se avete solo una piccola quantità di fondi e volete collaborare, coordinare o mettere in comune le vostre risorse con altri nella stessa situazione per finanziare correzioni o miglioramenti specifici.

Buone segnalazioni

Minimum requirements

  1. OS/LibreOffice version;
  2. enumerated reproducible steps;
  3. simple attachments where appropriate; and
  4. observed/expected results.

Richieste minime

  1. Vesrione del sistema operativo/LibreOffice;
  2. elencare i passi riproducibili;
  3. allegati semplici dove utile; e
  4. risultato osservato/aspettato.

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
  • tdf#85004 - Writer: Crash when clicking the Reminder icon on the Navigation toolbar
  • tdf#87907 - DIALOG: Page preview in print dialog refreshes when opening print details
  • tdf#74839 - EDITING: Position of connectors connected to a group aren't updated when editing group content

Esempi di segnalazioni meno buone

Reports can be less than ideal for a number of reasons. Below are some of the common problems:

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

Describing a bug report in paragraphs of text is one of the most common problems. Developers do not have the time to read paragraphs of text. Clear, succinct, enumerated steps are always better.

Paragrafi di testo

One report should only have a single bug in it. Grouping bugs, or listing a whole list of issues with a single document, is utterly unhelpful. In order to find developers to tackle issues, it is best to give them a single issue to focus on. They are unlikely to take on a bug that has multiple issues listed

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.

All bug reports should have at minimum:

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

Adding a lot of extra details that aren’t relevant is another common problem. Examples include:

Dettagli / passaggi mancanti

Tutte le segnalazioni di bug dovrebbero riportare un minimo:

Attachments should be as simple as possible. Take the time to prune your examples to the bare minimum. This helps tremendously in diagnosing problems.

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

Aggiungere informazioni superflue

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

  1. “questo è un blocco”;
  2. una lunga lista di motivi per cui è un blocco;
  3. “Non potete usare LibreOffice a causa di questo bug”;
  4. “LibreOffice fa schifo” (o qualsiasi variante); e
  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.

Do not assume contributors know what you’re talking about. Describe your steps clearly, each step of the way.

Ulteriori informazioni