How to Report Bugs in LibreOffice

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 44% complete.
Other languages:
Bahasa Indonesia • ‎Deutsch • ‎English • ‎Nederlands • ‎Türkçe • ‎español • ‎français • ‎galego • ‎italiano • ‎português do Brasil • ‎čeština • ‎Ελληνικά • ‎русский • ‎العربية • ‎中文(中国大陆)‎ • ‎中文(台灣)‎ • ‎中文(简体)‎ • ‎日本語 • ‎한국어

Mooi dat je ons hebt gevonden. Je staat op het punt om een belangrijke bijdrage aan LibreOffice te leveren. Een goed bug-verslag is heel nuttig voor onze ontwikkelaars. Hieronder vind je enkele aanwijzingen om dat eenvoudiger te maken.

Niet alle bugrapports gaan naar Bugzilla

Sommige bugs kun je niet rapporteren bij Bugzilla:

Soort bug Waar je de bug moet melden
LibreOffice-extensies Bij de maker van de extensie
Bij de infrastructuur van TDF/LibreOffice (websites, mailing lists, etc.) Redmine
LibreOffice compileren Developer mailing list
Testen van LibreOffice Units Developer mailing list

Voordat je een bug meldt

Verzeker je ervan dat het echt een bug is. Meestal is een bug iets dat ervoor zorgt dat de software werkt op een manier die een redelijke gebruiker niet wil. Zoals dat de software niet doet wat je wil dat hij doet, dat hij iets doet waar je niet om gevraagd hebt of dat het programma bij normaal gebruik vastloopt of zomaar stopt. Achter de schermen kan een bug er ook voor zorgen dat de software er veel langer over doet en veel meer hulpbronnen gebruikt dan nodig is om zijn werk te doen.

Sommige fouten kunnen eigenlijk het resultaat zijn van een beschadigd gebruikersprofiel. Problemen met OpenGL en OpenCL zijn gewoonlijk geldige bugs. Het helpt enorm als je de effecten van de instellingen voor OpenGL en OpenCL controleert voordat je je bugrapport schrijft.

Op een gegeven moment lijken de bugmeldingen meer op feature requests. We weten hoe de software zou moeten werken in een ideale wereld, ook al is de functie die we willen nog niet ontwikkeld. Gelukkig hoef je je niet zoveel zorgen te maken over het onderscheiden van bugs en feature requests. Als het iets is dat het normale, geldige gebruik van de applicatie in de weg staat, rapporteer het dan als een bug.

Het scheelt enorm als je LibreOffice door en door kent, zodat je een goed gevoel hebt van wat "normaal, geldig gebruik" is. Je moet niet heel veel tijd gaan besteden aan het melden van wat je voor bugs aanziet, terwijl het echte probleem is dat je nog niet weet hoe je een bepaalde functie moet gebruiken. Overweeg om eerst de [1] te lezen en de apps "veel" te gebruiken, zodat je vertrouwd raakt met wat ze gewoonlijk doen.

Als je redelijk vertrouwd bent met LibreOffice en op iets stuit dat op een bug lijkt maar dat ook iets kan zijn dat je niet begrijpt, kun je een vraag stellen op LibreOffice Users Mailing List (Engelstalig), Nederlandse Mailinglijsten of op Ask LibreOffice.

Maar stel dat je iets hebt gevonden dat echt op een bug lijkt. Doe dan vervolgens:

  1. Maak aantekeningen zodat je niet vergeet wat er gebeurde rond de tijd dat de bug verscheen. Wat was je aan het doen, wat verwachtte je dat er zou gebeuren, en wat gebeurde er echt? Hoe wist je dat er iets fout zat? Kun je het slechte gedrag reproduceren?
  2. Controleer of er soortgelijke, bestaande bugrapporten zijn:
    1. Ga naar Components en kies de component of subcomponent die van toepassing is.
    2. Als je een component hebt gekozen, kies dan de juiste subcomponent, of Extended Help als je de subcomponent niet op die pagina ziet.
    3. Als je Extended Help hebt gekozen, kies dan de juiste subcomponent, of de [1] onderaan de lijst als je de juiste subcomponent niet kon vinden of niet weet wat de juiste subcomponent is.
    4. Je krijgt een lijst bugrapporten te zien die bij die subcomponent horen. Kies onderaan de pagina "Edit Search'. Daar kun je dan de zoekopdracht aan je behoeften aanpassen.
    5. Als je een bugrapport vindt dat met je probleem te maken heeft, kun je daar een opmerking bij plaatsen. Als je geen bugrapport vindt dat betrekking heeft op je probleem, kun je een bugrapport indienen.
  3. Als de bug alleen optreedt op Ubuntu of te maken heeft met Afdrukken, ga dan naar #More Information.
  4. Volg na dat alles, als er kennelijk geen bugrapport over dit probleem is, de instructies op bij #Een bug melden.

Een bug melden

Maak een apart bugrapport voor elke bug die je tegenkomt, ook al lijken de symptomen vanuit het gezichtspunt van en gebruiker identiek. Het kan zijn dat verschillende problemen met verschillende wortels die in verschillende versies van LibreOffice opdoken, op verschillende momenten door verschillende mensen voor verschillende versies moeten worden opgelost, en het is onmogelijk om dat in een enkel bugrapport bij te houden.

