• 要約
• 用語
  • ワークアイテム
  • ワークアイテムのタイプ
    • ワークアイテムのプロパティ
  • 作業項目ウィジェット
  • ワークアイテムのウィジェットタイプ（更新中）
  • 作業項目の関係
    • 階層
  • ワークアイテムビュー
  • タスク
  • フィーチャーフラグ
• 動機
• 目標
  • スケーラビリティ
  • 柔軟性
  • 一貫したエクスペリエンス
• 解決すべき高レベルアーキテクチャの問題点
  • リンク集

作業項目

この文書は作業途中です。いくつかの側面は文書化されていませんが、将来的に追加されることを期待しています。

要約

ワークアイテムは、イシュー、要件、インシデントなど、製品全体で構築および計画されたさまざまなタイプのエンティティをサポートするために作成された新しいアーキテクチャです。同じ Core 機能を共有しながら、これらのタイプを簡単に拡張およびカスタマイズできるようにします。

用語

ワークアイテムアーキテクチャのコンポーネントとプロパティを説明するために、以下の用語を使用します。

ワークアイテム

イシュー、要件、テストケース、インシデント、タスクの基本タイプ（このリストは将来拡張される予定です）。異なるワークアイテムは、同じ基本プロパティのセットを持ちますが、ウィジェットのリストは異なります。

ワークアイテムのタイプ

ワークアイテムのさまざまなカテゴリのための事前定義されたタイプのセット。現在、利用可能なタイプは次のとおりです：

• インシデント
• テストケース
• 要件
• タスク
• OKR

既存のオブジェクトをワークアイテムタイプに変換したり、新しいオブジェクトを追加する作業が進行中です：

• イシュー
• エピック
• チケット

ワークアイテムのプロパティ

すべてのWork Itemタイプには、以下の共通プロパティがあります：

注：詳しくはWork Itemのフィールドを参照してください。

• id - 一意のWork Itemグローバル識別子；
• iid - 親ワークスペースに対するワークアイテムの内部 ID（現在、ワークスペースはプロジェクトのみ）。
• ワークアイテムのタイプ；
• ワークアイテムの変更時間に関連するプロパティ：createdAt updatedAt,closedAt；
• タイトル文字列；
• ワークアイテムの機密保持状態；
• ワークアイテムの状態（オープンまたはクローズ）；
• ワークアイテムが更新されるたびにインクリメントされます；
• リソースに対する現在のユーザーの権限。
• ワークアイテムウィジェットのリスト

作業項目ウィジェット

すべてのWork Itemタイプは、定義済みのウィジェットを共有し、特定のタイプでどのウィジェットがアクティブかによってカスタマイズされます。特定のWork Itemタイプのウィジェットリストは現在定義済みで、カスタマイズできません。しかし、将来的にはユーザーが新しいWork Itemタイプを作成し、そのタイプ用のウィジェットを定義できるようにする予定です。

ワークアイテムのウィジェットタイプ（更新中）

作業項目の関係

ワークアイテムは、さまざまな方法で他のワークアイテムと関連付けることができます：

• 親：親：現在のワークアイテムの直接の先祖で、その完了はこのワークアイテムの完了に依存します。
• 子：現在のワークアイテムの直接の子孫で、このワークアイテムの完了に貢献するもの。
• ブロックされたもの：現在の作業項目の完了を妨げている作業項目。
• ブロック：現在の作業項目によって完了が妨げられている作業項目。
• 関連：現在の作業項目の主題に関連するが、この作業項目の完了に直接貢献したり、妨げたりしない作業項目。

階層

親子関係は、ワークアイテムの階層の基礎を形成します。各ワークアイテムのタイプには、そのタイプの親または子になることができるタイプの定義されたセットがあります。

タイプが拡大し、親アイテムがそれ自身の親アイテムを持つようになると、階層機能は指数関数的に成長します。

Pajamasは、コンテキストに応じて階層を表示する方法を説明します。

