[Tutorial] Reporting bugs or suggestions

Home made tutorials, by users, for users
Forum rules
No question in this section please
For any question related to a topic, create a new thread in the relevant section.
Post Reply
User avatar
Hagar Delest
Posts: 32751
Joined: Sun Oct 07, 2007 9:07 pm
Location: France

[Tutorial] Reporting bugs or suggestions

Post by Hagar Delest »

Why file a report?
  • You like OpenOffice, you want to improve it? Help the developers by pointing them the flaws you could have seen
  • Reports are also used to ask for new features (RFE = Request For Enhancement)
1. Make sure there is actually a bug
  • You should use the latest version available because your bug may have been fixed in the meantime. Note that #.#.1 versions are for bug fixes only so if one of these versions is available, upgrade.
  • Creating a thread here can help determine if the issue is linked to your system (or a specific file) only. Moreover, you'll have plenty of additional information: sometimes, a bug is specific to an OS or a distribution (for Linux).
  • For Linux distributions, try to check if the bug doesn't come from your distribution packaging.
For LibO, see the LibreOffice Bug Reports page.

2. Check that the bug or suggestion has not been reported yet
Go to the query page : https://bz.apache.org/ooo/ (AOO) or https://bugs.documentfoundation.org/query.cgi (LO)
There are two ways to search for reports. The easiest (but less precise) is to introduce some keywords that identify the problem on the quick search box. The other is to click on the big Search button or the Search link on top left of the page: you'll see two search options center, at the top of the page, a Simple Search and an Advanced Search:
  • Simple Search, compared with "Quick search" gives you the possibility to select the Product: Writer, Calc, etc.
    NB: for a problem affecting all the applications, select "General".
  • Advanced Search gives you the possibility to also select:
    • Product, Component, Status & Resolution: really for advanced searches! for closed bugs for example.
    • Detailed Issue Information: Version, Severity, Priority, Hardware, OS & Target Milestone
    • Search By People: if you know the Bug Assignee or Reporter especially
    • Custom Search: really advanced search
The most difficult part is to guess what keywords other users could have used to file the report. First try few keywords and if no matches, remove them one by one to broaden the query.

3. Here we are, let's file it
First, you need an Apache BugZilla (BZ, from now on) account: As the user database is different from the forum, you need to register. If your forum username has not been used by someone else in BugZilla, you can have the same login/password. Now, click on New Account.
  • IMPORTANT: The email address you use to register will be your user name on the system and will be visible for all registered users. If you want to maintain your principal email address private, create an account on one of the many free webmail services available on internet, like gmail, yahoo, etc. Don't use your private email to register on BZ.
Once the registration process is completed, check your mail account and confirm the registration. Now you can log-in on BZ using your email address as user name and the chosen password. With a click on New, top left on the page you can start to write your report.

Select the appropriate Product, like Writer, Calc, etc. Each product has a small description that will help you which one to chose.
For a problem affecting all the applications, select "General".

On the following page, select the Component that shows the problem. For example, if the problem is during the edition select "editing" or if the problem appears when importing and external format (like .doc) select "open-import": on the box called "Component description" you'll see a brief description that will help you to choose the right component.

Select the Version on which you can see the problem. Versions are listed alphabetically, so it is possible you'll need to scroll through the list. For example, version 3.4.0 of AOO is identified with AOO340, while version 3.4.1 is identified with AOO341.

Under Severity select how bad you think the problem is. You have several options, from the worst ("critical" and "blocker") to the minor ones ("trivial")
  • blocker: use this option only for the errors that produce data loss, hangs or problems that prevent the program start
  • critical: the application is not usable or crashes
  • major: important feature broken
  • normal: random hangs, menus that do not work on the advertised way... no data loss.
  • minor: something wrong that could be confusing at first but with no feature loss (wrong translation for example)
  • trivial: a typo in the help file for example
Provide as many details as you can.
  • Write the Summary field as concise and precise as you can (this is the report title that will be shown near the bug reference when you perform a search).
  • [list]NOTE: When writing the "Summary", the system will automatically search reports with a simmilar summary: if on the resulting list a relevant report is shown well, you don't need to go on... ;) just comment on that issue and vote for it.
