Documentation process · Gitlab 中文文檔

# Documentation process > 原文：[https://docs.gitlab.com/ee/development/documentation/workflow.html](https://docs.gitlab.com/ee/development/documentation/workflow.html) * [Who updates the docs?](#who-updates-the-docs) * [Documentation labels](#documentation-labels) * [How to update the docs](#how-to-update-the-docs) * [Reviewing and merging](#reviewing-and-merging) * [Other ways to help](#other-ways-to-help) * [Post-merge reviews](#post-merge-reviews) * [Before merging](#before-merging) # Documentation process[](#documentation-process "Permalink") 創建和維護 GitLab 產品文檔的過程允許任何人提交合并請求或為 GitLab 文檔創建問題. **注意：**與新功能或功能增強相關的文檔更新必須使用 GitLab 手冊[中](https://about.gitlab.com/handbook/engineering/ux/technical-writing/workflow/#for-a-product-change)描述的[功能工作流程](https://about.gitlab.com/handbook/engineering/ux/technical-writing/workflow/#for-a-product-change) . ## Who updates the docs?[](#who-updates-the-docs "Permalink") *任何人都*可以貢獻力量！您可以在以下情況下創建文檔合并請求： * 您發現現有文檔中存在錯誤或其他需要改進的地方. * 您對全新文檔有一個想法，可以幫助 GitLab 用戶或管理員完成其與 GitLab 的工作. ## Documentation labels[](#documentation-labels "Permalink") 無論發布或合并請求的類型如何，添加或更新文檔時都需要某些標簽. 發行或合并請求作者添加了以下內容： * 適當的[類型標簽](../contributing/issue_workflow.html#type-labels) . * [階段標簽](../contributing/issue_workflow.html#stage-labels)和[組標簽](../contributing/issue_workflow.html#group-labels) . 例如， `~devops::create`和`~devops::create` `~group::source code` . * The `~documentation` [specialization label](../contributing/issue_workflow.html#specialization-labels). 技術寫作團隊的成員還添加了以下內容： * 具有`docs::`前綴的文檔[范圍標簽](../../user/project/labels.html#scoped-labels-premium) . 例如， `~docs::improvement` . * The `~Technical Writing` [team label](../contributing/issue_workflow.html#team-labels). 與新功能或更新功能的發布無關的文檔更改不帶有`~feature`標簽，但仍需要`~documentation`標簽. 它們可能包括： * 創建或更新文檔以提高準確性，完整性，易用性或[功能更改](https://about.gitlab.com/handbook/engineering/ux/technical-writing/workflow/#for-a-product-change)以外的任何其他原因. * 解決現有文檔中的空白，或對現有文檔進行改進. * 處理與文檔相關的特殊項目. ## How to update the docs[](#how-to-update-the-docs "Permalink") 要更新 GitLab 文檔： 1. Either: * 單擊[https://docs.gitlab.com](https://s0docs0gitlab0com.icopy.site)上任何頁面底部的" **編輯此頁面"**鏈接. * 導航到[GitLab 文檔指南](index.html)頁面上列出的存儲庫和文檔路徑之一. 2. 請遵循頁面上列出的描述的標準和過程，包括： * [結構和模板](structure.html)頁面. * [樣式指南](styleguide.html) . * [降價指南](https://about.gitlab.com/handbook/markdown-guide/) . 3. 遵循 GitLab 的[合并請求準則](../contributing/merge_request_workflow.html#merge-request-guidelines) . **提示：**如果您沒有開發人員對 GitLab 項目的訪問權限，請分叉工作. 如果您滿足以下條件，請尋求技術寫作團隊的幫助： * 需要幫助選擇正確的文檔位置. * 想討論文檔想法或大綱. * 想要請求其他幫助. 要尋求幫助： 1. 找到相關[DevOps 階段組](https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments)的技術作家. 2. Either: * 如果需要緊急幫助，請直接在問題或合并請求中分配技術作家. * 如果需要非緊急幫助，請在問題或合并請求中 ping 技術作家. 如果您是 GitLab Slack 工作區的成員，則可以在`#docs`請求幫助. ### Reviewing and merging[](#reviewing-and-merging "Permalink") 擁有維護者訪問相關 GitLab 項目權限的任何人都可以合并文檔更改. 維護者必須認真努力，以確保內容： * 清晰易懂，易于目標受眾瀏覽和理解. * 符合[文檔指南](index.html)和[樣式指南](styleguide.html) . 如果作者或審稿人有任何疑問，他們可以提及被分配到相關[DevOps 階段小組的作者](https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments) . 該過程涉及以下內容： * 主要審稿人. 由[代碼審閱者](https://about.gitlab.com/handbook/engineering/projects/)或其他適當的同事進行[審閱](https://about.gitlab.com/handbook/engineering/projects/) ，以確認準確性，清晰度和完整性. 對于較小的修訂，可以跳過，而無需實質性的內容更改. * 技術作家（可選）. 如果在合并之前未完成合并請求，則必須在合并后安排. 僅在需要緊急合并時才安排合并后審核. 要請求： * 合并前審查，為適用的[DevOps 階段組](https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments)分配列出的技術作家. * 合并后審核，請參閱[合并后審核](#post-merge-reviews) . * 維護者. 對于合并請求，維護者： * 隨時可以要求上述任何評論. * 在技??術作家審查之前或之后進行審查. * 確保已設置給定的發布里程碑. * 確保應用了適當的標簽，包括將合并請求選擇到版本中所需的標簽. * 確保（如果尚未完成或計劃進行技術作家審查） [創建所需的問題](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Doc Review) ，將其分配給給定階段組的技術作家，并將其與合并請求鏈接. 該過程反映在" **文檔** [合并請求"模板中](https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab/merge_request_templates/Documentation.md) . ## Other ways to help[](#other-ways-to-help "Permalink") 如果您有更多文檔資源的想法，請使用"文檔"模板[創建問題](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Documentation) . ## Post-merge reviews[](#post-merge-reviews "Permalink") 如果在合并之前未分配給技術作家進行審核，則開發人員或維護人員必須在合并后立即安排審核. 為此，請使用" [文檔審閱"描述模板](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Doc Review)創建一個問題，并從引入了文檔更改的合并合并請求中鏈接到該問題. 可能會跳過常規的合并前技術作家審查的情況包括： * 里程碑發布還有很短的時間. 如果還有不到三天的時間，請尋求合并后的審查，并通過 Slack 對作者進行 ping 操作，以確保審查盡快完成. * The size of the change is small and you have a high degree of confidence that early users of the feature (for example, GitLab.com users) can easily use the documentation as written. Remember: * 在 GitLab，我們將文檔視為代碼. 與代碼一樣，必須檢查文檔以確保質量. * 文檔是 GitLab [對 done 的定義的](../contributing/merge_request_workflow.html#definition-of-done)一部分. * 當代碼在里程碑發布之前完成得很好并且需要更大的文檔更改時，這種合并前的 Technical Writer 審核應該是最常見的. * 如果重要的是盡快使它附帶的代碼合并，那么可以要求對文檔進行合并后技術審查. 在這種情況下，原始 MR 的作者將在后續 MR 中闡述技術作家提供的反饋. * 技術作家還可以幫助您確定無需技術作家審查就可以合并文檔，而審查將在合并后立即進行. ### Before merging[](#before-merging "Permalink") 如果跳過初步的技術作家審查，請確保以下各項： * 該[產品徽章](styleguide.html#product-badges)已應用. * 包含引入該功能的 GitLab [版本](styleguide.html#text-for-documentation-requiring-version-text)已包括在內. * 標題的更改不會影響應用內超鏈接. * 記錄了特定的[用戶權限](../../user/permissions.html) . * 為了發現，這些新文檔從更高級別的索引鏈接在一起. * 遵循樣式指南： * 用于[目錄和文件](styleguide.html#work-with-directories-and-files) . * 對于[圖像](styleguide.html#images) . **注意：**更改文檔位置的合并請求必須在合并之前始終由技術作家審查.