JM/Bugzilla/Bidang/Keyword

    From The Document Foundation Wiki
    < QA‎ | Bugzilla‎ | Fields
    This page is a translated version of the page QA/Bugzilla/Fields/Keywords and the translation is 14% complete.
    Other languages:

    Halaman ini adalah tentang bidang Keywords pada Bugzilla.

    Pendahuluan

    Bidang Keywords berisi kata kunci yang berkaitan dengan kategorisasi kutu.

    Kata kunci telah ditentukan sebelumnya dan bidang tersebut menampilkan saran pelengkapan otomatis. Bidang Whiteboard menerima teks bebas-bentuk.

    Fitur-fiturnya meliputi:

    • pelengkapan otomatis
    • hanya Keywords yang terdaftar yang dapat ditambahkan
    • Pembuatan alfabet otomatis pada bidang Keywords

    Mengganti Tanda Whiteboard

    Kami telah membuat Keywords untuk menggantikan beberapa tanda umum yang (sebelumnya) digunakan di Whiteboard. Keywords harus lebih mudah dan lebih cepat digunakan, dan memberikan hasil yang lebih konsisten.

    Markup

    Seperti halnya bidang Whiteboard, kita menggunakan wimpyCaps untuk semua Keywords

    (Bi)bisection

    preBibisect

    Description: Digunakan jika kutu muncul pada commit bibisect paling awal

    Use: Harus diisi secara manual oleh orang yang melakukan bibisecting

    Note: Pengujian tambahan dapat dilakukan untuk mengetahui apakah kuty diwarisi dari OOo dan dengan demikian bukan regresi. Untuk mengujinya, Anda dapat mengunduh LibreOffice 3.3 dan melihat apakah kutu tersebut ada pada rilis paling awal, sehingga mengubah versi menjadi 'Inherited from OOo'. Sebaliknya, jika Anda menggunakan Linux, Anda dapat melihat di mana regresi diperkenalkan dengan menggunakan repositori ini

    bibisectRequest

    Description: Digunakan untuk memberi tahu kami bahwa bibisect memang diperlukan.

    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

    this worked in a previous release of LibreOffice, so the bug has been recently introduced.

    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.

    By Skill Required to Solve

    skillCpp

    Description: easyHacks which require C++ skills.

    Use: Used by developers who are confirming that needsDevEval are EasyHacks and then signal what skills are needed to fix the bug.

    skillJava

    Description: EasyHacks which require Java skills.

    Use: Used by developers who are confirming that needsDevEval are EasyHacks and then signal what skills are needed to fix the bug.

    skillJavaScript

    Description: EasyHacks which require JavaScript skills.

    Use: Used by developers who are confirming that needsDevEval are EasyHacks and then signal what skills are needed to fix the bug.

    skillPerl

    Description: EasyHacks which require Perl skills.

    Use: Used by developers who are confirming that needsDevEval are EasyHacks and then signal what skills are needed to fix the bug.

    skillPython

    Description: EasyHacks which require Python skills.

    Use: Used by developers who are confirming that needsDevEval are EasyHacks and then signal what skills are needed to fix the bug.

    skillSQL

    Description: EasyHacks which require SQL skills.

    Use: Used by developers who are confirming that needsDevEval are EasyHacks and then signal what skills are needed to fix the bug.

    skillVcl

    Description: EasyHacks which require VCL skills.

    Use: Used by developers who are confirming that needsDevEval are EasyHacks and then signal what skills are needed to fix the bug.

    skillUno

    Description: EasyHacks which require Uno skills.

    Use: Used by developers who are confirming that needsDevEval are EasyHacks and then signal what skills are needed to fix the bug.

    skillLibreOfficeBASIC

    Description: EasyHacks which require LibreOffice Basic skills.

    Use: Used by developers who are confirming that needsDevEval are EasyHacks and then signal what skills are needed to fix the bug.

    skillDebug

    Description: EasyHacks which require Debugging skills.

    Use: Used by developers who are confirming that needsDevEval are EasyHacks and then signal what skills are needed to fix the bug.

    skillDesign

    Description: EasyHacks which require Design skills. When used with topicDesign, the EasyHack can be solved without programming skills (visual/UI design).

    Use: Used by developers or designers who are confirming that needsDevEval are EasyHacks and then signal what skills are needed to fix the bug.

    skillScript

    Description: EasyHacks which require Scripting skills.

    Use: Used by developers who are confirming that needsDevEval are EasyHacks and then signal what skills are needed to fix the bug.

    skillTest

    Description: EasyHacks which require Testing skills.

    Use: Used by developers who are confirming that needsDevEval are EasyHacks and then signal what skills are needed to fix the bug.

    skillUI

    Description: EasyHacks which require User Interface skills.

    Use: Used by developers who are confirming that needsDevEval are EasyHacks and then signal what skills are needed to fix the bug.

    By Topic

    filter:xxx

    Description: Used to specify a particular file format for FILEOPEN / FILESAVE bugs.

    Examples:

    filter:docx 
    filter:rtf
    filter:svgInsert - when an SVG is inserted in a document
    

    filter:svgOpen -

    when a SVG is opened in Draw

    We may do something slightly different with file format families:

    filter:ooxml 
    filter:odf 
    

    text:xxx

    Description: Used to specify a particular text layout mechanism.

    Examples:

    Tag Bugs Tagged Notes
    text:rtl text:rtl Right to left
    text:cjk text:cjk Top to bottom (Chinese, Japanese, Korean)
    text:ctl text:ctl Complex text layout

    The default text layout is Left-to-Right, so we don't bother with a "text:ltr" tag, as that would be silly.

    topicCleanup

    Description: EasyHack which is focused on cleaning up code.

    Use: Used by developers who are confirming that needsDevEval are EasyHacks and then signal what is the topic (category) of the fix or improvement.

    topicQA

    Description: EasyHack which is about improving the Quality Assurance process.

    Use: Used by developers and QA experts who are confirming that needsDevEval are EasyHacks and then signal what is the topic (category) of the fix or improvement.

    topicDesign

    Description: EasyHacks which is somehow about Design. When used with skillDesign, the EasyHack can be solved without programming skills (visual/UI design).

    Use: Used by developers or designers who are confirming that needsDevEval are EasyHacks and then signal what is the topic (category) of the fix or improvement.

    Other

    accessibility

    Description: Used when the bug report is about an accessibility issue. Accessibility refers to bugs and enhancements which affect individuals with special needs. Applicable for both enhancement requests and bug reports.

    Use: Manually entered by someone who knows about accessibility problems. These are specific to bugs which would affect the way that individuals with special needs interact with LibreOffice – generally not appropriate if it is just a request to make something easier for everyone.

    perf

    Description: Bug relates to some performance problem including cpu spikes and memory leaks.

    Use: Should generally be used by experienced QA members and developers. Performance issues may need additional QA work such as a valgrind.

    dataLoss

    The bug concerns loss of data during import, export or while the program is running.

    corruptProfile

    Use for bugs that pertain to a corrupted User Profile.

    patch

    there is a patch attached to the issue

    security

    security related issue

    wantBacktrace

    a backtrace/stacktrace may help devs to pinpoint the problem. Here's a link explaining how to do it: Bug report debug information.

    haveBacktrace

    used when a backtrace or other debugging log has been attached and preferably verified to contain useful information.

    needsUXEval

    bugs which cover enhancements to the UI/UX of LibreOffice. Note that you also have to add libreoffice-ux-advise@lists.freedesktop.org to the CC to reach the Design team.

    needUITest

    bugs which happen when interacting with the UI and which should become part of an automated testing suite later on

    EasyHacks and Developer Information

    There are a number of Keywords used to categorize Development/EasyHacks. Find information about them here: