#docsテクニカルライターの採用
GitLab が成長するにつれて、テクニカルライティングチームが拡大し、チームメンバーが面接に参加します。一貫した採用プロセスのために、定義された面接プロセスが重要です。
採用プロセス 一般的なリソー …
テクニカルライティング
GitLab のテクニカルライティングチームは、開発者、プロダクトマネージャー、コミュニティと協力してプロダクトドキュメントを作成しています。
優れたドキュメントは、GitLab の顧客、ユーザー、管理者の進化するニーズに応えます。機能やベストプラクティスについて読者を教育します。GitLab を効率的に設定、利用、トラブルシューティングできるようにします。テクニカルライティングチームは docs.gitlab.com サイトとそのコンテンツ、プロセス、ツールを管理しています。
ドキュメントロードマップ は、コンテンツとドキュメントウェブサイトの両方の改善に向けた私たちの取り組みを推進しています。たとえば、docs.gitlab.com で情報を見つけにくいことを認識しています。ドキュメントサイトのプラットフォームを再構築し、より良いタスクベースの情報を提供し、コンテンツを見つけやすくするためのロードマップ項目と OKR があります。これらの大規模プロジェクトは、機能ドキュメントに加えて完了することで、ドキュメントのユーザーエクスペリエンスに継続的・反復的な改善をもたらします。
誰でもドキュメントに貢献できます。私たちの GitLab ドキュメントガイドラインに従ってください。
チームについて
チームの規模やチームメンバーの詳細については、Meet Our Team を Technical Writing でフィルタリングして参照してください。チームのロールには次のものがあります。
- Intermediate、Senior、Staff レベルの Technical Writers。
- Technical Writing Managers。
- Fullstack Engineers, Technical Writing。
- Technical Writing Director。
連絡先
私たちには、各種 Slack チャンネルまたは専用の GitLab
グループエイリアスを通じて連絡できます。@gl-docsteam は大規模なグループです。MR レビューについては、ドキュメントページのメタデータを確認し、
指定されたテクニカルライターを直接アサインするか @ メンションしてください。
Slack チャンネル
チームは、一般的なドキュメント関連およびチーム固有の Slack チャンネルを管理しています。
#docs: GitLab ドキュメントに関する質問や一般的な議論、および GitLab チームメンバーによるドキュメント・UI テキストのレビュー依頼。#docs-engineering: ドキュメントウェブサイトやその他のエンジニアリングプロジェクトに関する議論。#docs-processes: ドキュメントプロセスに関する議論。#docs-tooling: ドキュメントツールに関する議論。#docs-site-changes-hugo:docs-gitlab-comプロジェクトからの自動メッセージ。#tw-team: テクニカルライティングチームのチャット。#tw-social: テクニカルライティングチームのソーシャルチャット。
GitLab グループエイリアス
一部のチームメンバーは特定のグループに属しています。GitLab の Issue や MR で それらのグループのメンバー全員に連絡するには、次のエイリアスを使用してください。
| エイリアス | GitLab グループ | 説明 |
|---|---|---|
@gl-docsteam | gl-docsteam | テクニカルライティングチーム全体（リーダーシップ、ライター、エンジニア） |
@gitlab-org/tw-leadership | gitlab-org/tw-leadership | リーダーシップ（Manager、Staff テクニカルライター、Staff エンジニア） |
@gitlab-org/technical-writing/tw-docops | gitlab-org/technical-writing/tw-docops | DocOps |
@gitlab-org/technical-writing/tw-eng | gitlab-org/technical-writing/tw-eng | エンジニア |
@gitlab-org/maintainers/gitlab-development-kit/documentation | gitlab-org/maintainers/gitlab-development-kit/documentation | GDK のドキュメントをレビューするテクニカルライター |
GitLab テクニカルライティングの基礎を学ぶ
GitLab ドキュメントの更新や作成に興味がある場合は、 GitLab Technical Writing Fundamentals を参照してください。 このコースは GitLab チームメンバーとコミュニティ貢献者の両方を対象としており、次の内容を含みます。
- テクニカルライティングのガイドライン
- GitLab のスタイル規約
- 内部テストに関する情報
- コンテンツタイプの手順
このコースは docs.gitlab.com への貢献に 必須ではありません。誰でも貢献できます！
提案やフィードバックについては、フィードバック Issue を参照してください。
ドキュメント
GitLab ドキュメントは、ユーザー、管理者、意思決定者が GitLab の機能について学び、 DevOps のニーズを満たすために GitLab を最適に 実装・利用できるよう支援するために作られています。
ドキュメントはプロダクトの不可欠な一部です。そのソースは、
GitLab リポジトリ内のそれぞれのパスで
プロダクトとともに開発・保存されています。
ドキュメントは docs.gitlab.com（全プロダクトドキュメントの複数バージョンを提供）
と、各 GitLab インスタンスのドメインの /help/ パス（そのインスタンスのバージョンに対応するコンテンツ）
で公開されています。
ドキュメントは、すべてのプロダクト情報の 単一の信頼できる情報源（single source of truth） です。 私たちは、完全で正確かつ使いやすいドキュメントの作成を目標として、 ドキュメントファースト方法論に従っています。 ドキュメントは、必要な情報を簡単に閲覧・検索できるものであるべきであり、 ドキュメント自体への貢献も簡単であるべきです。
ドキュメントへの貢献を始めるには、 Contribute to the GitLab documentation を参照してください。 標準やガイドラインについては、スタイルガイド とワードリストを参照してください。
責任
チームメンバーは特定の DevOps ステージグループにアサインされます。テクニカルライティングチームは、ドキュメントコンテンツと UI テキストの両方を作成すること、および他者がコンテンツを作成する際に支援することに広く責任を負っています。
- 多くのエンジニアリングプロジェクトのドキュメントを保守する。
- コミュニティのニーズに応えるために、必要に応じて新しいコンテンツを作成する。
- ドキュメント計画をレビュー・協働し、ドキュメントのマージリクエストや最近マージされたドキュメントをレビューし、コンテンツがスタイルと言語の標準を満たすことを確認する。
- 完全性とスムーズなユーザーエクスペリエンスを確保するために、改善されたドキュメントを再編成・刷新・執筆する。
- マイクロコピー、UI からドキュメントへのリンク、エラーメッセージ、UI 要素のラベルなど、UI テキストについてプロダクトデザイナーと協働する。
- 毎月のリリースポストの Technical Writing Lead を務める。
優先順位付け
ステークホルダーのニーズを満たすための作業を評価する際、私たちは次の順序で優先順位を付けます。
- 機能作業（新機能のドキュメント化、UI テキストに関するガイダンスの提供を含む）
- OKR 関連作業
- ドキュメントの改善とバックログ Issue（ステージリード作業、ドキュメントの技術的負債、コンテンツトピック設計の実装を含む）
- その他すべてのタスク（DocOps タスクを含む）
プロセス
チームは、次のような効率的なプロセスの開発と保守に責任を負っています。
- GitLab ドキュメントを最新に保つためのプロセスが整備され、遵守されていることを確認する。
- プロダクト・エンジニアリングとのドキュメントワークフロー、ドキュメントチームのワークフロー、作業分担に従い、それらを最適化する。
- ドキュメント関連の Issue をトリアージする。
- ドキュメントスタイルガイドを改良し、GitLab ドキュメントとその貢献プロセスに関するコンテンツを継続的に改善する。
- コミュニティからのドキュメント貢献を効率的に処理しつつ、誰でもドキュメントに貢献しやすくする。
スタイルガイド
ドキュメントスタイルガイドは、 プロダクトドキュメントとリリースポストに関する言語とスタイルのガイダンスを提供します。
どのテクニカルライター（またはその他の貢献者）も、~tw-style ラベルを付けた Issue または
マージリクエストを作成し、その Issue または MR を Style Guide DRI にアサインすることで、
ドキュメントスタイルの更新や追加を提案できます。GitLab チームメンバーは #docs Slack チャンネルも利用できます。
完了したスタイル関連の Issue を追跡するには、次の検索を使用してください。
翻訳と国際化
誰でも、GitLab の英語から他言語への翻訳に貢献できます。 GitLab での翻訳と国際化について詳しくは、 internationalization を参照してください。 翻訳貢献の手順については、translating GitLab を参照してください。
docs.gitlab.com サイトは英語と日本語で利用できます。 ローカライゼーションプロセスについて詳しくは、 product documentation localization を参照してください。
アサインメント
テクニカルライター（TW）は、アサインされたグループと協働します。TW にはその他の作業もアサインされる場合があります。
docs.gitlab.com の一部のコンテンツは、TW のレビュー対象外です。
DevOps ステージとグループへのアサインメント
指定されたテクニカルライターは、アサインされたグループの 頼れる窓口です。新しいドキュメントの計画、既存ドキュメントの編集、 ドキュメントへの変更案のレビュー、UI マイクロコピーの変更提案について 他のチームメンバーと協働し、ドキュメントが必要なあらゆる場面で サブジェクトマターエキスパート（SME）のパートナーとして広く活動します。
Note
ドキュメントページのメタデータからこのページに案内された場合:
- メタデータは開発者の所有権を示すものではなく、適切なテクニカルライターに案内することを目的としています。
- 開発グループの一員で、ドキュメントページにメタデータを追加したい場合は、TW チームタスクプロジェクトに Issue を作成して議論してください。追加の議論は Issue 547 にあります。
- ステージが
noneと記載されている場合は、DRI がいるか確認するか、roulette を使用してください。
テクニカルライターは他のステージのドキュメントもレビュー・改善することが推奨されますが、 必須ではありません。自分が所有していないドキュメントに貢献する場合は、 アサインされた TW の所有権を尊重し、ドキュメントに重要な変更を加える際は そのレビューと承認を必ず依頼しなければなりません。
テクニカルライターが PTO 中の場合は、チーム全体がそのバックアップを務めます。
セクションリード
Technical Writing Manager は主要なセクションにアサインされます。 指定された Manager は、アサインされたセクションの頼れる窓口です。リーダーシップグループで テクニカルライティングを代表し、チームの連絡窓口として活動します。
| Section | Assigned Manager |
|---|---|
| AI |  Sarah Watt |
| Analytics | Sarah Watt |
| CD | Robert Landry |
| CI | Robert Landry |
| Dev | Robert Landry |
| Fulfillment | Sarah Watt |
| GitLab Delivery | Sarah Watt |
| Growth | Sarah Watt |
| GitLab SaaS Production Engineering | Sarah WattLysanne Pinto |
| Sec | Robert Landry |
| Tenant Scale | Sarah Watt |
これらのセクションは次を表します。
| 領域 | アサインされた Manager |
|---|---|
| AI, Analytics & Monetization, Platforms | Sarah Watt |
| Core DevOps, Security | Robert Landry |
ステージリード
このセクションでは、FY2025 の Q1 と Q2 に試験的に実施し、2025 年の Q3 でより広く展開したプロセスについて概説します。このプロセスは変更される可能性があります。
一部のテクニカルライターは、特定の DevOps ステージの ステージリード としてアサインされます。
| ステージ | アサインされたステージリード |
|---|---|
| Verify | Lysanne Pinto |
| Create | Brendan Lynch |
| Plan | TBD（保留中） |
| Application Security Testing | TBD（保留中） |
ステージリードは、ステージ全体にわたって作業する場合もあれば、ステージ内のグループのサブセットを担当する場合もあります。 彼らは、そのステージのグループにアサインされた他のテクニカルライターを支援します。
ステージリードは次を行います。
- テクニカルライターと同じ責任を負いますが、アサインされたステージのドキュメントを積極的に作成・改善することにより重点を置きます。
- 約 70% の時間を、アサインされたグループの新機能や機能強化について開発者が作成した Issue やマージリクエストのレビューに費やします。
- 残りの時間を次に費やします。
- アサインされた ステージ のドキュメントのニーズやギャップに対応するためのコンテンツの作成・改良 （たとえば、チュートリアルやユースケースベースのコンテンツの執筆、既存コンテンツの再構築、情報アーキテクチャの作業）。
- ステージ内の他のライターがドキュメント改善に貢献できるよう支援する。
- 3 つのマイルストーンにわたって対応を目指すコンテンツのギャップと改善を概説する四半期計画 Issue を完了します （たとえば、FY25Q3 Stage lead planning issue: Secure）。計画 Issue は、四半期開始前の最終月の 20 日に自動的に作成され、そのステージのすべてのテクニカルライターにアサインされます。
- 自分が推進または意見を提供するドキュメント改善 MR に、該当する
tw-leadラベルを適用します。このラベルにより、パフォーマンス指標（PI）の 1 つとして、ステージリードプロセスから生まれた改善を追跡できます。Tableau チャートは GitLab チームメンバーのみアクセス可能です。 - ドキュメント改善について他のステージリードと協働します。
時間の経過とともに、ステージリード 1 人あたりにアサインされるグループが少なくなることで、ステージリードが 30% ではなく 70% の時間を積極的な作業に費やすことが理想的な目標です。
ドキュメントの改善について、ステージリードは進行中および計画中のドキュメントの強化・追加を追跡する Issue ボードの作成に責任を負います。
DocOps グループ
DocOps は DevOps に似ていますが、ドキュメント向けのものです。ドキュメントの 作成、管理、デプロイを効率化するためのアプローチです。
一部のテクニカルライターは DocOps グループのメンバーであり、 次の責任を負っています。
- CI/CD パイプラインやローカルマシンでのテスト・リンティングを通じて、コンテンツの品質を維持する。
- 依頼があったとき、またはエンジニアがオンラインでないときに、Docs Engineers の運用タスクを支援する。たとえば、Pages の設定、デプロイ、スケジュールされたパイプライン、 レビューアプリの支援。
- リンティングツールの依存関係を更新し、それらの更新を上流のドキュメントプロジェクトに展開する。 DocOps グループは、ドキュメントウェブサイトのコード、インフラ、ビルドスクリプトには責任を負いません。 DocOps タスクは、機能作業や OKR 関連作業よりも下位に優先順位付けされます。
- TW: DocOps Issue ボードを監視する。
DocOps グループへの参加は、チームの要件に基づきます。参加に興味がある場合は、マネージャーに相談してください。
ドキュメントテスト
DocOps グループは、GitLab のドキュメント（およびその他の技術コンテンツ）の問題をテストするための ツールキットを開発・保守しています。これらのツールキットには、次のものが含まれます（ただしこれらに限りません）。
- コンテンツとフォーマット: markdownlint、Vale、yamllint
- リンクの有効性: Lychee
- ファイルのパーミッションと命名:
lint-doc.sh
リンティングルールやツールへの変更を提案するには、次を行います。
~tw-testingラベルを付けた Issue またはマージリクエストを作成する。- Issue または MR で @gitlab-org/technical-writing/tw-docops をメンションする。
DocOps グループは、この作業を他のテクニカルライティングの優先事項とバランスさせます。
他のプロジェクトと対象へのアサインメント
その他のプロジェクトや対象での協働については、次のとおりです。
| 対象 | 担当テクニカルライター |
|---|---|
| ドキュメントサイト | Sarah Watt ,
Robert Landry |
| ドキュメントサイトのバックエンド（コード、オートメーション） | Hiru Fernando |
| ドキュメントの情報アーキテクチャ（コンテンツの再構造化と左ナビゲーションの主要な変更） | Fiona Neill |
GitLab Design System (“Pajamas”) の content 配下の情報 | Fiona Neill |
| スタイルガイド | Fiona Neill |
| ドキュメントテスト（DocOps/Vale/markdownlint） | Sarah Watt |
| GitLab Development Kit (GDK) | Ashraf Khamis ,
Achilleas Pipinellis ,
Evan Read ,
Jon Glassman ,
Lorena Ciutacu ,
Marcel Amirault |
TW がレビューしないコンテンツ
テクニカルライターは、次の場所のコンテンツはレビューしません。
doc/developmentディレクトリ。doc/developmentディレクトリのドキュメントは、どの Maintainer もマージできます。 唯一の例外は/doc/development/documentationで、ここはライターがガイドラインを保守しています。doc/solutionsディレクトリ。この情報は、Solutions Architect によって作成、レビュー、マージ、保守されます。
安定したカウンターパート
テクニカルライティングチームは、チーム外の stable counterpart から docs-gitlab-com プロジェクトの支援を受けています。
| 対象 | 担当者 |
|---|---|
| バックエンドレビュー | TBD |
| フロントエンドレビュー | Paul Gascou-Vaillancourt |
| サポート | Mike Lockhart |
docs サイトの統計と分析
テクニカルライティングチームは、満足度、見つけやすさ、有用性という 3 つの重要な領域でドキュメントのパフォーマンスを追跡しています。ユーザーアンケート、Google Analytics、ユーザーフィードバック、コンテンツ監査、サイトの可用性など、複数の指標を組み合わせて使用しています。
私たちは 6 つの主要プロジェクト（GitLab、Omnibus、Charts、Operator、Runner、CLI）の統計を追跡しています。
- ドキュメントプロジェクトには 3,100 を超えるドキュメントページと 4,400,000 を超える単語があります。
- 2020 年 5 月以降、ページ数は 165% 以上、単語数は 270% 以上増加しています。
- ページ（30%）と単語（30%）の大部分は、左ナビゲーションの Use GitLab セクションにあります。
GitLab チームメンバーは、ドキュメントメトリクスページ と docs.gitlab.com の LookerStudio ダッシュボードで追加のドキュメントメトリクスを表示できます。ダッシュボードの手順については、Google Analytics を参照してください。
テクニカルライターの PTO
テクニカルライターが有給休暇を取得する際は、チームの他のメンバーがそのカバーを提供します。 これらのチームメンバーは、依頼に対して追加のコンテキストを必要とする場合があります。依頼は、その 主要グループのステージ／グループおよび 機能の優先事項のリストに組み込まれます。
アサインされたテクニカルライターが PTO 中にグループが支援を得る方法は次のとおりです。
- Reviewer Roulette。 ルーレットで選ばれたテクニカルライターに、Issue やマージリクエストでメンションまたはアサインできます。
- Slack の
#docsチャンネルでの依頼。対応可能なボランティアのテクニカルライターが 対応します。 - 特定の、時間的制約のある進行中の作業について支援が必要な場合は、事前に手配したテクニカルライター。そのテクニカルライターに Issue やマージリクエストでメンションして参加してもらえます。
長期 PTO（1 週間以上）を取得する場合、テクニカルライターと Manager は Technical Writer coverage issue を使用するべきです。 この Issue には、誰が、何を、どのような手段でカバーを提供するかを正確に記載できます。
PTO を取るとき
PTO を取得する際、テクニカルライターは次を行います。
不在通知メッセージに、利用可能なカバー手段を反映させます。 次を確実にするため、GitLab.com のステータスを最新に保つことが重要です。
- Reviewer Roulette が正確な提案を行えるようにする。
- TW チームが Roulette ダッシュボードを確認する際に、全チームメンバーの PTO ステータスを簡単に把握できるようにする。
グループの Slack チャンネルに、利用可能な手段の場所を示すメッセージを送信します。たとえば、次のとおりです。
I'm off for the holidays (202y-mm-dd - 202y-mm-dd). For help with documentation while I'm away, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#technical-writer-pto for ways to get help. For urgent _named time-sensitive task_ matters, ping _named TW_.
マージリクエストキューのチェック
テクニカルライターが PTO に入る前に、そのライターまたはマネージャーは、誰がそのライターの MR キューをチェックするかを決定するべきです。 アサインされた人は、次のいずれかを使用して、少なくとも 1 日 1 回キューをチェックするべきです。
- GitLab Review Workload Dashboard。
gitlabプロジェクトの Merge requests ページを Reviewer でフィルタリングしたもの。- coverage issue 内のマージリクエストキューセクション。
アサインされたライターが作業自体を行う必要はありません。キューをチェックする際、次を行えます。
- レビューのために MR を自分にアサインする。
- Roulette を使用してレビューする他の TW を見つける。
定期的にスケジュールされたタスク
テクニカルライターの通常アサインされている作業に加えて、定期的に完了する必要がある 反復タスクがあります。
- リリースポストの構造チェック: Technical Writing Lead が、各マイルストーンの終わりに公開されるリリースポストのコンテンツをレビューします。アサインについては、Release Post Scheduling ページを参照してください。
- 毎月のドキュメントリリース: 各マイルストーンの終わりに、テクニカルライターがドキュメントサイトの毎月のリリースを作成します。このタスクにアサインされるテクニカルライターは、前のマイルストーンでリリースポストの構造チェックを完了したライターです。
- ドキュメントプロジェクトのメンテナンスタスク: 毎月、1 人のテクニカルライターが、ドキュメントサイトとそのコンテンツのメンテナンスタスクを完了するようにアサインされます。これには、
technical-writingプロジェクトでtw-monthly-tasksテンプレートを使用して新しい Issue を作成し、メンテナンス作業を追跡することが含まれます。メンテナンス Issue に記載された内容を超える追加作業が必要な場合、テクニカルライターは必要に応じてマージリクエストや追加の Issue を作成します。
スケジュール
| バージョン | 月 | リリースポストチェック | 毎月のドキュメントリリース | メンテナンスタスク |
|---|---|---|---|---|
| 19.7 | 2026 年 12 月 | TBD | TBD | Isaac Durham |
| 19.6 | 2026 年 11 月 | TBD | Isaac Durham | Lorena Ciutacu |
| 19.5 | 2026 年 10 月 | Isaac Durham | Lorena Ciutacu | Zach Painter |
| 19.4 | 2026 年 9 月 | Lorena Ciutacu | Zach Painter | Roshni Sarangadharan |
| 19.3 | 2026 年 8 月 | Zach Painter | Roshni Sarangadharan | Fiona Neill |
| 19.2 | 2026 年 7 月 | Roshni Sarangadharan | Fiona Neill | Achilleas Pipinellis |
| 19.1 | 2026 年 6 月 | Lysanne Pinto | Achilleas Pipinellis | Jon Glassman |
| 19.0 | 2026 年 5 月 | Achilleas Pipinellis | Brendan Lynch | Uma Chandran |
| 18.11 | 2026 年 4 月 | Jon Glassman | Uma Chandran | Ryan Lehmann |
| 18.10 | 2026 年 3 月 | Uma Chandran | Russell Dickenson | Brendan Lynch |
| 18.9 | 2026 年 2 月 | Ryan Lehmann | Kati Paizee | Evan Read |
| 18.8 | 2026 年 1 月 | Brendan Lynch | Evan Read | Marcel Amirault |
| 18.7 | 2025 年 12 月 | Evan Read | Marcel Amirault | Ashraf Khamis |
| 18.6 | 2025 年 11 月 | Marcel Amirault | Ashraf Khamis | Zach Painter |
| 18.5 | 2025 年 10 月 | Ashraf Khamis | Zach Painter | Lysanne Pinto |
| 18.4 | 2025 年 9 月 | Zach Painter | Lysanne Pinto | Isaac Durham |
| 18.3 | 2025 年 8 月 | Russell Dickenson | Isaac Durham | Lorena Ciutacu |
レビュー
テクニカルライターは、GitLab チームメンバーやコミュニティ貢献者が作成したドキュメント変更を含むマージリクエストのレビューにアサインされます。レビューは、stage groups またはその他の専門分野へのテクニカルライターのアサインに従って、主題ごとにアサインされます。
編集レベル
テクニカルライターは次の編集レベルを使用します。
Light
- パイプラインが通過し、明らかな文法、スペル、句読点の誤りがないことを確認する。
Medium
- パイプラインが通過し、文法、スペル、句読点の誤りがないことを確認する。
- コンテンツが明確で、発見しやすく、ナビゲートしやすく、ユーザーの視点を念頭に置いて書かれていることを確認する。
- コンテンツがドキュメントスタイルガイドのガイドラインを満たしていることを確認する。
Heavy
- パイプラインが通過し、文法、スペル、句読点の誤りがないことを確認する。
- コンテンツが明確で、発見しやすく、ナビゲートしやすく、ユーザーの視点を念頭に置いて書かれていることを確認する。
- コンテンツがドキュメントスタイルガイドのガイドラインを満たしていることを確認する。
- コンテンツが定義されたトピックタイプに準拠していることを確認する。
- コンテンツが、より大きなドキュメントセットによく適合していることを確認する。
- UI テキストについては、コンテンツが Pajamas Design System とテクニカルライターワードリストで定義された標準を満たしていることを確認する。
ライターが編集レベルを適用する方法
品質、スピード、リソース制約のバランスを取るため、テクニカルライターは異なるドキュメントに異なる編集レベルを適用します。
これらのガイドラインは一般的なガイダンスを提供することを目的としています。固定的なものではなく、ケースバイケースで上書きできます。
次の項目は、特に依頼がない限り 編集を受けません（依頼があった場合は light 編集を受けます）。
- GitLab リポジトリの貢献ガイドライン（
/developmentディレクトリ内）。 - GitLab リポジトリの
doc/solutionsディレクトリ。この情報は Solutions Architect が所有します。
次の項目は light 編集を受けます。
- 5 つの主要 GitLab リポジトリ（GitLab、Charts、Operator、Omnibus、Runner）外のドキュメント。
- 非推奨化と削除。
- 他のテクニカルライターが作成したマージリクエスト。ただし、その MR が OKR の一部である場合、または作成者がより詳細な編集を依頼した場合を除く。
次の項目は medium 編集を受けます。
- 日々のプロダクトドキュメントの依頼:
- 新機能の作業（stage groups から）
- 改善
- バグ修正
- コミュニティ貢献
- リリースポストの項目
次の項目は heavy 編集を受けます。
- トピックタイプの再構築の取り組み（「CTRT」）
- OKR 作業
- UI テキスト
いずれの場合も、テクニカルライターは、信頼できる情報源がドキュメントの技術的正確性を確認したことを確かめます。 テクニカルライター自身が必要な知識を持っているか、必要な検証を効率的に実施できる場合は、その信頼できる情報源として 活動できます。
レビューワークフロー
ベロシティと品質のバランスを取るため、テクニカルライターは次のワークフローを使用します。
- テクニカルライターがマージリクエストを開く場合、別のテクニカルライターがレビューしてマージする必要があります。
- テクニカルライターは自分の MR を承認またはマージするべきではありません。代わりに、Maintainer アクセスを持つ仲間にレビューを依頼するべきです。最終承認後、レビュアーが MR をマージします。
- この要件は GitLab の Code Review Guidelines に沿っており、GitLab の Change Management Policy を満たします。
- テクニカルライターは自分の MR を承認またはマージするべきではありません。代わりに、Maintainer アクセスを持つ仲間にレビューを依頼するべきです。最終承認後、レビュアーが MR をマージします。
- 他の誰か（開発者、コミュニティメンバー、Support チームメンバーなど）がマージリクエストを開く場合:
- MR がドキュメント変更のみを含む場合、テクニカルライターは次を行います。
- コンテンツをレビューし、提案を行う。
- MR で明示的な承認がない限り、作成者のブランチに（提案を適用したりコミットをプッシュしたりして）大きな変更を直接行わない。 ブランチへのプッシュは解決が難しいマージコンフリクトを引き起こす可能性があり、コンテンツが誤って上書きされる場合があります。
- 作成者のブランチに直接変更を加えることについて作成者の同意がある場合に限り、提案やコミットを使用して自分で変更を行える。 その場合、ライターがマージする前に、正確性を確保するため作成者が必ずテクニカルライターの変更をレビューしなければなりません。
- MR がほぼマージ可能な状態の場合、Apply suggestion 機能を使用して小さな提案を適用できる。 ライターは、追加のレビューなしで、句読点の欠落、タイポ、パイプラインの失敗などを修正できます。
- ドキュメント MR が準備できたら承認してマージする。
- MR が主にコード変更で、ドキュメント更新も含む場合、テクニカルライターは次を行います。
- ドキュメント、UI テキスト、エラーメッセージの変更について提案を行うが、提案を自分で適用するべきではない。 コード MR に変更を加えると、コードや仕様がテクニカルライティングの提案に合うようエンジニアによる更新を必要とすることが多いため、パイプラインが失敗する可能性があります。
- ドキュメント変更がマージ可能であれば MR を承認する。
- コード MR はマージしない。MR は、コード変更もレビューするエンジニアがマージしなければなりません。
- MR が主にドキュメント変更だが、変更に合わせてリンクを更新する小さなコード変更も含む場合、テクニカルライターは次を行います。
- ドキュメントのみの MR と同じワークフローを使用してコンテンツをレビューする。
- MR がすべての必要な承認を得ている場合に 限り マージできる。
- MR がドキュメント変更のみを含む場合、テクニカルライターは次を行います。
レビューの所要時間について詳しくは、Review-response SLO を参照してください。
自動グループメンションのトリアージ
ボットまたはコミュニティ貢献者が、CODEOWNERS に基づいて @gl-docsteam または複数のテクニカルライターをメンションした場合、TW は次をボランティアで行うべきです。
- MR をスキャンし、自分でレビューを引き受けるか、レビュアーの選定のガイドラインに従ってどの TW がレビューするべきかを判断する。
- 次に、MR が:
- レビューの準備ができていそうな場合、選ばれた TW をレビュアーとしてアサインする。
- レビューの準備ができていなさそうな場合、準備ができたら選ばれた TW をメンションするよう貢献者にコメントを残す。
- ボットのコメントを編集し、チームメンションをコードとしてフォーマットする。たとえば:
Hi `@gl-docsteam`! Please review this documentation merge request.これにより、他の TW が MR の参加者リストから削除され、その MR の通知を受け取らなくなります。To-do 通知はバッククォート付きのユーザー名を表示するように更新されるため、To-do リストから作業しているチームメンバーは、その MR が対応済みであることを視覚的に把握できます。
レビュアーの選定
ほとんどの場合、テクニカルライターは GitLab Review Workload Dashboard を使用して、テクニカルライティングレビューの担当者を特定するべきです。ページのフィルターがテクニカルライターのみを表示するように設定され、Assign events last 7 days でソートされていることを確認してください。
対応可能なテクニカルライターを得るには、ダッシュボードページで Spin the wheel! を選択します。選ばれたテクニカルライターがすでに多くのレビューをアサインされている、または最近非常に忙しかった特定のケースでは、Spin the wheel! をもう一度選択して別のライターを得られます。
特定の担当者が必要なコンテンツがある場合、または DRI のいるページ（ドキュメントスタイルガイドなど）のマージリクエストがある場合は、そのレビューをその人に特定してアサインできます。
テクニカルライターの対応可否の判断
テクニカルライターが一般的なチームのマージリクエストレビューに対して忙しすぎて、自分のグループやその他の優先事項に集中する必要がある場合があります。そのような場合、テクニカルライターは Busy チェックボックスを選択し、🔴 :red_circle: を追加することで GitLab ステータスを更新でき、これによりレビュアールーレットに自分の名前が表示されなくなります。
たとえば、あるマイルストーンのリリース担当のテクニカルライターは、リリースポストやその他の要件に集中するため、リリース日の前の週に busy インジケーターをステータスに追加するべきです。
その他すべての場合、テクニカルライターは busy インジケーターをプロフィールに追加（および削除）できますが、busy インジケーターは一度に 2 日を超えて設定せず、2 週間に 1 回を超えて使用しないようお願いします。（リリース中の busy インジケーターの使用はこれに影響しないことに注意してください。）レビュールーレットに参加しない時間がもっと必要な場合は、マネージャーに相談して支援を得られるようにしてください（これには busy インジケーターの追加使用が含まれる場合があります）。
マージ権限
テクニカルライティングチームには、そのロールの一部として、GitLab プロジェクトへのマージ権限（Maintainer アクセスを通じて）が付与されています。 すべての開発者が Maintainer アクセスを得るわけではないため、テクニカルライターはこの権限を責任を持って使用しなければなりません。
Maintainer として、テクニカルライターがマージするものは次に限定しなければなりません。
- ドキュメント、通常は Markdown 形式のファイル。
- コードファイル内の UI テキスト、エラーメッセージ、リンク関連の更新（適切なエンジニアの承認付き）。
次の場合、エンジニアの承認をスキップして、TW リーダーシップチーム
または TW DocOps チームのメンバーにコード変更の承認を依頼できます。
- ドキュメント MR 内の唯一のコード変更が、ドキュメントファイルやアンカー名の変更に合わせたリンク修正であり、かつ
- パイプラインが正常に完了した場合。
- リンターなどのドキュメント関連のツールや設定、および
docs-gitlab-comプロジェクトへの変更。エンジニアが コードレビューとマージに対応できます。
さらに、テクニカルライターは次を行わなければなりません。
- 失敗したパイプラインがある MR を決してマージしない。
- マージ前に、適切なラベルとマイルストーンを付けて MR が完了していることを確認する。
- DRI が MR をレビューして承認したことを確認する。
テクニカルライターのオンボーディング
テクニカルライターのオンボーディング中は、グループのシャドーイングにアサインされ、 その後トレーニーとして貢献を開始します。ベテランのテクニカルライターがそのプロセスをコーチングします。
オンボーディングのフェーズとタスクについて詳しくは、テクニカルライターオンボーディングテンプレート を参照してください。
スタンドアップ
私たちは、週 2 回のスタンドアップ（あなたのローカルタイムゾーンで火曜日と木曜日の午前 10 時）と 毎週のランダムな質問（水曜日の正午に実行）のために Geekbot を設定しています。
すべてのメンバーがスタンドアップを編集・管理できます。
毎日のスタンドアップに新しいメンバーを追加するには、次を行います。
- Geekbot ダッシュボードにアクセスし、 求められたら Slack アカウントでサインインします。
- Tues/Thurs ping スタンドアップを選択し、Add participants エリアでメンバーを名前で検索します。
- 新しく追加したメンバーに Manage アクセスを付与し、右上隅の Save を選択します。
Weekly Wednesday Question スタンドアップに新しいメンバーを追加するには、次を行います。
- Geekbot ダッシュボードにアクセスし、 求められたら Slack アカウントでサインインします。
- Weekly Wednesday Question スタンドアップを選択し、Add participants エリアでメンバーを名前で検索します。
- 新しく追加したメンバーに manage アクセスを付与し、右上隅の Save を選択します。
テクニカルライティングチームのメンバーとして、ランダムな水曜日の質問のリストに自分の 質問を追加することが推奨されています！追加するには、次を行います。
- Weekly Wednesday Questions にアクセスします。
- Questions セクションの下に、“This is a random set of questions” という質問があります。右側の 2 つの矢印にカーソルを合わせ、Edit を選択します。
- 一番下までスクロールして Add question を選択します。
- Save questions を選択します。
コミュニティ貢献の機会
私たちは、コンテンツの改善 だけでなく、https://docs.gitlab.com のドキュメントウェブサイトの開発も歓迎します。
コミュニティ貢献について詳しくは、次を参照してください。
docs.gitlab.com で緊急のコンテンツ更新を行う
ドキュメントウェブサイトは 1 時間ごとに更新されます。まれに、ドキュメントの更新を もう少し早く公開しなければならない場合があります。緊急の更新が必要な場合は、ドキュメントサイトを手動でデプロイする手順に従ってください。
ドキュメントウェブサイトの問題やインフラの課題を報告する
ウェブサイトのバグや機能リクエストは、GitLab Docs プロジェクトの Issue リストで報告してください。
障害やウェブサイトの可用性の問題については、Docs site infrastructure を参照してください。
関連トピック
Docs Engineering: 機能の優先順位付けとプロセス
概要 Docs Engineering チームは、カンバン とマイルストーンベースの優先順位付けを使用して GitLab プロダクトドキュメントプラットフォームを維持しています。私たちは、新機能、プラ …
最終更新 June 14, 2026: Merge pull request #403 from kyama0/claude/cool-turing-ls6eck (
bfd74782)