Jump to content

QA/Звіт про помилку

From The Document Foundation Wiki
< QA
This page is a translated version of the page QA/BugReport and the translation is 42% complete.
Outdated translations are marked like this.

Раді, що ви прийшли сюди. Ви збираєтеся зробити важливий внесок у розвиток LibreOffice. Хороше повідомлення про ваду дуже корисне для наших розробників. Нижче ви знайдете деякі вказівки, які полегшать цей процес.

Не всі помилки потрапляють до Bugzilla

Всі собаки можуть потрапити до раю, але деякі повідомлення про помилки слід надсилати не до Bugzilla. До них відносяться:

Клас помилок Куди надсилати повідомлення про ваду
Розширення LibreOffice Автору розширення
Інфраструктура TDF/LibreOffice (веб-сайти, списки розсилки тощо) Redmine
Створення LibreOffice Список розсилки для розробників
Тести модулів LibreOffice Список розсилки для розробників
Слова, відсутні у словниках До супровідника словника або репозиторію
Помилки в перекладах Повідомляти про них у Bugzilla дозволено, але ефективніше додавати їх як пропозиції на Weblate (не потребує реєстрації).

Перш ніж відправити повідомлення про помилку

Переконайтеся, що це дійсно "баг". Здебільшого, вада (баг) - це те, що змушує програму поводитися так, як розумний користувач не хотів би, щоб вона поводилася. Це включає в себе те, що програма не робить те, що ви хочете, робить те, що ви ніколи не просили її робити, або просто виходить з ладу при звичайному використанні. Якщо за лаштунками, помилка може бути чимось, що змушує програму працювати набагато довше і використовувати набагато більше ресурсів, ніж вона повинна.

Consider having a look at First steps to take before submitting a bug, in particular for bugs with fonts, graphics, slideshows and computation.

Якщо ви досить добре знаєте LibreOffice і зіткнулися з чимось, що може бути помилкою, але може бути просто чимось, чого ви не розумієте, ви можете опублікувати запитання на Список розсилки користувачів LibreOffice або Запитайте LibreOffice.

Але припустимо, що те, що ви знайшли, дійсно схоже на помилку. Ось що робити далі:

  1. Робіть нотатки, щоб не забути щось, що відбувалося в момент появи помилки. Що ви робили, чого очікували і що сталося насправді? Як ви зрозуміли, що щось не так? Чи можете ви відтворити погану поведінку?
  2. Якщо можливо, перевірте наявність подібних існуючих звітів про помилки (але не витрачайте на це занадто багато, і краще подати дублікат, ніж здатися):
    1. Перейдіть на Компоненти і виберіть відповідний компонент (або підкомпонент).
    2. Якщо ви вибрали компонент: виберіть відповідний підкомпонент або Розширену довідку, якщо ви не бачите підкомпонента на цій сторінці.
    3. Якщо ви вибрали Розширену довідку: виберіть відповідний підкомпонент або [1] внизу списку, якщо ви не знайшли або не знаєте відповідного підкомпонента.
    4. Ви побачите список вад, пов'язаних з цим підкомпонентом. Внизу сторінки виберіть пункт Змінити пошук. Там ви можете змінити пошук відповідно до ваших потреб.
    5. Якщо ви знайшли повідомлення про ваду, що стосується вашої проблеми, ви можете зробити свій внесок у його створення. Якщо ви не знайшли повідомлення про ваду, яке стосується вашої проблеми, створіть нове повідомлення про ваду.
  1. Якщо вада трапляється лише у Ubuntu або пов'язана з друком, перейдіть до #Додаткова інформація.
  2. Після цього, якщо не схоже, що про цю проблему створено звіт про ваду, дотримуйтесь інструкцій на сторінці #Подати повідомлення про помилку.

Подати повідомлення про помилку

Перейдіть до Bugzilla.

Вхід

Bugzilla - Головна сторінка

Якщо вам буде запропоновано Увійдіть, увійдіть за допомогою свого облікового запису Bugzilla.

Якщо у вас ще немає облікового запису в Bugzilla, створіть його, натиснувши Новий обліковий запис.

Компонент

У розділі "Компонент" виберіть компонент.

Якщо ви не впевнені, до якого компонента є ваша проблема, виберіть компонент Libreoffice. Хтось перегляне звіт про помилку пізніше і вибере більш точний компонент. (Для отримання додаткової інформації про "" TRIAGE "", яка переглядає помилки, щоб отримати важливі дії до вершини списку, подивіться " bugtriage".)

