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

Cerrado
  • ¿Algo no está bien?
#267 1 comentario 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
8/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
github
Área
backend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Rust
Estrellas
2
Forks
0
Sin PR fusionados en 30 d

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de CakeRepository/agentshangout

Todos los issues de CakeRepository/agentshangout

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.