Приступая к работе

Поле Keywords содержит ключевые слова, относящиеся к классификации ошибок.

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

Features include:

auto-complete
only listed Keywords may be added
automatic alphabetizing of the Keywords field

Replacing Whiteboard Tags

We've created Keywords to replace several common tags (previously) used in the Whiteboard. Keywords should be much easier and faster to use, and give us more consistent results.

Ключевые слова

As with the Whiteboard field, we use wimpyCaps for all Keywords

(Bi)bisection

preBibisect

Description: Used if a bug is present at the earliest bibisect commit

Use: Should be manually entered by the person performing the bibisecting

Note: Additional tests can be done to find out if the bug was Inherited from OOo and thus not a regression. To test it you can download LibreOffice 3.3 and see if the bug is present in the earliest release, thus change version to 'Inherited from OOo', otherwise, if you are using Linux, you can see where the regression was introduced by using this repository

bibisectRequest

Description: Used to let us know that a bibisect is needed.

Use: All confirmed regressions after 3.5.0 should have a bibisectRequest keyword unless the bug is specific to Windows (which should be confirmed prior to removing a bibisectRequest). Many bugs that affect Windows will also affect Linux and macOS so they can be bibisected successfully.

bibisected

Description: Used for letting developers know that the bug has been bibisected. For more information on bibisect see the Bibisect page.

Use: Should be manually entered by the person attaching the bibisect details after bibisecting a bug.

bisected

Description: Used for letting developers know that the bug has been bisected. This applies only when the exact commit is determined, so don't add it if the bibisect process only led to a range of source commits.

Use: Should be manually entered by the person attaching the bisect/responsible commit details after bisecting a bug.

notBibisectable

Description: Use when bibisect fails for the particular bug.

Use: If someone has attempted to bibisect a bug but it has failed for some reason then put notBibisectable. Important to note that this is when the bug appears within the bibisect commit range but is not bibisectable (many reasons why this can happen).

Note: this is different from a bug that is present in the earliest commit (which requires adding the keyword “preBibisect”).

Regressions

regression

ранее работавшая функциональность была "сломана" в последующих выпусках LibreOffice.

possibleRegression

Description: possibleRegression is entered when a user has stated that the bug was not present in a previous release of LibreOffice and therefore it's a regression. The point of this status is so that QA can confirm that there is a regression and do the follow up steps needed for regressions (bibisect, etc . . .)

implementationError

Description: Use this to indicate bugs which were introduced together with a feature.

Use: To be used where a bug was introduced together with a new feature, and there is no previous version which contains the relevant feature but not the bug. This is distinct from a regression, where there is a previous version which contains the relevant feature but not the bug, and from an "Inherited from OOo" bug, where both the feature and the bug existed before the first version of LibreOffice. Using this allows this case to be distinguished from bugs which have not yet been triaged for regressions.

Note: Bibisection should be performed to confirm that the bug and the feature were introduced at the same time. If the issue is not a crash or hang, and not contrary to a written specification or other strong expectation as to how the feature should behave, the bug should instead be tagged as an enhancement.

EasyHack

needsDevEval

Description: Use when you think a bug will qualify as an easy hack and you are requesting a developer to confirm.

Use: Generally used by developers and people who have been with quality assurance for a significant amount of time. Use sparingly as it takes developers time to confirm (or reject) the easy hack.

easyHack

Description: Used to denote a bug which has been determined to be a good start for a new developer on the project.

Use: Developers should be the only ones to use this keyword. Developers add this status after they provide code pointers to fix the bug and relevant topics/skills needed.

difficultyBeginner

Description: Developers add this to easy hacks (see easyHacks keyword) to indicate that not only is the bug an easy hack, it is “really easy” and can be done by individuals who have beginner skills in computer science. These tasks are good for getting used to the code review process.

Use: Used exclusively by developers who have done the work (provided code pointers) to move the bug to an easy hack.

difficultyMedium

Description: Developers add this to easy hacks (see easyHacks keyword) to indicate that the tasks require some actual thinking and problem solving. This keyword should not be used for trivial tasks.

Use: Used exclusively by developers who have done the work (provided code pointers) to move the bug to an easy hack.

difficultyInteresting

Description: Developers add this to easy hacks (see easyHacks keyword) to indicate that while the bug is considered to be an easy hack by our experts, it could be quite challenging for a new developer on the project. Generally people who tackle these should be relatively comfortable with programming generally.

Use: Used exclusively by developers who have done the work (provided code pointers) to move the bug to an easy hack.