Connect rooms to public GitHub work: issues, PRs, participants and impact

クローズ
  • 何か問題がありますか？
#267 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
8/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
活発
技術スタック
github
領域
backend

調査の方向性

This is a design draft, not a code task, and the payload names no files, tests or entry points. Read the related issues #253, #256, #263, #264 and #265 first, then find the existing board and repository linking code the draft says to reuse. Done means the scope is confirmed by product review and split into small, separately reviewable PRs, not that anything is built here.

索引モデルが issue の本文から書いたものです。

説明

Goal

Make GitHub collaboration the next product step after #256: help people see issues/PRs, who is working on them, who is affected, and where to coordinate. Justin identified GitHub work as the highest priority. This records the draft developed with mac in Deep Space; proposed details below still need product review before implementation.

Proposed first increment

  • A project/place owner explicitly links one public repository. Reuse existing board/repository linking capabilities where possible rather than adding parallel stores.
  • Show a room work board with issue/PR number, title, state, source URL and last refresh. For PRs show verified CI and review-request/review-result state from GitHub.
  • Distinguish source facts (GitHub author, assignees and requested reviewers) from voluntary local claims. Do not equate appearing on a PR with working together or endorsement.
  • Add explicit claim/unclaim and optional pairing participation with timestamps. mac suggested a four-hour claim expiry; treat that as a proposed default requiring review, not an established rule.
  • Let owners map public labels to product areas. Any watcher/notification feature must be explicit opt-in, scoped to recipients/rooms, deduplicated and easy to stop. Do not infer personal impact from identity or membership alone.
  • Keep GitHub mutations, automated merge/deploy, badges and furniture unlocks out of this first increment.

Architecture and boundaries

  • Begin with a bounded read-only GitHub ingestion path and documented cache/staleness/rate-limit behavior. Respect actual authorization; public repo data does not make private room activity public.
  • MCP event delivery in #264 is outbound to clients and is NOT a GitHub inbound webhook implementation. If inbound GitHub webhooks are added later, specify and authorize them separately.
  • Local claims/pairing/room links are writes even though GitHub access is read-only. Apply normal server-side ownership and room permissions.
  • No new credentials or persistent access should be created as an implicit side effect of viewing a board.
  • Keep the data model useful to the portable MCP App proposed in #265 without making either feature depend on camera work.

Acceptance criteria

  • A user can find an issue/PR, see its verified state and source, identify explicit contributors/claims, and open the relevant coordination room.
  • No duplicate pins/cards on refresh; closed/merged/renamed/transferred/deleted source items are handled with provenance.
  • Refresh failures and rate limits show stale/unknown state, not false green CI or missing work.
  • Permissions prevent room membership/private participation leaking through public repo links or other rooms.
  • Claims, expiry and pairing are explicit and reversible; watcher notifications require opt-in and do not create bot mention loops.
  • Small, separately reviewable PRs with docs/tests; exact scope confirmed before new GitHub access or notification subscriptions.

Related: #253/#256 profile identity/display foundation, #263 mention guidance, #264 OAuth MCP events, #265 interactive MCP App. This issue is a collaboration specification draft, not a claim that these features are already implemented.

主要言語
Rust
スター
2
フォーク
0
30日以内にマージされた PR はありません

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

CakeRepository/agentshangout のほかの issue

CakeRepository/agentshangout の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。