[*]On Description provide a detailed description of the problem, including the needed steps to reproduce it[/*]
[*]Consider the possibility to attach sample files (documents, screen-shots...) with Add an attachment button[/*]
[*]Review the provided information and when ready, click on Submit Bug.[/*]
    • When you complete the form not all the available field will be available unless you select "Show Advanced Fields", option that, perhaps, offers too many fields... an important field not shown on the default form template is "Issue Type", used to determine the kind of the report (error, enhancement request...). Unless you select "Show Advanced Fields" this field will be available only after you send the report. The possible values for this field are.
      • DEFECT
      The predefined value for this field is DEFECT, valid for error reports. If you are asking for an enhancement change this field for, well, ENHANCEMENT while if you are asking for something new or not implemented you can use FEATURE. The last two options are useful for developers so. Once the value for the issue type field is changed, you can press "Save Changes", adding something to "Additional Comments" if you wish.
For the record, the wiki page: QA/HowToFileIssue with additional details.

4. Vote for it!
Each account can cast votes to issues. You're granted 5 votes per component and you can cast 1 or 2 votes for a single issue.
Click the link to the vote page on your issue, fill the related field and click the Submit button bottom of page to confirm your vote.
Note that when an issue has been fixed, you need to clear your votes from that issue: go to the My votes page, set 0 instead of the votes number and submit. Fixed issues are marked with strikethrough characters.

5. Make the others vote for it!
You've created a thread here ? Post the link to your issue inside, so that other users could jump to it quickly and vote for it also if they're interested.
Use the BBCode URL for that: [ url=address_to_bug_report ]Issue # - Summary[ /url ] (spaces added in tags here to avoid the automatic recognition).
Advertise your issue: put the tag '[Issue]' at the beginning of your first post title in your thread.
User avatar
Hagar Delest
Posts: 32751
Joined: Sun Oct 07, 2007 9:07 pm
Location: France

Re: [Tutorial] Reporting bugs or suggestions

Post by Hagar Delest »

Here is another way from acknak (on oooforum):
  • Be patient. If you're like me, you're spoiled by Google's uncanny knack for finding what you want. Unfortunately a bug hunt doesn't work that way. At all. Be prepared to spend 20 minutes doing searches before you give up and conclude it's not there.
  • Corollary to #1: Be ready to spend some effort. Plan to read at least 10 reports before you give up the search.
  • Start with a search that's as generic as possible. By reflex, the first thing I do is clear everything to start with. I clear(*) the "Issue type" and the "Status" fields; I don't even specify the component (at first). I go straight to the field labeled "A description entry:" and enter two or three words that you expect must be used to describe the problem. Leave the default for that field to "all words/strings". Then submit.
    I avoid using the "Summary:" field if possible(**).
    Widening a search (too few hits)
    If you get no hits, remove search terms and re-submit. You may need to re-think what terms to use.
    Narrowing a search (too many hits)
    If I get more than about 70 hits, then I try adding another search term, or selecting a component(***). As a last resort, I try moving one of the search terms to the "Summary:" but only if I'm nearly certain that the term would need to appear in the summary.
  • Scan the summaries. Once I get to about 50 hits, I scan through the summaries and pick the ones that look relevant. I find the best way to do this is to use "Open in a new tab" and then move on down the list. Trying to read as you scan the list is too distracting.
    On reading a report, if it's marked as a duplicate, click the link and check the duplicate as well.
  • Read the relevant reports. Even if you don't find your issue at first, reading similar reports often suggests changes for your search terms. I may call a feature a "tab leader" when the OOo devs call it a "tab fill".
  • Regroup and try again. If you don't find your issue in the first pass, try to think of a different approach--you might describe the problem one way, but someone else may describe it very differently. As I said above, I just keep at it until I've spent 20 minutes or so, and read at least 10 reports before I give up. It's still faster in the long run to spend 20 minutes searching and 2 minutes adding a comment to an existing issue than to spend 30 minutes writing a good report that turns out to be a duplicate.
  • Practice. Chase down issues for other people's problems: it will help them (many issues in the database have workarounds or solutions in the comments) and it will give you a chance to practice when you're not excited about a bug that's causing you grief.
(*) If you can't figure out how to do this, just ask. It took me a while to work it out. I clear these because I want to know about any kind of report, at least to start with. I've never found it useful to narrow a search in these fields.

(**) The "Summary:" field is nearly useless for searching. People come up with the weirdest summaries. I filed an issue (after searching of course) with this summary: "Large page width causes center- and right-alignment to fail". The existing report that I missed in my search said "page width > 640mm forces short header left-aligned". Arrrgh. Sometimes the devs will change a poor summary, most often not. I use it as a last resort to get down to a manageable number of hits or to try and find better terms to use.

(***) Specifying the "Component" field is a potential problem: the OOo components share a lot of code, and what I think is a Writer bug is really a "Framework" bug, or may have been reported for another component.
User avatar
Posts: 2882
Joined: Mon Nov 19, 2007 8:23 pm
Location: Budapest, Hungary

Re: [Tutorial] Reporting bugs or suggestions

Post by r4zoli »

Issue handling flowchart.

You can submit your ideas on List of wishes on OOo wiki, but I has no information about the handling of such wishes.

You can submit ideas within a new issue as ENHANCMENT or FEATURE.
AOO 4.0 and LibO 4 on Win 8
Hungarian forum co-admin
User avatar
Posts: 1456
Joined: Mon Oct 08, 2007 1:34 am

Re: [Tutorial] Reporting bugs or suggestions

Post by RGB »

The "Product" field was simplified when you fill a new issue, with less and more clear categories: "Word processor" is now "Writer", "Spreadsheet" is now "Calc" and so on.
There are two types of people: those who believe that there are two types of people and those who do not.

openSUSE Leap with KDE Plasma / LibreOffice
Post Reply