Issues workflow · Gitlab 中文文檔

# Issues workflow > 原文：[https://docs.gitlab.com/ee/development/contributing/issue_workflow.html](https://docs.gitlab.com/ee/development/contributing/issue_workflow.html) * [Issue tracker guidelines](#issue-tracker-guidelines) * [Issue triaging](#issue-triaging) * [Labels](#labels) * [Type labels](#type-labels) * [Facet labels](#facet-labels) * [Stage labels](#stage-labels) * [Naming and color convention](#naming-and-color-convention) * [Group labels](#group-labels) * [Naming and color convention](#naming-and-color-convention-1) * [Category labels](#category-labels) * [Naming and color convention](#naming-and-color-convention-2) * [Feature labels](#feature-labels) * [Naming and color convention](#naming-and-color-convention-3) * [Department labels](#department-labels) * [Team labels](#team-labels) * [Naming and color convention](#naming-and-color-convention-4) * [Specialization labels](#specialization-labels) * [Release scoping labels](#release-scoping-labels) * [Priority labels](#priority-labels) * [Severity labels](#severity-labels) * [Label for community contributors](#label-for-community-contributors) * [Stewardship label](#stewardship-label) * [Feature proposals](#feature-proposals) * [Issue weight](#issue-weight) * [Regression issues](#regression-issues) * [Technical and UX debt](#technical-and-ux-debt) * [Technical debt in follow-up issues](#technical-debt-in-follow-up-issues) # Issues workflow[](#issues-workflow "Permalink") ## Issue tracker guidelines[](#issue-tracker-guidelines "Permalink") 在提交您自己**[的問題](https://gitlab.com/gitlab-org/gitlab/-/issues)**之前，請**[在問題跟蹤器中](https://gitlab.com/gitlab-org/gitlab/-/issues)**搜索類似的條目，否則很有可能其他人也有相同的問題或功能建議. 通過獎勵表情符號顯示您的支持和/或參加討論. 請使用問題跟蹤器提供的["錯誤"問題模板](https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab/issue_templates/Bug.md)提交錯誤. 括號中的文字可以幫助您添加內容. 提交實際問題時將其忽略. 您可以復制粘貼它，然后根據需要進行編輯. ## Issue triaging[](#issue-triaging "Permalink") 我們的問題分診政策[在手冊中](https://about.gitlab.com/handbook/engineering/quality/issue-triage/)有所[描述](https://about.gitlab.com/handbook/engineering/quality/issue-triage/) . 非常歡迎您幫助 GitLab 團隊分類問題. 我們還每季度組織一次[bash 事件](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/17815) . 最重要的是確保有效問題得到開發團隊的反饋. 因此，優先考慮的是可以為這些問題提供幫助的開發人員. 請從[GitLab 團隊中](https://about.gitlab.com/company/team/)選擇具有相關經驗的[人員](https://about.gitlab.com/company/team/) . 如果沒有人提到這種專業知識，請在提交歷史中查找受影響的文件以找到某人. 我們還使用[GitLab Triage](https://gitlab.com/gitlab-org/gitlab-triage)來自動化一些分類策略. 當前已將其設置為在其上運行的計劃管道（ `https://gitlab.com/gitlab-org/quality/triage-ops/pipeline_schedules/10512/editpipeline_schedules/10512/edit` ，必須至少具有開發人員訪問項目的權限） [質量/分類操作](https://gitlab.com/gitlab-org/quality/triage-ops)項目. ## Labels[](#labels "Permalink") To allow for asynchronous issue handling, we use [milestones](https://gitlab.com/groups/gitlab-org/-/milestones) and [labels](https://gitlab.com/gitlab-org/gitlab/-/labels). Leads and product managers handle most of the scheduling into milestones. Labeling is a task for everyone. 大多數問題的標簽至少包含以下之一： * 類型： `~feature` ， `~bug` ， `~backstage` ， `~documentation`等. * 階段： `~"devops::plan"` ， `~"devops::create"`等 * 組： `~"group::source code"` ， `~"group::knowledge"` ， `~"group::editor"`等 * 類別： `~"Category:Code Analytics"` ， `~"Category:DevOps Score"` ， `~"Category:Templates"`等 * 特點： `~wiki` ， `~ldap` ， `~api` ， `~issues` ， `~"merge requests"` ，等等. * Department: `~UX`, `~Quality` * Team: `~"Technical Writing"`, `~Delivery` * Specialization: `~frontend`, `~backend`, `~documentation` * 發布范圍： `~Deliverable` ， `~Stretch` ， `~"Next Patch Release"` * Priority: `~P1`, `~P2`, `~P3`, `~P4` * 嚴重性： `S1` ， `~S2` ， `~S3` ， `~S4` 所有標簽，其含義和優先級均在[標簽頁面](https://gitlab.com/gitlab-org/gitlab/-/labels)上定義. 如果您遇到的問題都不存在，并且可以設置標簽，則可以*隨時*添加類型，階段，組以及類別/功能標簽. ### Type labels[](#type-labels "Permalink") 類型標簽非常重要. 他們定義了這是什么類型的問題. 每個問題都應該只有一個. 當前的類型標簽為： * ~feature * ~bug * ~backstage * ?"支持請求" * ~meta * ~documentation 許多類型標簽都分配了優先級，這會根據其重要性自動使它們浮動到頂部. 類型標簽始終是小寫字母，并且可以具有除藍色（已為類別標簽保留）以外的任何顏色. [標簽頁面](https://gitlab.com/groups/gitlab-org/-/labels)上的描述說明了每種類型標簽下的內容. GitLab 手冊記錄了[什么是錯誤](https://about.gitlab.com/handbook/product/product-processes/#bug-issues)以及[什么是功能請求](https://about.gitlab.com/handbook/product/product-processes/#feature-issues) . ### Facet labels[](#facet-labels "Permalink") 有時，改進問題的類型很有用. 在這種情況下，您可以添加構面標簽. 以下是構面標簽的非詳盡列表： * 增強功能：此標簽可以完善具有功能標簽的問題. * ?" master：broken"：此標簽可以細化帶有?bug 標簽的問題. * ?" failure :: flaky-test"：此標簽可以細化帶有?bug 標簽的問題. * ?"技術債務"：此標簽可以完善具有?后臺標簽的問題. * ?"靜態分析"：此標簽可以細化具有?backstage 標簽的問題. * ?" ci-build"：此標簽可以優化具有?backstage 標簽的問題. * ?性能：性能問題可能描述?錯誤或?功能. * ?安全性：一個安全性問題可以描述一個 bug 或一個功能. * 數據庫：數據庫問題可能描述錯誤或功能. * ?customer：這與客戶創建的或客戶感興趣的問題有關. * ?" UI 文本"：在 UI 內添加或修改任何文本的問題，例如用戶輔助顯微鏡，按鈕/菜單標簽或錯誤消息. ### Stage labels[](#stage-labels "Permalink") 階段標簽指定問題屬于哪個[階段](https://about.gitlab.com/handbook/product/product-categories/#hierarchy) . #### Naming and color convention[](#naming-and-color-convention "Permalink") 舞臺標簽遵守`devops::<stage_key>`命名約定. `<stage_key>`是階段密鑰，因為它位于[https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml)的單個真相來源中，其中`_`替換為空間. 例如，" Manage"階段由`gitlab-org`組中的`~"devops::manage"`標簽表示，因為它的關鍵`stages`是`manage` . 通過[在標簽列表中搜索`devops::`](https://gitlab.com/groups/gitlab-org/-/labels?search=devops::)可以找到當前階段的標簽. 這些標簽是[作用域標簽](../../user/project/labels.html#scoped-labels-premium) ，因此是互斥的. 舞臺標簽用于自動生成[方向頁面](https://about.gitlab.com/direction/) . ### Group labels[](#group-labels "Permalink") 組標簽指定了問題所屬的[組](https://about.gitlab.com/company/team/structure/#product-groups) . 強烈建議添加一個組標簽，因為我們的分類自動化會使用它來[推斷正確的舞臺標簽](https://about.gitlab.com/handbook/engineering/quality/triage-operations/#auto-labelling-of-issues) . #### Naming and color convention[](#naming-and-color-convention-1 "Permalink") 組標簽遵循`group::<group_key>`命名約定，其顏色為`#A8D695` . `<group_key>`是組密鑰，因為它位于[https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml 的](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml)組的單個真實來源中，其中已替換`_`與空間. 例如，" Continuous Integration"組由`gitlab-org`組中的?" group :: continuous integration"標簽表示，因為它的關鍵在`stages.manage.groups`下是`continuous_integration` . 通過[在標簽列表中搜索`group::`](https://gitlab.com/groups/gitlab-org/-/labels?search=group::)可以找到當前的組標簽. 這些標簽是[作用域標簽](../../user/project/labels.html#scoped-labels-premium) ，因此是互斥的. 您可以在" [產品階段"，"組"和"類別"](https://about.gitlab.com/handbook/product/product-categories/)頁面中找到列出的[組](https://about.gitlab.com/handbook/product/product-categories/) . 我們使用術語組來映射產品階段中的產品需求. 當團隊需要某種方式來收集其成員計劃分配的工作時，我們可以使用`~group::`標簽來完成. 通常，舞臺標簽和組標簽之間存在 1：1 的關系. 本著"人人都可以貢獻"的精神，任何問題都可以由任何團體根據當前的優先事項來解決. 拾取屬于其他組的問題時，應重新標記. 例如，如果計劃階段的"訪問"組中的某人拾取了標有`~"devops::create"`和`~"group::knowledge"`的問題，則應在發布該問題時將其重新標記為`~"group::access"`保持原始`~"devops::create"`不變. 我們還使用階段標簽和組標簽來幫助量化[吞吐量](https://about.gitlab.com/handbook/engineering/management/throughput/) . 請閱讀[吞吐量中的階段和組標簽，](https://about.gitlab.com/handbook/engineering/management/throughput/#stage-and-group-labels-in-throughput)以獲取有關在這種情況下如何使用標簽的更多信息. ### Category labels[](#category-labels "Permalink") 在手冊的" [產品階段，組和類別"](https://about.gitlab.com/handbook/product/product-categories/#hierarchy)頁面中： > 類別是高級功能，可能是另一家公司的獨立產品. 例如投資組合管理. 強烈建議添加類別標簽，因為我們的分類自動化會使用它來[推斷正確的組和階段標簽](https://about.gitlab.com/handbook/engineering/quality/triage-operations/#auto-labelling-of-issues) . 如果您是特定領域的專家，則可以更輕松地找到要解決的問題. 您還可以訂閱這些標簽，以在每次用與您的專業知識相對應的類別標簽標記問題時接收電子郵件. #### Naming and color convention[](#naming-and-color-convention-2 "Permalink") 類別標簽遵循" `Category:<Category Name>`命名約定，其顏色為`#428BCA` . `<Category Name>`是類別名稱，因為它位于[https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/categories.yml 的](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/categories.yml)類別的唯一真實來源中. 例如，" DevOps 分數"類別由`gitlab-org`組中的?" Category：DevOps 分數"標簽表示，因為其`devops_score.name`值為" DevOps 分數". 如果類別的標簽不遵守此命名約定，則應在[https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/categories.yml 中](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/categories.yml)使用[`label`屬性](https://about.gitlab.com/handbook/marketing/website/#category-attributes)指定它. ### Feature labels[](#feature-labels "Permalink") From the handbook’s [Product stages, groups, and categories](https://about.gitlab.com/handbook/product/product-categories/#hierarchy) page: > 特點：小型，離散功能. 例如發行權重. 括號中列出了一些常用功能，以幫助通過關鍵字查找負責任的 PM. 如果沒有類別標簽，強烈建議添加功能標簽，因為我們的分類自動分類系統會使用該功能標簽來[推斷正確的組和階段標簽](https://about.gitlab.com/handbook/engineering/quality/triage-operations/#auto-labelling-of-issues) . 如果您是特定領域的專家，則可以更輕松地找到要解決的問題. 您還可以訂閱這些標簽，以在每次問題被標記有與您的專業知識相對應的功能標簽時接收電子郵件. 特征標簽的例子是`~wiki` ， `~ldap` ， `~api` ， `~issues` ， `~"merge requests"`等. #### Naming and color convention[](#naming-and-color-convention-3 "Permalink") 功能標簽全部為小寫. ### Department labels[](#department-labels "Permalink") 當前部門標簽為： * ~UX * ~Quality ### Team labels[](#team-labels "Permalink") **重要提示** ：現在不推薦使用大多數歷史團隊標簽（例如"管理"，"計劃"等），而推薦使用" [組"標簽](#group-labels)和" [階段"標簽](#stage-labels) . 團隊標簽指定負責此問題的團隊. 分配團隊標簽可確保問題引起適當人員的注意. 當前的團隊標簽為： * ~Delivery * ?"技術寫作" #### Naming and color convention[](#naming-and-color-convention-4 "Permalink") 團隊標簽始終大寫，以便顯示為任何問題的第一個標簽. ### Specialization labels[](#specialization-labels "Permalink") 這些標簽縮小了工作單元的[專業](https://about.gitlab.com/company/team/structure/#specialist)范圍. * ~frontend * ~backend * ~documentation ### Release scoping labels[](#release-scoping-labels "Permalink") 發布范圍界定標簽有助于我們清楚地傳達對發布工作的期望. 發行范圍界定標簽分為三個級別： * ?可交付成果：預期在當前里程碑中交付的問題. * ?延伸：問題是實現當前里程碑的延伸目標. 如果當前發行版中未解決這些問題，則強烈考慮將它們用于下一個發行版. * ?"下一個補丁程序發行版"：下一個補丁程序發行版中的問題. 首先進行處理，然后將`~"Pick into XY"`標簽添加到合并請求中，并添加適當的里程碑. 為當前里程碑計劃的每個發行都應標記為?Deliverable 或?" Stretch". 上一個里程碑的所有未解決問題都應標記為"下一個補丁發布"，或以其他方式重新安排到另一個里程碑. ### Priority labels[](#priority-labels "Permalink") 我們具有以下優先級標簽： * ~P1 * ~P2 * ~P3 * ~P4 請參閱手冊中的問題分類[優先級標簽](https://about.gitlab.com/handbook/engineering/quality/issue-triage/#priority)部分，以了解其用法. ### Severity labels[](#severity-labels "Permalink") 我們具有以下嚴重性標簽： * ~S1 * ~S2 * ~S3 * ~S4 請參閱手冊中的問題分類[優先級標簽](https://about.gitlab.com/handbook/engineering/quality/issue-triage/#severity)部分，以了解其用法. ### Label for community contributors[](#label-for-community-contributors "Permalink") 我們目前沒有能力或不想給予優先考慮的對用戶有益的問題" nice to haves"被標記為"正在接受合并請求"，以便社區可以做出貢獻. 社區貢獻者可以針對他們想要的任何問題提交合并請求，但是?"接受合并請求"標簽具有特殊含義. 它指出了以下變化： 1. 我們已經達成共識， 2. 定義明確 3. 可能會被維護者接受. 我們希望避免出現以下情況：投稿人選擇?"接受合并請求"問題，然后關閉他們的合并請求，因為我們意識到它不符合我們的愿景，或者我們想以其他方式解決它. 我們會自動將?"接受合并請求"標簽添加到與[分類策略](https://about.gitlab.com/handbook/engineering/quality/triage-operations/#accepting-merge-requests)匹配的問題. 我們建議從未參與過任何開源項目的人員尋找標有`~"Accepting merge requests"`且[權重為 1](https://gitlab.com/groups/gitlab-org/-/issues?state=opened&label_name[]=Accepting+merge+requests&assignee_id=None&sort=weight&weight=1)或帶有`~"Good for 1st time contributors"` [標簽的](https://gitlab.com/gitlab-org/gitlab/-/issues?scope=all&utf8=?&state=opened&label_name[]=Good for 1st time contributors&assignee_id=None)問題. 我們歡迎更多有經驗的貢獻者[與他們](https://gitlab.com/groups/gitlab-org/-/issues?state=opened&label_name[]=Accepting+merge+requests&assignee_id=None)一起解決. 如果您決定要解決某個問題，請@-提及[適當的產品經理](https://about.gitlab.com/handbook/product/#who-to-talk-to-for-what) . 然后，產品經理將邀請適當的 GitLab 團隊成員進一步討論范圍，設計和技術注意事項. 這將確保您的貢獻與 GitLab 產品保持一致，并最大程度地減少返工和將其合并到 master 中的延遲. 在問題上貼上"接受合并請求"標簽的 GitLab 團隊成員應與負責任的產品經理一起更新問題描述，并邀請上述任何潛在的社區貢獻者加入@提及. ### Stewardship label[](#stewardship-label "Permalink") 對于與 GitLab 的開源管理有關的問題，有?"管理"標簽. 該標簽將用于解決有關 GitLab 管理問題的問題. 例如，如果 GitLab Inc.計劃將 GitLab EE 中的功能添加到 GitLab CE 中，則相關問題將標記為"管理". 最近的一個例子是[將時間跟蹤 API 引入 GitLab CE 的問題](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/25517#note_20019084) . ## Feature proposals[](#feature-proposals "Permalink") 要創建功能建議，請在[問題跟蹤器](https://gitlab.com/gitlab-org/gitlab/-/issues)上打開[問題](https://gitlab.com/gitlab-org/gitlab/-/issues) . 為了幫助跟蹤功能建議，我們創建了[`feature`](https://gitlab.com/gitlab-org/gitlab/-/issues?label_name=feature)標簽. 目前，不是項目成員的用戶無法添加標簽. 您可以改為要求[核心團隊](https://about.gitlab.com/community/core-team/)成員之一在問題上添加標簽?feature，或在描述后的新行中添加以下代碼段： `~feature` . 請使功能建議盡可能小而簡單，復雜的建議可能會被編輯以使其小而簡單. 請使用問題跟蹤器上提供的["功能建議"問題模板](https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab/issue_templates/Feature proposal.md)提交功能建議. For changes in the interface, it is helpful to include a mockup. Issues that add to, or change, the interface should be given the ~”UX” label. This will allow the UX team to provide input and guidance. You may need to ask one of the [core team](https://about.gitlab.com/community/core-team/) members to add the label, if you do not have permissions to do it by yourself. 如果您想自己創建一些東西，請考慮首先打開一個問題，討論將其包含在 GitLab 中是否有趣. ## Issue weight[](#issue-weight "Permalink") 問題權重使我們對解決一個或多個問題所需的工作量有所了解. 這樣可以更準確地安排工作. 鼓勵您設置任何問題的權重. 遵循以下準則將使其易于管理，而沒有不必要的開銷. 1. 盡早設置任何問題的權重 2. 如果您不同意設定的權重，請與其他開發人員討論，直到就權重達成共識 3. 問題權重是問題復雜性的抽象度量. 不要將發行權重直接與時間相關. 這稱為[錨定](https://en.wikipedia.org/wiki/Anchoring) ，是您要避免的事情. 4. 權重為 1（或無權重）的東西確實很小而簡單. 9 表示正在重寫 GitLab 的一個很大的基本部分，這可能會導致許多難以解決的問題. 在 GitLab 中更改某些文本可能是 1，添加新的 Git Hook 可能是 4 或 5，大功能是 7-9. 5. 如果某事物非常大，則應將其拆分為多個問題或大塊. 您不能簡單地設置父問題的權重，而不能設置子問題的權重. ## Regression issues[](#regression-issues "Permalink") 每個月度發行版的 CE 問題跟蹤器上都有一個相應的發行版，以跟蹤該發行版所破壞的功能以及修補程序發行版中需要包含的所有修補程序（請參閱[8.3 回歸](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/4127)示例）. 如問題描述中所概述的那樣，預期的工作流程是發布一個注釋，其中包含對描述回歸的問題的引用，然后通過對合并請求的引用來更新該注釋，該合并請求將在發布后對其進行修復. 如果您是貢獻者，沒有所需的權限來更新其他用戶的注釋，請發布新注釋，同時提及問題和合并請求. 發布經理將在解決補丁程序后[更新](https://gitlab.com/gitlab-org/release-tools/blob/master/doc/pro-tips.md#update-the-regression-issue)回歸問題中[的注釋](https://gitlab.com/gitlab-org/release-tools/blob/master/doc/pro-tips.md#update-the-regression-issue) . ## Technical and UX debt[](#technical-and-ux-debt "Permalink") 為了跟蹤可以在 GitLab 的代碼庫中改進的事物，我們在[GitLab 的問題跟蹤器中](https://gitlab.com/gitlab-org/gitlab/-/issues)使用?"技術債務"標簽. 對于錯過的用戶體驗要求，我們使用?" UX 債務"標簽. 這些標簽應添加到描述可以改進的問題，已采取的捷徑，需要額外注意的功能以及由于高速發展而遺留下來的所有其他事項的問題上. 例如，需要重構的代碼應使用?"技術債務"標簽，根據我們的設計系統準則，未交付的某些產品應使用?" UX 債務"標簽. 每個人都可以創建一個問題，但是如果您沒有權限自行添加，則可能需要請求添加特定標簽. 可以將其他標簽與這些標簽結合使用，以更輕松地計劃發布的改進. 用這些標簽標記的問題具有與描述要在 GitLab 中引入的新功能的問題相同的優先級，并且應該安排由適當的人員發布. 請確保在問題的描述中提及與"技術債務"問題或" UX 債務"問題相關的合并請求. ## Technical debt in follow-up issues[](#technical-debt-in-follow-up-issues "Permalink") 在開發新功能時通常會發現技術債務. 本著"最小可行的改變"的精神，通常將解決方案推遲到后續問題上. 但是，這不能用作合并劣質代碼的借口，否則這些劣質代碼將無法通過審閱，或者忽略了瑣事，這些瑣事不值得單獨安排，最好在原始合并請求中解決-否則完全追蹤！ The overheads of scheduling, and rate of change in the GitLab codebase, mean that the cost of a trivial technical debt issue can quickly exceed the value of tracking it. This generally means we should resolve these in the original merge request - or simply not create a follow-up issue at all. 例如，在文件之間復制的注釋中的錯字值得在同一 MR 中修復，但不值得為其創建后續問題. 重命名在許多地方使用的方法以使其意圖更清晰可能是值得修復的，但是這種方法不應在同一 MR 中發生，并且通常不值得自己解決. 如果我們要創建這些問題，這些問題將始終標記為`~P4 ~S4` . 更嚴重的技術債務可能對發展速度產生影響. 如果不能及時解決，那么代碼庫將變得不必要地難以更改，新功能也將難以添加，并且大量回歸. 應該認真對待此類技術債務的發現，盡管在后續問題中解決問題可能是適當的，但維護人員通常應從原始 MR 的作者或相關領域的工程或產品經理那里獲得調度承諾. . 這可以采取在問題上使用適當的優先級/嚴重性標簽的形式，也可以采用明確的里程碑和受讓人的形式. 維護者必須始終同意，以這種方式解決一個懸而未決的討論，并且它將是引發問題的人. 標題和描述的質量應[與通常](#technical-and-ux-debt)創建的標題和描述的質量相同-特別是，問題標題**不能**以" `Follow-up`開頭！創建維護者還應該期望在后續問題上開始工作時會有所參與. * * * [Return to Contributing documentation](index.html)