QA/BugTriage/ru

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

    TDF LibreOffice Document Liberation Project Блоги сообщества Weblate Nextcloud Redmine Ask LibreOffice Пожертвования

    Other languages:


    Введение

    На этой странице рассказано о том, как проводится сортировка ошибок для LibreOffice. Сортировка - это действия, которые включают в себя: подтверждение, расстановку приоритетов и проверку отчета об ошибке. Она является хорошим местом для новых участников или людей с ограниченными возможностями программирования для того, чтобы помочь LibreOffice. Сортировка является невероятно важным аспектом в разработке, и приносит пользу пользователям и разработчикам.

    This document provides information on how to triage bugs for LibreOffice. Triaging is the name given for confirming, prioritizing, and organizing bug reports and is a good place for new contributors and/or contributors with limited programming abilities to help LibreOffice become a better product for everyone. Triaging is an incredibly important aspect of development that benefits users and developers alike.

    Где найти других членов команды QA

    Есть несколько мест где можно найти членов из команды QA. Многие кто может помочь с вопросами по сортировке и люди, которые сами занимаются сортировкой часто появляются:

    1. Списки рассылки - члены команды часто общаются в чате в сети freenode.
      • libreoffice-qa@lists.freedesktop.org
      • libreoffice@lists.freedesktop.org
    2. IRC-каналы на Freenode.
    3. Члены команды QA
      • Список членов команды QA - не стесняйтесь добавлять свое собственное имя, если вы собираетесь участвовать в команде QA. Пожалуйста, связывайтесь с пользователем на прямую только в том случае, когда получили от него разрешение на это.

    There are a few places where you can find/contact members from the QA team, many of whom can help with triaging questions and are actively triaging themselves.

    1. Mailing Lists
      • libreoffice-qa@lists.freedesktop.org
      • libreoffice@lists.freedesktop.org
    1. IRC Channels on Libera Chat
    1. QA Members
      Here is a list of QA members (feel free to add your own name if you intend on contributing to QA). If the user has given you permission to contact them directly, feel free to do so. Also you'll find them hanging out in the chat rooms somewhat frequently.

    Шаги в сортировке ошибок

    В этом разделе перечислены шаги, которые необходимо сделать, что бы сортировка была правильной. Это краткое руководство, для того, чтобы получить дополнительную информацию по вопросу, обычно в разделе присутствует ссылка. Перейдя по ней, вы сможете узнать о вопросе более подробно. По существу, весть процесс сортировки может быть разбит на три шага:

    1. Подготовка.
    2. Воспроизведение.
    3. Определение приоритета.

    This section lists the steps necessary in order to triage correctly. This guide aims to be concise, links in some sections will provide more information relevant to the particular step. The triage process can be essentially broken up into three parts, the first being "preparation" the second being "reproducing" the third being "prioritization".

    Порядок операций

    1. Найти ошибку для сортировки;
    2. Поиск дубликатов ошибки;
    3. Проверить информацию, представленную в отчет об ошибке;
    4. Попытаться воспроизвести ошибку
    5. Установить статус ошибки
    6. Определить приоритет
    7. Сообщить разработчикам - Нужно только в очень редких случаях, когда ошибка, кажется, блокирующей выпуск или критической.
    1. Find Bugs to Triage
    2. Pre-filter Bug Reports
    3. Search for Duplicates of Bug(s)
    4. Check Information Provided in Bug Report
    1. Attempt to Reproduce Bug
    2. Set Bug Status
    3. Regression Testing
    4. Prioritize Bug

    Объяснение шагов

    Подготовка

    В основном, вы всегда будете хотеть сделать следующие шаги в процессе сортировки ошибок. Помните, что вы можете работать над ошибками, только будучи авторизованным в Bugzilla. Если у вас ещё нет учетной записи создайте её. После того как создадите учетную запись, если вы хотите быть уведомлены каждый раз, когда кто-нибудь отвечает в сообщении, в котором вы оставили комментарий, пойдите в настройки и установите Automatically add me to the CC list of bugs I change в Only if I have no role on them.

    Preparation

    In general you'll always want to do the following steps in preparing to triage bugs. Remember that you can work on bugs only when logged in (please create an account if you do not already have one). And once you have an account, it is good to go to your preferences and set 'Automatically add me to the CC list of bugs I change' to 'Only if I have no role on them' if you want to be notified whenever someone replies in any of the bug reports you commented in.

    Шаг 1. Поиск ошибки для сортировки

    Поиск Bugzilla

    - Перейдите в bugs.documentfoundation.org трекер ошибок LibreOffice. После авторизации просмотрите открытые ошибки по компонентам или сделайте пользовательский поиск:

    1. в поле Product: выберите LibreOffice;
    1. в поле Status: выберите UNCONFIRMED и/или REOPENED;
    1. добавьте любые другие критерии, которые вам интересны.

    Когда вы авторизовались, вы можете начать искать ошибки, которые вам интересно обработать. Используйте расширенный поиск или введите условие в поле быстрого поиска (Помощь по быстрому поиску). Вы также можете использовать нижеприведённые прямые ссылки. Щелчок по ссылке переместит вас к результатам запроса на Bugzilla:

    Step 2: Pre-filter Bug Reports

    Some bugs need special attention by specific teams:

    UX Enhancements

    Any reports which cover enhancements to the UI/UX of LibreOffice should be given to the UX Team. This should be done only at a point where it is clear what the reporter wants. Prefer to leave the status as UNCONFIRMED. Only use NEW, if you feel the proposed change should obviously be implemented and the remaining question is how.

    1. Add keyword 'needsUXEval'
    2. Add this to the CC List: libreoffice-ux-advise@lists.freedesktop.org
    1. Leave a comment along the lines of:
    UX Team -- please take a look at this enhancement. Thanks!

    Some bugs don't belong in Bugzilla at all. For a list of topics that belong elsewhere, see the BugReport page.

    • If one of these bugs is filed in Bugzilla, please change the Status to RESOLVED NOTOURBUG and add the following in a comment:

    Thank you for getting in touch with us! 

    Although Bugzilla sometimes feels like the center of the
Universe, there are a few topics that need to be
reported elsewhere. To find the right place to report
your issue, please look at the BugReport wiki page:
https://wiki.documentfoundation.org/QA/BugReport#Not_all_bugs_go_to_Bugzilla

    Шаг 2. Поиск ошибок дубликатов

    Дубликаты являются ошибками отмеченные как RESOLVED DUPLICATE. Они очень близки или полностью совпадают с одной из ошибок, но отчет об ошибке подан разными пользователями. Отмеченные таким образом ошибки автоматически считаются Bugzilla и доступны на странице Most Frequently Reported Bugs for LibreOffice (Наиболее часто сообщалось об ошибках). При сортировке пожалуйста, проверьте этот список и сделайте быстрый поиск по ошибкам в Bugzilla, чтобы увидеть, есть ли какие-либо дубликаты. Но не следует тратить всю жизнь на это. :) Когда вы просмотрите большое число ошибок, вы сможете вспомнить аналогичные ошибки.

    Duplicates are reports which are very similar or identical, but reported by different users. You typically want to keep the NEW status for the report with the most valuable information and close others as RESOLVED DUPLICATE. So even though an older report exists, there is no need to keep it open, if it contains confusing or incomplete information.

    Closed duplicates are automatically counted by Bugzilla and available at Most Frequently Reported Bugs page. When triaging please, check that list and do a quick search through reports in Bugzilla to see if there are any duplicates of the report you are examining. You don't need to spend a lifetime on this. As you see more reports you may start spotting duplicates without having to use the search.

    Если вы нашли дубликат ошибки перейдите к Шагу 5

    Шаг 3. Проверка информации

    Качественно преподнесённая информация необходима для программистов. Вам нужно проверить следующие пункты:

    1. Понятное и содержательное резюме;
    2. Понятное описание проблемы;
    3. Шаги воспроизведения проблемы, если это не понятно из темы или описания проблемы;
    4. Вложения - во многих случаях они необходимы, чтобы воспроизвести проблему, если вложения нет, это может затруднить исправления.

    Если информация в отчете об ошибке не точная или её мало, перейдите к Шагу 5.

    Checking information is critical for development. What you should look for is the following:

    1. Clear and meaningful summary
    2. Clear problem description
    1. Steps to reproduce the problem -- if not clear from summary and/or description
    2. Attachments -- in many cases attachments are needed to reproduce the problem, if attachment(s) are not provided this can hinder proper fixes
    3. If the report refers to external data (screenshots, documents, screencasts, etc.), copy and attach them to the bug, so they don't vanish later and eventually render it unreproducible.

    Некоторые вопросы не относятся к Bugzilla вообще. Для получения более подробной информации смотрите страницу Как сообщить об ошибке в LibreOffice?.

    Если одна из этих ошибок подана в Bugzilla, измените статус на RESOLVED NOTOURBUG и добавьте следующий комментарий:
    Thank you for getting in touch with us!	
