Akari AMTS
メニュー

AMTS 2.0.0は、現在初期ベータの設計段階です。新しいモデルが十分に 記述・検証されるまで、安定版のAMTS 1.x仕様は変更されません。

なぜ組み込みのチーム機能が必要なのか

多くの人とアシスタントシステムが同じSpaceを継続的に更新すると、 プロジェクトやSpaceの中心的なデータへの変更が重なることがあります。 AMTS 2では、保護され統合された中核データと、各メンバーによる分散した 貢献を区別することを目指します。

Spaceとプロジェクトの責任者が正式な中核データを管理します。メンバーは、 担当する貢献領域にタスクの進捗、結果、求められた意見を記録します。 責任者はそれらを確認し、必要な内容を中核データへ意識的に統合します。

アイデンティティと責任

AMTS 2は、ローカル環境でメンバーを識別し、共有Space内の安定した公開Aliasへ 対応付けます。Aliasには、すでに公開されているGitHubユーザー名または自由に 選んだニックネームを使用できます。共有情報とローカル情報は明確に分離します。

  • 共有・同期する情報: 公開Alias、役割、Spaceおよびプロジェクトの所属。
  • ローカルのみの情報: 正式名または私的な名前、GitHubユーザー名を含む 各種アカウント名、コンピューターのアカウント名、ローカルのRepositoryパス、 端末ごとの識別情報、他のSpaceへの参照。

ローカルのAlias対応表が、既知の名前とアカウントを公開Aliasへ対応付けます。 これにより、私的な識別情報を同期せずに、タスクが現在の利用者向けか判断できます。

Spaceは責任者を指定します。各プロジェクトも責任者とメンバーを指定します。 保護された中核データを変更できるのは、その範囲で許可された人だけです。

貢献モデルの案

正確なファイル構造はベータ設計の対象です。候補の一例は次のとおりです。

members/<member-id>/profile.md
governance.md
contributions/<member-id>/
projects/<Project>/governance.md
projects/<Project>/contributions/<member-id>/

公開されるメンバー用ディレクトリには、公開Alias、役割、貢献の要約だけを 保存します。タスク、進捗、結果、フィードバックへの回答を個別に管理することで、 複数の人が同じ作業ファイルを上書きする必要をなくします。

governance.mdは、責任者、所属、保護対象の中核データ、統合ルールを記述する ための現在の候補です。ファイル名と形式はまだ正式な仕様ではありません。

タスクとGitHub Issues

タスクには1人の担当メンバー、または明示された主担当者が必要です。タスクは 対象範囲と、結果が将来どの中核データへ統合されるかを記述します。

GitHub Issuesを最初の外部タスクソースとして利用する予定です。Repository、 Issue番号、AssigneeをローカルのAlias対応表によって公開AMTS Aliasへ対応付けます。 現在の状態についてはIssueを正とし、SpaceにはAMTS固有の割り当て、結果、 統合情報の要約だけを保存します。これにより、Issue全体の古いコピーがSpace内に 残ることを防ぎます。

意見とフィードバックを求める

開始者は、特定のメンバーや役割に意見を依頼できます。依頼された各メンバーは、 自分の貢献領域に回答を記録します。開始者が結果をまとめ、自分の作業へ何を 取り入れるかを決定します。フィードバックは開始者の責任や、中核データを変更する 権限を置き換えるものではありません。

共有するタスク領域とフィードバック領域には要約だけを記録します。完全な会話は 私的なローカルChatとして保持し、明示的に共有された場合だけ同期対象のSpaceへ 加えます。

そのため、プロジェクトを開始するとき、AMTSはローカルで識別されたメンバーに 未完了のタスク、期待される貢献、フィードバック依頼があるか確認します。

初期化時の質問

初期化または再初期化では、次の内容を順番に確認します。

  1. 希望する呼び方と公開Alias、
  2. GitHubユーザー名を含め、そのAliasへ対応付けるローカルの名前とアカウント、
  3. 端末ごとのローカル識別情報とRepositoryパス、
  4. 他のSpaceへの任意のローカル相互参照、
  5. Spaceの責任者とメンバー、
  6. 既存または新規プロジェクトの責任者とメンバー。

書き込み前に、AMTSは現在のメンバーを識別し、そのメンバーのタスクと依頼を読み、 対象ファイルが本人の貢献領域か、保護された中核データかを確認します。

ルールと技術的な保護

AMTSは責任と書き込みルールを定義できますが、MarkdownのSpaceだけでローカルの ファイルアクセスを技術的に禁止することはできません。Gitを使う実装では、 保護されたBranch、必須Review、CODEOWNERSによってルールを補強できます。 他の保存システムは、それぞれのアクセス制御を利用できます。

2.0.0ベータでは、どのファイルを中核データとして保護するか、メンバーIDを Space間でどのように安定させるか、競合または放棄されたタスクをどのように 再割り当てするかを、今後さらに定義します。