Pajamas デザインレビュープロセス
概要
Pajamas デザインシステムは、さまざまなプロジェクトで構成されており、そこではデザインレビューが必須です:
このページでは、あなた(またはコミュニティメンバー)のマージリクエスト(MR)を承認しマージする際の、レビュアーとメンテナーの役割について説明します。また、メンテナーになるためのプロセスについても説明します。
レビュアー
すべての GitLab プロダクトデザイナーは、Pajamas に影響を与える MR に対してデザインレビューとコードレビューを実行できます(そして推奨されます)。これには、GitLab チームメンバーとより広い GitLab コミュニティからの貢献が含まれます。MR をレビューしたい場合、誰かがあなたに割り当てるまで待つこともできますが、オープンな MR のリストを閲覧し、あなたが持っているフィードバックや質問を残すことも大歓迎です。
レビューを実行するには、以下を理解し従う必要があります:
- 一般的なコードレビューガイドライン。
- プロダクトデザイナー向けの一般的な MR レビューガイドライン。
- Pajamas プロジェクトの貢献ガイドライン。
すべてのデザイナーがすべての MR をレビューできる一方で、MR を受け入れる能力はメンテナーに制限されていることに注意してください。すべてのデザインレビュアーとメンテナーは、GitLab エンジニアリングプロジェクトのリストで見つけることができます。
メンテナー
メンテナーは、以下のような GitLab デザイナーです:
- コミットメッセージのレビューを含む、デザインとコードレビューのエキスパート。
- GitLab のプロダクト、デザインガイドライン、コードベースをよく知っている。
- Pajamas プロジェクトの 1 つ以上で MR を受け入れる権限を持っている。
すべてのプロジェクトには少なくとも 1 人のメンテナーがいますが、ほとんどには複数いて、一部のプロジェクト(gitlab-uiやdesign.gitlab.comなど)にはデザインとフロントエンドのために別々のメンテナーがいます。レビュアーと同様に、デザインメンテナーはGitLab エンジニアリングプロジェクトのリストで見つけることができます。
優れたメンテナーになるための詳細については、Engineering Review Workflowをお読みください。
メンテナーの種類
デザインメンテナーは、メンテナーシップの種類に分かれています。これはメンテナーが専門化するのに役立ちますが、より重要なことに、メンテナーになるプロセスをスピードアップし、MR の最終受け入れについて誰に尋ねるべきかを知るのに役立ちます。プロジェクトの自然な進化に対応するために、新しいタイプを作成したり、既存のものをリファクタリングしたりできます。
| プロジェクト | メンテナーの種類 |
|---|---|
design.gitlab.com | Figma(Pajamas UI Kit): ファイルの構成、オブジェクトのプロパティ、インタラクションデザイン、アクセシビリティ、ビジュアルデザイン、技術的実現可能性をレビューします。UX(Pajamas ウェブサイト): ウェブサイトのすべてのセクションにわたるコンテンツの意味、用語、構造をレビューします。 |
gitlab-svgs | Figma(Pajamas UI Kit): アイコンとイラストのファイル構成、オブジェクトのプロパティ、ビジュアルデザインをレビューします。 |
gitlabまたはgitlab-uiプロジェクトの UI(.scss)のメンテナーになることに興味がある場合は、Engineering Review Workflowに従ってください。
メンテナーになる方法
エンジニアリングのカウンターパートと同じメンテナーガイドラインに従います。それらのガイドラインと、Engineering Review Workflowでメンテナーになる方法を理解してください。
そのプロセスの 3 つの重要な側面:
- 「メンテナーレベル」MR: 候補者は、最近の「メンテナーレベル」MR の具体的な例を持っている必要があります。あらゆる種類の MR に取り組むことができますが、「メンテナーレベル」の MR がメンテナーシップの焦点です。「メンテナーレベル」MR は、Engineering Review Workflowで説明されています。
- 貢献が優先: メンテナー候補者は、デザインシステムへの一貫した、意味のある貢献を示すべきです。これは、MR の提出、コードレビュー、協働的な問題解決を通じて、デザインシステムの開発に積極的に参加することを意味します。候補者は、デザインシステムの業務を時々のタスクではなく、自分の役割の重要な部分として扱い、他の責任とデザインシステムへの貢献のバランスを取ることができることを示すべきです。貢献の質と一貫性は、量よりも重要です。メンテナーは、デザインシステムを前進させる思慮深い業務を信頼性をもって提供できることを示す必要があります。
- レビュー: 候補者は、大幅な必要な変更なしに、一貫してレビュアーレビューを通過する必要があります。
- トレーニーシップはオプション: トレーニーメンテナープログラム(トレーニーシップ)は、レビュアーがメンテナーになるのを支援しますが、プログラムは必須ではありません。最近、相当数の「メンテナーレベル」MR に関与していたデザイナーは、トレーニーシップなしでメンテナーになることができます。Engineering Review Workflowで説明されているプロセスに従って、誰でも自分(または他の人)をメンテナーシップに推薦できます。
トレーニーメンテナー
エンジニアリングのカウンターパートと同じトレーニーメンテナープログラム(トレーニーシップ)に従います。誰でも、Trainee design maintainer テンプレートを使用してトラッキング Issue を開くことで、トレーニーとして自分を推薦できます。
トレーニーシップでは、各トレーニーにデザインメンテナーがサポートメンテナーとして割り当てられます。サポートメンテナーは、レビュー用の MR を指示し、提案にフィードバックを与え、1:1 セッション中にプロセスや進捗について話し合います。トレーニーは、いつでもマネージャーや他のメンテナーに、専任のサポートメンテナーとは別にフィードバックとガイダンスを求めることができます。トレーニーメンテナーが Pajamas MR のレビューを学ぶ際にガイドするのに役立つよう、Pajamas UX メンテナーレビューチェックリストも作成しました。
メンテナーが追加のサポートメンテナーとしての役割で過負荷にならず、適切なガイダンスを提供できるよう、メンテナーごとに最大 1 人のトレーニーを保つようにしています。現在のトレーニーメンテナーを参照してください。
期間
トレーニーシップは長いコミットメントで、通常は数か月かかり、他の責任から時間を奪います。このプログラムに登録することに興味がある場合は、トレーニーシップがキャパシティに影響を与える可能性が高いため、自分を推薦する前にマネージャーやチームと話してください。
トレーニーシップの期間には、それに専念する時間数と、トレーニーが利用できる MR の数の 2 つの側面が大きく影響します。これらの 2 つの側面が互いに対立するとき、トレーニーシップは予想より長くかかる可能性があります:
- 多くの時間、少ない MR: MR の数を増やすために、トレーニーはいつでも自分の貢献を行うことができます。他の人からの MR をレビューすることだけが、メンテナーになる唯一の方法ではありません。トレーニーは創造的でなければならず、可能な限り「メンテナーレベル」の MR に取り組むようにしなければなりません。
- 少ない時間、多くの MR: 少ない時間で多くの MR をレビューしたり貢献したりすることは、品質に悪影響を与える可能性があります。トレーニーは、評価される対象である品質に焦点を当てるべきです。また、レビュー応答 SLOに従うべきです。トレーニーがトレーニーシップをスピードアップしたい場合は、マネージャーと話して、ワークロードのバランスを取り、このプログラムのためにより多くの時間を確保する方法を見つけるべきです。
進捗を追跡するのに役立てるため、トレーニーはトレーニーシップを個人の OKR の 1 つにすることを推奨します。
メンテナー比率
Pajamas メンテナー比率ダッシュボード(internal)を参照してください。
現在のトレーニーメンテナー
| プロジェクト | トレーニー | サポートメンテナー |
|---|---|---|
| Pajamas Design System (Figma) - 一時停止中 | Michael Le | Jeremy Elder |
| design.gitlab.com (Brand) | Monica Galletto | Pedro Moreira da Silva |
c955a93f)