dabcc607a5Adds a directory for storing meeting notes and includes the notes file for the 2026-01-07 meeting. Updates the main README to reflect this change.
65 lines
No EOL
3.5 KiB
Markdown
65 lines
No EOL
3.5 KiB
Markdown
# 2026-01-07 Transports WG (Weekly)
|
|
|
|
## TL;DR
|
|
The Transport Working Group held a structured retrospective using a card-based
|
|
voting system to prioritize discussion topics. Key outcomes included a decision
|
|
to secure high-level directional agreement with core maintainers before detailed
|
|
implementation, a consensus to converge on single proposals within the working
|
|
group to minimize noise, and a move toward using a dedicated GitHub repository
|
|
combined with Google Docs for technical discussions.
|
|
|
|
## Detailed Summary
|
|
|
|
### Retrospective Process
|
|
Larry Maccherone facilitated a "Start/Stop/Continue" style retrospective, where
|
|
participants wrote cards, grouped them, and voted to prioritize the discussion
|
|
agenda. This process surfaced four primary topics for the group to address.
|
|
|
|
### Core Maintainer Engagement & Feedback
|
|
The group discussed the need for earlier, lighter-weight feedback loops with
|
|
core maintainers rather than waiting to present fully fleshed-out proposals.
|
|
* **High-Level Alignment First:** Participants noted that the recent San
|
|
Francisco meeting successfully broke a "logjam" by allowing for alignment on
|
|
high-level direction before implementation details were solidified.
|
|
* **Avoid "Phone Books":** The group agreed that presenting massive "phone book
|
|
sized" proposals without prior alignment leads to excessive questioning and
|
|
wheel-spinning; "slicing" topics into high-level goals first is more
|
|
effective.
|
|
|
|
### Minimizing Competing Proposals
|
|
* **Convergence:** There was a strong consensus that the working group should
|
|
strive to converge on a single, unified proposal before seeking endorsement
|
|
from core maintainers.
|
|
* **Unified Front:** While individual maintainers can technically sponsor
|
|
independent SCPs, the group agreed that achieving internal consensus first
|
|
("blessing" a proposal) would increase the likelihood of acceptance and reduce
|
|
confusion.
|
|
|
|
### Location for Technical Discussions
|
|
The group debated the best venue for technical discussions, noting that
|
|
fragmentation across Discord, Google Docs, and GitHub is currently inefficient.
|
|
* **Discord:** There was general consensus that Discord is not the preferred
|
|
place for deep technical discussions due to low adoption in corporate
|
|
contexts.
|
|
* **Hybrid Workflow:** A hybrid approach is preferred—using **Google Docs** for
|
|
rapid, early-stage iteration and **GitHub** (PRs/Issues) for the official
|
|
record, history, and discoverability.
|
|
* **Dedicated Repo:** There was strong interest in establishing a dedicated
|
|
repository for the Working Group to centralize these discussions.
|
|
|
|
### Roadmap Structure & Visibility
|
|
* **Sequencing:** Participants discussed the need for better sequencing and
|
|
visibility of the overall MCP roadmap, specifically to understand how
|
|
transport changes interact with other simultaneous initiatives (like Tasks).
|
|
* **Transparency:** There was a request for more transparency regarding core
|
|
maintainer strategy and active work streams to prevent negative overlaps
|
|
between working groups.
|
|
|
|
## Action Items
|
|
- [ ] **Kurtis Van Gent:** Consult with Basil Hosmer and Peter Alexander
|
|
regarding the creation of a dedicated GitHub repository for the Working Group.
|
|
- [ ] **Kurtis Van Gent:** Draft a proposal for the "rules of engagement"
|
|
regarding technical discussions (defining the workflow between Google Docs and
|
|
GitHub) based on the poll results for the next meeting.
|
|
- [ ] **Peter Alexander & Basil Hosmer:** Bring the request for greater
|
|
visibility into core maintainer strategy and outputs back to the core team. |