Although Bugzilla sometimes feels like the center of the	
Universe, there are a few topics that need to be	
reported elsewhere. To find the right place to report	
your issue, please look at the BugReport wiki page:	
https://wiki.documentfoundation.org/QA/BugReport#Not_all_bugs_go_to_Bugzilla

    Шаг 4. Попытка воспроизвести

    Если отчет об ошибке прошёл все предыдущие шаги, осталось только попробовать воспроизвести ошибку. Выполните следующее: пройдите через необходимые шаги и постарайтесь воспроизвести ошибку. Если вам удалось воспроизвести ошибку, имейте ввиду следующие вещи:

    1. Привело ли ваше воспроизведение проблемы к тому же результату? Может быть они похожи, не не одинаковы?
    2. Оставил ли репортёр достаточно информации об ошибке, нужны ли дополнительные шаги, нужны ли дополнительные вложения?

    Дополните её оставив комментарий, при необходимости, или запросите дополнительную информацию у репортёра.

    If the bug "passed" the Preparation steps it's time to try to reproduce the bug.

    Do just that: Go through the steps necessary and try to reproduce the bug, that simple! When you reproduce it, keep these things in mind:

    1. Did the bug reporter leave enough information in Bugzilla itself to reproduce the bug, or did you have to take extra steps? If extra steps were needed, add a comment to describe the extra step(s).
    2. Did your reproduction lead to the same result, something similar but not identical, or did everything work flawlessly?

    Шаг 5. Установка статуса

    Этот раздел является последним обязательным шагом для успешной сортировки.

    This section is the last "mandatory" step of a successful triage and can only be done once steps #1–#4 are done (or #3 if #4 isn't applicable).

    Статус ошибки (Status) зависит от ваших результатов вышеупомянутых шагов. Ниже приводится краткое описание использования каждого статуса.

    1. NEW: Подтвержденные ошибка, вся необходимая информация есть.
    2. NEEDINFO: Отсутствует важная информация для воспроизведения ошибки. Попросите человека её дополнить.
    3. RESOLVED: Эта категория имеет несколько вариантов использование. Если вы не можете воспроизвести ошибку, в статусе нужно указать RESOLVED WORKSFORME. Для подробной информации смотри: WORKSFORME.
    4. VERIFIED: Эта возможность доступна только тогда, когда текущая ошибка получила статус RESOLVED. Вы можете установить статус ошибки RESOLVED FIXED (исправлена) как VERIFIED, когда вы подтверждаете, что она исправлена в упомянутой версии отчета об ошибке. Это также приятное для разработчика, который выполнил исправление, и является подтверждением решения проблемы. Иначе, репортёр ошибки может отметить свою собственную ошибку которая в статусе RESOLVED WORKSFORME как VERIFIED WORKSFORME, чтобы подтвердить её как исправленную.
    5. INVALID: Существует много причин почему ошибка может быть отмечена как необоснованная. Но это обычно требует участия других членов команды QA. Если вы столкнулись с ошибкой, которую считаете необоснованной, лучшим решением будет получение стороннего мнения от членов команды QA в рассылке или на канале.
    6. UNCONFIRMED: Этот статус получают все новые ошибки, которые не прошли сортировку.
    1. NEW: Confirmed bug, all information necessary is there
    2. NEEDINFO: All information needed to attempt replication is not included in the bug report. Please ask a particular person for a particular information in a comment.
    3. RESOLVED: This category comes with several options. For example, if the issue has already been reported, you can mark it as RESOLVED DUPLICATE. Or if you can replicate the bug as described, but it is already fixed in a more recent version, RESOLVED WORKSFORME might be an appropriate STATUS. See RESOLVED for a detailed description of all possible values.
    4. VERIFIED: This option is only available when the current bug status is RESOLVED. You can mark a RESOLVED FIXED bug as VERIFIED, when you can confirm it is fixed with the version mentioned in the bug report. It is also pleasant for the developer who fixed the issue, and is a confirmation the problem is solved now. Otherwise a bug reporter can mark their own bug that is in RESOLVED WORKSFORME state as VERIFIED WORKSFORME to verify it is somehow fixed.
    5. INVALID: There are many reasons why a bug can be determined to be invalid, but this usually requires input from other QA members. If you come across a bug that you believe to be invalid, best bet is to get a second opinion from the QA IRC channel or send an email out to the mailing list explaining why you believe the bug to be invalid.
    6. UNCONFIRMED:

    This is the status given to all new bugs that have not gone through triage process. Note that such bug might be also in NEEDINFO state.

    Каждый раз, когда вы вносите изменения, вы должны сделать комментарий, вежливо объясняя, почему вы сделали эти изменения!

    Ниже приведённые блок схемы показывают, как можно визуализировать установку статуса. Если у вас есть идеи, не стесняйтесь их выкладывать.

    PDF file
    LibreOffice Draw file

    Step 7: Regression Testing

    Use older versions of LibreOffice to find out whether the bug has been introduced since LibreOffice began.

    Download and install a number of old versions, the oldest being LibreOffice 3.3. At a minimum you should have one version from all the main release lines (3.x, 4.x, 5.x, 6.x...).

    You have to have some awareness of when various features were introduced into the software to avoid getting irrelevant test results. Please consult other team members, if you are unsure of something.

    • If the bug is present in version 3.3.0, set version to "inherited from OOo" and add the following comment:

    This bug is already present in Libreoffice 3.3.0 

    Changing version to "inherited from OOo"
    • If the bug is not present in 3.3.0 add "regression" to the keywords field and add the following comment:

    This bug is not present in Libreoffice 3.3.0, thus it's a regression

    For regressions that are older than version 3.5.0, also add the keyword preBibisect. For newer regressions add the keyword bibisectRequest and update the version field to match the earliest known problematic version.

    Шаг 6. Установка приоритета

    В настоящее время выделяются только критические ошибки путём добавления в копию письма разработчиков, специальных записей в whiteboard, keywords и обновления трекера MAB (Самых досадных ошибок). Смотри: Дополнительные полезные шаги.

    We currently highlight only critical bugs by CC-ing developers and adding keywords. See below for more information.

    Пока что выставление приоритетов в сортировке ошибок находится в беспорядке, но люди, которые сортируют их, должны всегда активно стараться сделать её наилучшим образом. Также, выставление приоритетов относительно субъективно, но команда должна действовать согласовано в определении приоритета.

    Члены команды QA должны иметь четкое представление что собой представляет каждое состояние приоритета и стараться придерживаться этой методологии. Также, оставляя комментарий к ошибке после выставления приоритетов, невероятно важно дать знать репортёру (а также, разработчикам и другим пользователям) чем вы руководствовались при выборе приоритета.

    Блок-схемы ниже примеры того, как визуально думать об установке статуса.

    Пример в формате JPG
    Пример в формате Draw

    It is usually easier to determine the severity of an issue than try to think of a suitable priority.

    Small aesthetic tweaks to the UI can be considered low priority and trivial severity.

    Problems that make you angry, but you can tolerate or work around somehow can be set to minor severity.

    Bugs that break some functionality and do not have a workaround are normal severity.

    Crashes, hangs and freezes resulting from a specific file or command are major severity.

    Дополнительные полезные шаги

    Keywords

    Поле Keywords содержит ключевые слова относящиеся к категории этой ошибки.

    Keywords

    The Keywords field holds Keywords pertaining to the categorization of this bug.

    Используйте ключевое слово regression, если в предыдущей минорной версии или выпуске исправлений этой ошибки нет. Пожалуйста, не отмечайте ошибки, которые присутствуют уже несколько версий, как регрессию.

    Новые регрессии, как правило, очень сильно раздражают пострадавших пользователей и легче в исправлении. Поэтому, они должны иметь более высокий приоритет. С другой стороны, если регрессия присутствует уже несколько месяцев или даже лет, и только теперь её нашли, видимо, эта малоиспользуемая функция. И таким образом, это менее важно.

    Crash reports

    Having a crash report (aka backtrace) for a bug makes it easy for a developer to identify what is causing the crash. If a crash report is added to a bug report, the havebacktrace keyword should be added to the Keywords field.

    Meta reports

    Look at our existing meta reports that collect reports of the same genre. If you find a good fit, add the meta report number to the Blocks field of the report you are triaging.

    Статус Whiteboard

    Статусы Whiteboard - это дополнительные статусы, которые полезны для дополнения других элементов отчета. Некоторые эти статусы предназначены для привлечения внимания определённых груб разработчиков. Мы могли бы разделить их по назначению:

    • нарушается функциональность в конкретных областях: filter:xxx (filter:ooxml, filter:doc, filter:rtf, ...), perf
    • запрошена или предоставлена отладочная информация: bibisectRequest, bibisected
    • простые задачи: easyHack, difficultyBeginner, skillCPP
    • другие статусы, которые останавливаются автоматически: target:X.Y.Z, BSA

    Существует один интересный статус: needsDevEval. easyHack это ошибка, которая, вероятнее всего, не отберёт много времени для исправления и может быть исправлена новым разработчиком или разработчиком без глубоких знаний программирования. Как команда QA мы не должны просто отмечать ошибку как easyHack, так как это требует дополнительных шагов (например, поиск разработчика как наставника и обратной трассировки). Если вы думаете, что это ошибка должна быть простой для исправления, пометьте её как needsDevEval и отправьте письмо в в список рассылки разработчиков с темой POSSIBLE EASY HACK FDO#.

    obsolete, spam, me-too, off-topic, abusive, no-value, bibisection, noise.

    You can show a hidden comment by clicking on the "Toggle comment display" widget in the comment header. You can also hide regular comments and show tagged comments by clicking on the tag name of your choosing under the "Comment Tags" list next to the bug description (comment 0). Click Expand all comments to show everything.

    Проверка дополнительной информации

    Как сортировщики мы должны проверять информацию предоставленную репортёром отчета об ошибке. Они включают:

    • Product
    • Version
    • Platform

    As a triager we should try to check the information that was originally reported by the bug reporter. Things to check include:

    • Product
    • Version
    • Platform

    Добавление разработчиков в копию

    Этот шаг должен быть сделан, только если вы уверены, что это действительно необходимо. Если вы считаете, что это ошибка достаточно серьезная, чтобы она заслуживала особого внимания, но возможно не настолько серьёзна как MAB, то вам нужно найти эксперта. Пожалуйста, используйте это с осторожностью, поскольку мы не хотим, чтобы наши разработчики были получали большое количество бессмысленных сообщений. Чтобы добавить человека, просто добавите его имя к списку в копии и поместите комментарий в отчете об ошибке, говоря разработчикам, почему вы добавили их. Во всяком случае, правильные имена можно найти в списке экспертов.

    This step should only be done if you're sure that it is important enough to CC a developer. If you think that a bug is serious enough that it deserves extra attention but maybe does not belong in the category of Most Annoying Bugs, then you should seek out an expert for additional input. Please try to use this with care as we don't want to inundate our expert developers with minor bug pings. To add the user simply add their name to the CC list and put a comment on the bug telling the developers why you've added them to the CC Anyway, the right names can be found in the list of experts.

    Добавление членов QA в копию сообщения

    Обычно мы это не используем, но если вы чувствуете, что добавление себя или другого члена QA в копию может быть полезно, не стесняйтесь делать это. Убедитесь, чтобы добавить комментарий, если вы добавили кого-то в копию. В противном случае, это может раздражать человека из-за не понимания, зачем это было сделано.

    This mostly is not used but if you feel like adding yourself or another QA member to the list might be useful, feel free to do so. Again, please make sure to add a comment if you're adding someone else to the list, otherwise they might get irritated at not knowing what's going on.

    Interoperability testing

    If the requirement for testing is opening or saving a file with Microsoft Office and you don't have access to the software, you might make use of Office Web Viewer. It works with Word, Excel, PowerPoint and ODF documents. You need to upload the document somewhere and then add the URL to the end of this link:

    https://view.officeapps.live.com/op/view.aspx?src=

    You can then click the Print button in the top menu and finally Open PDF to get access to a PDF rendering of the document. This will both allow you to see how the document looks like in the latest version of Microsoft Office and share the PDF in Bugzilla.

    Bugzilla attachment links work with the viewer.

    To conveniently use the live viewer in Firefox
    • Add a new bookmark
    • Set some Name
    • Set the URL to:
    https://view.officeapps.live.com/op/view.aspx?src=%s
    • Set a Keyword, such as lv, press OK.
    • Now you can use the bookmarks keyword plus a bugdoc URL in the URL bar to open the bugdoc in the Office live viewer:
    lv https://bugs.documentfoundation.org/attachment.cgi?id=180059

    Специальные замечания для команды QA

    Тут есть некоторые замечания для опытных сортировщиков команды QA. Если вы только вступили в команду, не беспокойтесь от этом.

    Специальное ПО и оборудование необходимое для воссоздания

    Иногда нам нужно специальное программное обеспечение или аппаратное обеспечение для воспроизведения ошибки:

    Extensions

    Мы в настоящее время не имеем стратегии по сортировки ошибок расширений. Вот наш текущий план действий для ошибок с расширениями:

    • Добавьте в копию отчета об ошибке Joel Madero или Robinson Tryon, и оставьте комментарий с просьбой разобраться с ними.

    Locale-related controversy

    Sometimes we are faced with hot topics related to locales. There might be a situation where a national standard for something differs from the actual practice. In these cases, it can be useful to direct the issue reporter to the Unicode Common Locale Data Repository and their survey tool.

    Рекомендуемый порядок сортировки

    Целью команды QA является подтверждение в первую очередь самых серьёзных ошибок. Приведенные ниже таблицы, представляют собой предполагаемый порядок, чтобы ускорить сортировку.

    The tables below represent a suggested order to approach triaging. The goal of QA is to confirm the worst bugs first.

    Таблица по операционным системам (OS)

    Description All Bugs Windows Linux macOS Comments
    Аварийное завершение CrasherAll CrasherWindows CrasherLinux CrashermacOS Это ошибки, которые имеют "crash" или какой-либо аналогичное слово в названии ошибки. Для ошибок с аварийным завершением тяжесть должна быть установлена ​​на Major/Critical/Blocker в зависимости от того, сколько пользователей будут затронуты. Кроме того, члены QA должны смотреть, является ли аварийное завершение регрессией или нет, и добавить "regression" в ключевые слова, если ошибка определяется как регрессия.
    Потенциальные регрессии possibleRegressionAll possibleRegresionWindows possibleRegressionLinux possibleRegressionmacOS Эти ошибки получают в ключевое поде слово PossibleRegression при добавлении через BSA, если пользователь сообщивший об ошибке сказал, что в той или иной версии ошибка не присутствовал. Если ошибка является регрессией, статус whiteboard PossibleRegression должен быть удален и вместо него поставлено "regression" в ключевые слова (keywords).
    Ключевое слово регрессия RegressionAll RegressionWindows RegressionLinux RegressionmacOS Сообщивший об ошибке мог поставить regression в поле keyword (ключевое слово). Не менее важно, строка выше, но FDO не позволяет использовать "или" в поиск, поэтому пришлось разбить на два ряда.
    Критические ошибки CriticalAll CriticalWindows CriticalLinux CriticalmacOS В настоящее время пользователи могут устанавливается тяжесть собственных ошибок, если ошибка неправильно помечена как критическая, пожалуйста, изменить тяжесть и объяснить пользователю, почему ошибка не является таковой. Critical зарезервировано для очень серьезных ошибок (например, потери данных, которые будут влиять на многих пользователей). Для руководства смотри PriorityFlowChart
    Важные MajorAll MajorWindows MajorLinux MajormacOS В настоящее время пользователи могут устанавливается тяжесть собственных ошибок, если ошибка неправильно помечена как major, пожалуйста, изменить тяжесть и объяснить пользователю, почему ошибка не является таковой. Major зарезервировано для очень серьезных ошибок (например, потери данных), но которые, скорее всего, не влияют на многих пользователей или которые происходят только в тупиковая ситуация с отдельными документами. Для руководства смотри PriorityFlowChart.
    Все другие ошибки AllBugs AllWindows AllLinux AllmacOS Список всех отчетов об ошибках (без настройки). Если указанные выше ошибки отсортированы, тогда можно приниматься за сортировку этих. Предлагается делать их в хронологическом порядке (сначала старые, чтобы пользователи, которые сообщили раньше получили больший приоритет).
    Запросы на улучшение EnhancementAll EnhancementWindows EnhancementLinux EnhancementmacOS Запросы на улучшения обладают самым низким приоритетом для подтверждения.

    === Таблица по компонентам ===

    Описание Writer Calc Impress Draw Base Other Комментарий
    Аварийное завершение WriterCrasher SpreadsheetCrasher PresentationCrasher DrawingCrasher DatabaseCrasher OtherCrashers Это ошибки, которые имеют "crash" или какой-либо аналогичное слово в названии ошибки. Для ошибок с аварийным завершением тяжесть должна быть установлена ​​на Major/Critical/Blocker в зависимости от того, сколько пользователей будут затронуты. Кроме того, члены QA должны смотреть, является ли аварийное завершение регрессией или нет, и добавить "regression" в ключевые слова, если ошибка определяется как регрессия.
    Потенциальная регрессия WriterPosReg SpreadsheetPosReg PresentationPosReg DrawingPosReg DatabasePosReg OtherPosReg Эти ошибки получают в ключевое поде слово PossibleRegression при добавлении через BSA, если пользователь сообщивший об ошибке сказал, что в той или иной версии ошибка не присутствовал. Если ошибка является регрессией, статус whiteboard PossibleRegression должен быть удален и вместо него поставлено "regression" в ключевые слова (keywords).
    Ключевое слово регрессия WriterRegression SpreadsheetRegression PresentationRegression DrawingRegression DatabaseRegression OtherRegressions Сообщивший об ошибке мог поставить regression в поле keyword (ключевое слово). Не менее важно, строка выше, но FDO не позволяет использовать "или" в поиск, поэтому пришлось разбить на два ряда.
    Критические WriterCritical SpreadsheetCritical PresentationCritical DrawingCritical DatabaseCritical OtherCritical В настоящее время пользователи могут устанавливается тяжесть собственных ошибок, если ошибка неправильно помечена как критическая, пожалуйста, изменить тяжесть и объяснить пользователю, почему ошибка не является таковой. Critical зарезервировано для очень серьезных ошибок (например, потери данных, которые будут влиять на многих пользователей). Для руководства смотри PriorityFlowChart
    Важные WriterMajor SpreadsheetMajor PresentationMajor DrawingMajor DatabaseMajor OtherMajor В настоящее время пользователи могут устанавливается тяжесть собственных ошибок, если ошибка неправильно помечена как major, пожалуйста, изменить тяжесть и объяснить пользователю, почему ошибка не является таковой. Major зарезервировано для очень серьезных ошибок (например, потери данных), но которые, скорее всего, не влияют на многих пользователей или которые происходят только в тупиковая ситуация с отдельными документами. Для руководства смотри PriorityFlowChart.
    Все другие ошибки WriterOther SpreadsheetOther PresentationOther DrawingOther DatabaseOther AllOther Список всех отчетов об ошибках (без настройки). Если указанные выше ошибки отсортированы, тогда можно приниматься за сортировку этих. Предлагается делать их в хронологическом порядке (сначала старые, чтобы пользователи, которые сообщили раньше получили больший приоритет).
    Запросы на улучшение WriterEnhance SpreadsheetEnhance PresentationEnhance DrawingEnhance DatabaseEnhance OtherEnhance Запросы на улучшения обладают самым низким приоритетом для подтверждения.
    Retrieved from "https://wiki.documentfoundation.org/index.php?title=QA/BugTriage/ru&oldid=774323"