Ga naar Bugzilla.

Meld je aan

Als je wordt gevraagd om in te loggen, log dan in met je Bugzilla-account.

Component

Kies in Component de component.

Als je er niet zeker van bent met welke component met je probleem te maken heeft, kies dan de LibreOfficecomponent. Later beoordeelt iemand het bugrapport, en die kiest dan een preciezere component. (Zie voor meer informatie over triage, dat is het beoordelen van bugrapporten om zo de belangrijkste bugs bovenaan de lijst te krijgen "BugTriage".)

Als het om een ernstig probleem gaat (niet-werkende delen, regressie enz.), en je bent een ervaren gebruiker die het ontwikkellaarsteam kent, kun je het bugrapport toewijzen aan een van de ontwikkelaars op de pagina FindTheExpert.

Details

Als er een sectie Sub-component is, kies dan de subcomponent.

Als je juiste subcomponent niet kent, ga dan naar Components. Klik op die pagina op de juiste component. Lees de beschrijvingen van alle subcomponenten van die component op die pagina. Als je geen geschikte subcomponent vindt, klik dan op Extended help en lees de beschrijvingen van de subcomponenten op die pagina.

Kies de versie van de applicatie waarin de bug verscheen. Selecteer om erachter te komen welke versie van LibreOffice je gebruikt Help ▸ Over LibreOffice.

Kies in Operating system of OS het besturingssysteem van de computer waarop je met de bug te maken kreeg.

Als er een sectie Hardware is, vul die dan in.

Als er een sectie Severity (ernst) is, negeer die dan, tenzij je een ervaren gebruiker bent. De bug wordt niet sneller gerepareerd als je Blocker (stopper) kiest. Raadpleeg dit schema voor de definities van de items in de sectie Severity.

Je kunt de sectie latest known-working version (laatst bekende werkende versie) negeren.

Subject

Controleer in de tabel possibly related Bugs (mogelijk soortgelijke bugs) op de pagina voor bugmeldingen en verder op Tabel met duplicaten of het probleem echt nog niet gemeld is.

In de sectie Subject (onderwerp, ook bekend als Summary, samenvatting):

  • Geen informatie opnemen die al bekend is uit de fields.
  • Wel de namen van de subcomponenten uit Components opnemen.
    • Schrijf de subcomponenten met hoofdletters.
    • 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.

Description and attachments

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

  • list the steps to reproduce the bug;
  • use a numbered list; and
  • state the exact method to make something happen. For example, instead of writing “Open document”, write instead “In new empty LibO Spreadsheet document, use menu File > Open (LibO dialog) > file type “Text documents” > select attached sample document > double click”.

If you’re using a pre-built LibreOffice on Linux, list the exact versions of LibreOffice packages in your package management system. If you’re using Windows, list the exact filename of the installer, and from where it was downloaded.

  • Including information about installed and used localization (UI language, document language) might be useful.
  • Include whether a 32-bit LibreOffice is used on a 64-bit (Linux) system.
  • Include the package source if it’s not the official LibreOffice build.

Write the expected behavior and the actual behavior.

You can include an attachment, such as a screenshot or a sample document. The typical way to take a screenshot is to press the "Print Screen/PrtScn" button on your keyboard. Depending on your operating system, you might have to then open an image editing application (such as Paint on Windows) and do Edit - Paste in it.

  • If you create screenshots, switch the language to English before making the screenshot. You can do so in Tools ▸ Options ▸ Language Settings ▸ Languages.
  • You can make screenshots more useful by adding comments and marking relevant areas with LibreOffice Draw.
  • 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.

Status

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.

Submit

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

If Bugzilla seems daunting

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

Even if you post your problem on those channels, your goal should be to get a good bug report on bugzilla. These channels might help you with that. Note, that reporting problems on social media (Facebook, Twitter etc.) is not productive in general as it will rarely lead to a good bug report ending up in bugzilla (see also: 99 ways to ruin an open source project, top 5).

After you submit a 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.

Adding comments to bugs

  • 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.

LibreOffice is open source and your help in fixing issues that are relevant to your particular situation is most welcome. You can:

  • Employ and/or teach your own developers to work on LibreOffice. We are most happy to mentor them: see the developer’s pages.
  • Fund individuals or companies to work on specific issues - see the list of certified developers.
  • Contact The Document Foundation to help you if you have only a small amount of funding, and want to collaborate, coordinate or pool your resources with others in the same situation to fund specific fixes or enhancements.

Good Reports

Minimum requirements

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

Good Examples

  • 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

Examples of Less Good Reports

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

Paragraphs of Text

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.

One Report, Five Bugs

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

Missing Details/Steps

All bug reports should have at minimum:

  1. your Operating System and version of LibreOffice;
  2. clear reproducible steps;
  3. expected results;
  4. observed results; and
  5. a simple attachment where appropriate.

Adding Superfluous Information

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

  1. “this is a blocker”;
  2. a long list of reasons why it’s a blocker;
  3. “I can’t use LibreOffice because of this bug”;
  4. “LibreOffice sucks” (or any variation of that); and
  5. I’m going to start using your competitor unless you fix it.

Complex Attachments

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

Assuming Contributors Know Everything

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

More Information