Якщо це нагальне питання (зламані частини, регресія тощо), і ви досвідчений користувач, який знає команду розробників, ви можете призначити звіт про помилку одній із розробників, перелічених на сторінці findtheexpert.

Деталі

Якщо є розділ підкомпонент, виберіть підкомпонент.

Якщо ви не знаєте відповідного підкомпонента, перейдіть до Компоненти. На цій сторінці натисніть на відповідний компонент. Прочитайте описи всіх підкомпонентів на сторінці цього компонента. Якщо ви не бачите відповідного підкомпонента, натисніть на розширену допомогу та прочитайте описи субкомпонентів на сторінці That.

Виберіть версію програми, в якій з’явилася помилка. Щоб перевірити, яку версію Libreoffice ви використовуєте, виберіть Довідка ▸ Про libreoffice

У Операційна система або ОС виберіть операційну систему комп'ютера, якою ви використовували, коли ви зустрічали помилку.

Якщо є розділ Обладнання/Hardware, заповніть його.

Якщо є розділ Тяжкість, і ви повідомляєте про запит на функцію, виберіть Удосконалення. В іншому випадку ігноруйте це, якщо ви не досвідчені. Якщо ви хочете дізнатися визначення елементів у розділі Тяжкість, див. цю діаграму

Ви можете проігнорувати розділ Остання відома робоча версія.

Тема

Перевірте в таблиці можливо пов'язаних вад на сторінці повідомлення про ваду і додатково в Таблиці дублікатів, щоб переконатися, що про проблему дійсно ще не повідомлялося.

У розділі Тема (також відомому як Резюме):

  • Не включайте інформацію, вже відому з Поля.
  • Включіть назви підкомпонентів з Компоненти.
    • Вкажіть назви підкомпонентів великими літерами.
    • Якщо підкомпонент можна сплутати з частиною слова (наприклад, UI є частиною слова quit), візьміть підкомпонент у квадратні дужки.
    • Використовуйте не більше двох підкомпонентів.
    • Використовуйте підкомпоненти точно так, як вони з'являються у списку, але ви можете інтегрувати їх у речення теми, наприклад, "WIKIHELP [UI] доступний не всіма мовами".
  • Досить точно сформулюйте проблему.
    • Поганий приклад: "Файл пошкоджено"
    • кращий приклад: "Меню Файл > Зберегти як недоступне (виділено сірим кольором)"
  • Уникайте коротких форм на кшталт "doesn't" або "isn't", щоб полегшити пошук рядків у резюме; натомість використовуйте повну форму, наприклад, "does not" або "is not".
  • Якщо проблема, описана у звіті, полягає у тому, що LibreOffice "падає" або перестає відповідати ("зависає"), додайте слово CRASH до резюме, щоб ці помилки можна було легко знайти і відстежити.

Опис та додатки

У розділі Розгорнутий опис або Опис надайте довгий, фактичний опис проблеми:

  • перелічіть кроки для відтворення вади;
  • використовуйте нумерований список; і
  • вказуйте точні дії, за допомогою яких щось має відбутися. Наприклад, замість того, щоб писати "Відкрийте документ", напишіть "У новому порожньому документі LibO Spreadsheet скористайтеся меню Файл > Відкрити (діалогове вікно LibO) > тип файлу "Текстові документи" > виберіть прикріплений зразок документа > двічі клацніть".

Якщо ви використовуєте попередньо зібраний LibreOffice у Linux, вкажіть точні версії пакунків LibreOffice у вашій системі керування пакунками. Якщо ви використовуєте Windows, вкажіть точне ім'я файлу інсталятора та джерело його завантаження.

  • Вказуйте інформацію про встановлену та використану локалізацію (мова інтерфейсу користувача, мова документів), яка може бути корисною.
  • Вкажіть, чи використовується 32-розрядний LibreOffice на 64-розрядній системі (Linux).
  • Додайте джерело пакунка, якщо це не офіційна збірка LibreOffice.

Напишіть очікувану та фактичну поведінку.

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.

After you report a bug

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.

We are grateful for every received report. Writing a bug report can be tedious and time-consuming, but the time spent by others on analysing and eventually fixing an issue can be ten or sometimes even a hundred times longer in comparison. We therefore ask you to be understanding and kindly provide more information, if requested. Moreover, a clear report with complete information means you are well positioned for having your issue fixed.

Commenting on issues

Refrain from posting comments along the lines of “me too” or “we have 1000 seats here and only this bug prevents us from migrating” which contain no additional useful information. An 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.

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:

One report for 5 issues

Reporting multiple issues in a single ticket―even if they affect a single document―is suboptimal, particularly in the long term. A ticket should only report a single issue.

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