QA(품질보증)/버그리포트
LibreOffice 에 중요한 공헌을 하게 되는 단계에 오신 것을 환영합니다. 좋은 버그 리포트는 개발자에게 큰 도움이 됩니다. 아래에는 이 과정을 쉽게 할 수 있는 지침이 설명되어 있습니다.
모든 버그를 Bugzilla에 올리는 것은 아닙니다
All dogs may go to heaven
, but some bug reports should be filed outside of Bugzilla. These include:
| 버그의 종류 | 버그 보고 대상 |
|---|---|
| LibreOffice 확장 도구 | With the extension author |
| TDF/LibreOffice 인프라 (웹사이트, 메일링 리스트 등) | Redmine |
| LibreOffice 빌드 | Developer mailing list |
| LibreOffice 유닛 테스트 | Developer mailing list |
| Words missing from dictionaries | To the dictionary maintainer or repository |
| Mistakes in translations | Reporting them in Bugzilla is allowed, but it is more efficient to add them as suggestions in Weblate (does not require registration) |
버그를 보고하기 전에
해당 버그가 실제로 버그인지 확인하세요. 대부분의 경우, 버그란 합리적인 사용자가 원하지 않는 방식으로 소프트웨어가 작동되게 하는 것을 말합니다. 소프트웨어가 원하는 작업을 수행하지 않거나, 요청하지 않은 작업을 수행하거나, 정상적인 사용 중 충돌이 발생하는 경우가 버그에 속합니다. 내부적으로는 어떤 작업을 수행할 때 평소보다 더 많은 시간이 소요되거나 너무 많은 리소스를 사용하는 것도 버그일 수 있습니다.
일부 문제는 손상된 사용자 프로필 때문에 나타나는 결과일 수 있습니다. OpenGL 및 OpenCL 은 일반적으로 유효한 버그입니다. 버그 리포트를 작성하기 전에 OpenGL 및 OpenCL 설정에 따른 결과를 확인하면 많은 도움이 됩니다.
At a certain point what look like bugs are actually more like feature requests, where we know how the software should work in an ideal world, even though the feature we want hasn't been built yet. Fortunately, you don't have to worry that much about separating bugs from feature requests. If it's something that interferes with normal, valid use of the application, report it as a bug.
It helps a lot if you know your way around LibreOffice, though, so you have a good sense of what normal, valid use is. You don’t want to spend a lot of time reporting what you think are bugs when the issue is that you don’t know how to use a certain feature yet. Consider reading the user documentation, and use the apps a lot so you become familiar with what they normally do.
당신이 LibreOffice를 꽤 잘 알고있고, 버그일 수 있지만 이해할 수 없는 문제에 직면했다면 LibreOffice Users Mailing List 또는 Ask LibreOffice에 질문을 등록할 수 있습니다.
당신이 찾은 것이 정말로 버그처럼 보인다면 다음에 해야할 것은 다음과 같습니다.
- 버그가 나타났을 때 무슨 일이 있었는지 잊지 않도록 메모하세요. 당신은 무엇을 하고 있었고, 어떤 일이 일어나기를 기대했으며, 실제로 무슨 일이 일어났나요? 뭔가 잘못되었다는 것을 어떻게 알았나요? 잘못된 행동을 재현할 수 있나요?
- 유사한 기존 버그 리포트를 확인하세요:
- Components로 이동하여 적절한 구성 요소(또는 하위 구성 요소)를 선택합니다.
- 구성 요소를 선택한 경우: 적절한 하위 구성 요소를 선택하거나 하위 구성 요소가 페이지에 표시되지 않는 경우 확장 도움말을 선택합니다.
- 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.
- 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.
- 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.
- 만약 버그가 "Ubuntu"에서만 발생하거나 "출력"에 관련되어 있다면, #더 많은 정보로 갑니다.
- 이 모든 것을 한 후, 이 문제에 대한 버그 리포트가 없는 것처럼 보이면, #버그 제출하기의 안내를 따릅니다.
버그 리포트 제출
사용자 관점에서 증상이 동일하더라도 발생하는 각 버그에 대해 별도의 버그 리포트를 작성하세요. 수많은 LibreOffice 버전에서 발생하는 다양한 원인의 문제들을 해결하기 위해서는 다른 사람들이, 다른 버전에 대해, 다른 시간에 수정을 수행해야 할 수 있습니다. 하나의 버그 리포트에서 이 모두를 관리하는 것은 불가능합니다.
Bugzilla 로 이동하세요.
로그인
로그인하라는 안내가 나오면, Bugzilla 계정으로 로그인합니다.
If you don't have a Bugzilla account, create one by clicking New Account.
Component
In Component, choose the component.
If you are not sure what component your problem is about, choose the LibreOffice component. Someone will review the bug report later and will choose a more precise component. (For more information about triage, which is reviewing bugs to get the important onces to the top of the list, have a look at "BugTriage".)
If it is an urgent issue (broken parts, regression, etc.), and you are an experienced user who knows the development team, you can assign the bug report to one of the developers listed on the FindTheExpert page.
Details
If there is a Sub-component section, select the subcomponent.
If you don’t know the appropriate subcomponent, go to Components. On that page, click on the appropriate component. Read the descriptions of the all the subcomponents on the page of that component. If you don’t see a suitable subcomponent, click on Extended Help, and read the descriptions of the subcomponents on that page.
Choose the version of the application in which the bug appeared. To check what version of LibreOffice you are using, select ▸
In Operating system or OS, choose the operating system of the computer you were using when you met the bug.
If there is a Hardware section, fill it in.
If there is a Severity section and you are reporting a feature request, select enhancement. Otherwise ignore it unless you are experienced. If you want to know the definitions of the items in the Severity section, see this chart.
You can ignore the section latest known-working version.
Subject
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.
In the Subject section (also known as the Summary):
- Do not include information already known from the fields.
- Include the names of subcomponents from Components.
- Make the subcomponents uppercase.
- 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 ▸ ▸ ▸ .
- 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 IRC://.
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
- OS/LibreOffice version;
- enumerated reproducible steps;
- simple attachments where appropriate; and
- observed/expected results.
Good Examples
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:
- your Operating System and version of LibreOffice;
- clear reproducible steps;
- expected results;
- observed results; and
- a simple attachment where appropriate.
Adding Superfluous Information
Adding a lot of extra details that aren’t relevant is another common problem. Examples include:
- “this is a blocker”;
- a long list of reasons why it’s a blocker;
- “I can’t use LibreOffice because of this bug”;
- “LibreOffice sucks” (or any variation of that); and
- 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.