開発プロセス
GitLabに貢献するための開発プロセスについては、これらのトピックを参照してください。
プロセス
必読
- 既存コンポーネントの適合と新コンポーネントの導入に関するガイド
- コードをレビューし、コードをレビューしてもらうためのコードレビューガイドライン
- データベース関連の変更や複雑なSQLクエリをレビューし、レビューしてもらうためのデータベースレビューガイドライン
- セキュアコーディングガイドライン
- GitLabプロジェクトのパイプライン
補完的な読み物
- 必須ストップの回避
- GitLabに貢献する
- 開発者のためのセキュリティプロセス
- 開発者のためのパッチリリースプロセス
- Enterprise Editionの機能を実装するためのガイドライン
- GitLabへの新しいサービスコンポーネントの追加
- 変更履歴のガイドライン
- 依存関係
- 危険なボット
- GitLab.comのChatOpsへのアクセスリクエスト（GitLabチームメンバー用）
開発ガイドラインのレビュー
GitLab開発ガイドラインに変更を加える場合、誰にレビューを依頼するかは変更のレベルによって異なります。
文言、スタイル、リンクの変更
すべての変更に大規模なレビューが必要なわけではありません。例えば、コンテンツの意味や機能を変更しないMRは、どのメンテナーやテクニカルライターでもレビュー、承認、マージすることができます。これには以下のようなものがあります：
- タイプミスの修正。
- 外部プログラミング言語ドキュメントへのリンクの明確化。
- ドキュメント・スタイル・ガイドに準拠するための変更で、ドキュメント・ページの意図を変えないもの。
具体的な変更
MR が特定のステージ、グループ、チームに限定した変更を提案する場合は、そのグループの経験豊富な GitLab チームメンバーにレビューと承認者を依頼してください。例えば、あるグループだけが使う新しい内部APIを文書化する場合は、そのグループのメンバーの一人にエンジニアリングレビューを依頼してください。
エンジニアリングレビューが完了したら、変更したドキュメントページのメタデータで、ステージとグループに関連付けられたテクニカルライターにMRを割り当てます。ページが特定のグループに割り当てられていない場合は、開発ガイドラインのテクニカルライティングのレビュアー・プロセスに従ってください。
より広範な変更
一部の変更は複数のグループに影響を与えます。例えば
- コードレビューガイドラインの変更。
- コミットメッセージガイドラインの変更。
- GitLab の開発における機能フラグのガイドラインの変更。
- 機能フラグのドキュメントガイドラインの変更。
このような場合は、以下のワークフローを使用してください：
- チームのメンバーにレビュアー依頼をします。
-
当該分野を担当するエンジニアリング・マネージャー(EM) またはスタッフ・エンジニアにレビューと承認を依頼してください：
EMまたはその分野を担当するスタッフエンジニアが作成したMRについては、このステップを省略できます。
影響を受けるグループが複数ある場合は、影響を受ける各エリアの EM/Staff Engineer レベルの承認者が必要になる場合があります。
-
レビュアーが完了したら、MR の作成者/承認者である EM/Staff Engineer に相談してください。
複数の領域にまたがる重要な変更の場合は、開発担当副社長、開発ガイドライン担当DRI、@clefelhocz1 に最終レビューと承認を依頼してください。
- すべての承認者が完了したら、変更したドキュメントページのメタデータで、ステージとグループに関連付けられたテクニカルライターにMRを割り当てます。ページが特定のグループに割り当てられていない場合は、開発ガイドラインのテクニカルライティングレビュープロセスに従ってください。テクニカルライターは、MRをマージする前に、前述のように追加の承認を求めることができます。
レビュアー値
GitLab 14.1 で導入されました。
レビュアーとして、あるいはレビュイーとして、GitLabで私たちが目指しているレビュアーとしての価値観をよく理解してください。