ワークアイテムビュー

グローバルWork Itemid を識別子として使用し、あらゆるタイプのWork Itemをレンダリングする新しいフロントエンドビューです。

タスク

タスクは特別なワークアイテムタイプです。タスクは子アイテムとしてイシューに追加でき、イシュービューのモーダルに表示できます。

フィーチャーフラグ

このプロジェクトは、多数の可動部がある大規模なプロジェクトであるため、利用可能なウィジェットの昇格を追跡するために機能フラグが使用されています。下の表は、使用されているさまざまな機能フラグと、それらが利用可能な対象者を示しています。

動機

Work Itemsの主な目標は、プランニングツールセットを強化し、あらゆる業界のナレッジワーカーにとって最も人気のあるコラボレーションツールにすることです。

• すべての類似アイテム（イシュー、インシデント、エピック、テストケースなど）を標準プラットフォーム上に配置し、メンテナンスを簡素化し、エクスペリエンスの一貫性を高めます。
• 一般的なプランニングコンセプトをファーストクラスでサポートすることで、複雑さを軽減し、ユーザーがGitLab特有のニュアンスを学ぶことなくプランニングできるようにします。

目標

スケーラビリティ

現在、イシュー、エピック、マージリクエストなどの異なるエンティティは多くの類似した機能を共有していますが、これらの機能はエンティティの種類ごとに個別に実装されています。例えば、イシューとインシデントに新しい機能を追加する場合、イシューとインシデントタイプに別々に実装する必要があります。ワークアイテムの場合、新しい機能は既存のすべてのタイプに対してウィジェットを介して実装されるため、アーキテクチャがよりスケーラブルになります。

柔軟性

既存の実装では、イシュアブル、マージリクエスト、エピックなどのための厳格な構造を持っています。この構造はバックエンドとフロントエンドの両方で定義されているため、変更には調整作業が必要です。また、既存の機能を有効/無効にするフラグを導入することなく、この構造をユーザーのためにカスタマイズ可能にすることは非常に難しいでしょう。Work Itemアーキテクチャは、フロントエンドが柔軟な方法でWork Itemウィジェットを表示することを可能にします。これにより、変更を素早く行うことができ、構造がより柔軟になります。例えば、インシデントページにラベルを表示したくない場合、バックエンドでインシデントワークアイテムタイプからラベルウィジェットを削除します。また、将来的には、ユーザーがカスタムWork Itemタイプに表示したいウィジェットのセットを定義できるようになります。

一貫したエクスペリエンス

異なるエンティティの類似機能に対して一貫した動作を持つように努めていますが、実装にはまだ違いがあります。たとえば、GraphQL API を介したマージリクエストでのラベルの更新は専用のsetMergeRequestLabels 変異で行うことができますが、イシューではより粗粒度のupdateIssueを呼び出します。これは、フロントエンドと外部 API ユーザーの両方に一貫性のないエクスペリエンスを提供します。その結果、エピック、イシュー、要件、その他はすべて、共通するインタラクションにおいて類似していますが微妙な違いがあるため、ユーザーはそれぞれの動作について複雑なメンタルモデルを保持する必要があります。

Work Itemアーキテクチャは、Work Itemウィジェットとして実装された、すべてのタイプのためのすべての機能を一貫したものにすることを念頭に設計されています。

解決すべき高レベルアーキテクチャの問題点

• グループやプロジェクトのマイグレーションを回避して、エピックをWork Itemタイプに移行する方法；
• 特定のWork Itemタイプ（エピック＞イシュー＞タスク）、および同じWork Itemタイプ（イシュー＞イシュー）の親子関係への対応。
• カスタムWork Itemタイプとカスタムウィジェットの実装

リンク集

• パジャマデザインシステムのワークアイテム
• ワークアイテムのエピック
• タスクロードマップ
• ワークアイテム「ビジョン」プロトタイプ
• ワークアイテムのディスカッション