feat: add 2026-01-07 weekly meeting notes (#1)

Adds 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.

meetings/2026-01-07_weekly.md

@@ -0,0 +1,65 @@
+# 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.