[AI] Follow up on 1.3 retro feedback

[shawnalpay]

Detailed Description

We conducted an in-person FOCUS meeting on Oct 22, 2025 in Washington, DC, as collected by Retrotool and collated on #1484 in this comment.

We will conduct another retrospective in a future Members meeting.

Definition of Done

• Consider and respond to all feedback provided in the retrospectives, especially those that have significant +1's.
• Share the responses to feedback (pasted directly as a comment, not linked to a spreadsheet) here.
• Share with the working group via the #working-group Slack channel and email.

[jpradocueva]

Content extracted from FOCUS Maintainers + Steering Committee meeting, Washington, October 22, 2025.

• See meeting minutes FOCUS_Maintaienrs_SC_Washington_20251022 - Topic - 1.3 Restrospective

Topic – 1.3 Retrospective

Documents:

• Retro Tool summary
• FOCUS Spec prioritization spreadsheet
• Discussion references to conformance validator and performance validator
• JSON requirements file and proposed requirements viewer (no direct link)
• Various feature requests related to invoicing, contract amendments, data generators, and migration guidance (no direct links)
• Mentoring and onboarding program documentation (implied)

Context

The group ran a structured retro (Start/Stop/Continue) at the close of the v1.3 cycle. Discussion centered on release-management friction (cadence, breaking changes, migration paths), workload/ownership (maintainer bandwidth, TF throughput), quality gates (topic readiness, sample data, validator parity), collaboration hygiene (contentious topics, asynchronous inputs, time zones), and adoption enablement (provider conformance visibility, examples, marketing, requirement viewer/JSON).

Start

Limit Maintainer sponsorship of Feature Requests to 2 (Shawn Alpay) — (+5)

• Context: Multiple maintainers held several prominent FRs; risk of burnout and diffusion of focus.
• Summary: Group generally agrees owning more than two FRs is challenging. One-at-a-time is ideal, with exceptions for interrelated FRs. Highlighting limits can expose resource gaps so the group can recruit help instead of overcommitting.
• Possible solutions:
  • Set a hard cap of 2 FRs per maintainer; prefer 1 when possible.
  • Surface unstaffed FRs to the broader community to attract contributors.
  • Use limits to make gaps explicit and drive targeted recruiting.
• Action points: Evaluate resource constraints when maintainer bandwidth is limited; proactively broadcast unstaffed items to solicit volunteers.

---

Limit number of FRs actively worked per Task Force to 2 (Shawn Alpay) — (+3)

• Context: Too many simultaneous FRs diluted discussion and focus.
• Summary: For 1.3, priority existed but execution still began on too many items at once. Suggest limiting active work-in-flight to two per TF while still assigning more for backlog ordering.
• Possible solutions:
  • Maintain a prioritized backlog but enforce WIP limits (2 FRs) per TF.
  • Consider capacity expressed as effort budget per TF and track in project views.

---

Come with mock-up data to discussions (Letian Feng) — (+4)

• Context: Philosophical debate without concrete rows/columns slows progress.
• Summary: Anchor conversations in sample/mock data that reflect real practitioner queries and end products (“working backwards”).
• Possible solutions:
  • Require example datasets as a precondition to deep solutioning.
  • Provide a sandbox plus provider-native & latest FOCUS export samples to bootstrap examples.

---

Context into a topic should hit a minimum bar for release (Christopher Harris) — (+3)

• Context: Complex areas (e.g., SaaS) progressed with limited SME breadth.
• Summary: Avoid moving forward without sufficient domain expertise and representation.
• Possible solutions:
  • Define a minimum bar (e.g., X vendors with relevant features/interest).
  • If SME coverage is thin, de-scope or delay the item.

---

Advanced communication on breaking changes with samples (Sarah McMullin) — (+3)

• Context: Adoption suffers without early notice and concrete examples.
• Summary: Align release cadence and messaging with industry expectations for data contracts. Provide samples and advance notice of breaking changes.
• Possible solutions:
  • Explore semantic versioning and clearer backwards-compat definitions.
  • Issue candidate releases every six months with “go/no-go” for finalization.
  • Distribute breaking-change samples early; coordinate with providers.

---

Sample data available from each provider’s native & most recent FOCUS exports (Karl Kraft) — (+3)

• Context: Some members spend time anonymizing/building data; standardized samples would accelerate examples and conformance.
• Summary: Maintain per-provider sample packs for both native and FOCUS datasets.
• Possible solutions:
  • Use conformance/sample data pipelines as the entry point to source and curate example data by version.

---

Include a meeting time option outside US hours (Karl Kraft) — (+2)

• Context: US-centric scheduling limits global participation.
• Summary: Balance inclusivity and efficiency.
• Possible solutions:
  • Rotate meeting times to “share the pain.”
  • Increase asynchronous collaboration (with the caveat it can be slower).
  • Use Slack channels/polls to gather input, while keeping decisions in WG meetings.

---

Real-time written summaries during contentious topics (Larry Advey) — (+2)

• Context: New/less-informed participants struggle to track complex debates.
• Summary: Require perspective write-ups (one-pagers) for opposing views and share 24 hours in advance.
• Possible solutions:
  • Assign opposing parties to produce brief write-ups; conduct silent read at start.
  • Deadline those artifacts 24 hours before the meeting and tie them to the published agenda.
• Action points: Contentious topics need write-ups for the next TF to share out (24 hours in advance).

---

Conformance validator developed in parallel with spec (Jason Wu) — (+2)

• Context: Validation should be available at release, per column/PR.
• Summary: Foundation validator exists; plan is to ship 1.3 & 1.4 validators alongside 1.4 release.
• Possible solutions:
  • For each approved column/PR, ensure a validator rule exists by release time.

---

Publish provider conformance reporting (George Parker) — (+2)

• Context: Visibility into who publishes what drives adoption and planning.
• Summary: Maintain a public matrix of publishers, supported versions, and links to gap reports.
• Possible solutions:
  • Host a matrix on the website; include version, coverage, and gap links.

---

More external marketing & enablement (George Parker) — (+2)

• Context: Awareness is low, especially among SaaS vendors and internal stakeholders.
• Summary: Increase evangelism (blogs, podcasts, LinkedIn cadence) to generate pull.
• Possible solutions:
  • Regular LinkedIn posts, blogs, and whitepapers targeted to emitters/vendors/practitioners.

---

Provide data-generator-to-FOCUS column mappings (Matt Cowsert) — (+1)

• Context: Practitioners and data generators need clear mappings.
• Summary: Useful enablement artifact; also discussed in conformance context.
• Possible solutions:
  • Produce mapping guides by provider/tool and version to reduce friction.

---

Define more granular milestones within the release (Shawn Alpay) — (+1)

• Context: 1.3 was better than 1.2; end-of-cycle logjams still occurred.
• Summary: Add more intermediate milestones to spread approvals and maintain momentum.
• Possible solutions:
  • Earlier draft → review → approval gates; explicit checkpoints to avoid end-loading.

---

Tie discussions to examples; pause if no example (Shawn Alpay) — (+1)

• Context: Avoid “philosophy talks.”
• Summary: If no data/example, pause and return with concrete rows/columns.
• Possible solutions:
  • Make examples a pre-req for specific debates.

---

More clarity/transparency into how/why topics are picked (Christopher Harris) — (+1)

• Context: 1.3 was metrics-driven; add qualitative rationale.
• Summary: Provide quant + qual justification for topic selection.
• Possible solutions:
  • Publish a brief rationale per selected topic beyond the metric scores.

---

Stand up a data generator community (Shawn Alpay) — (+1)

• Context: Need a targeted forum for conformance/enablement questions.
• Summary: Explore a community for vendors/tools that generate or present FOCUS data (mindful of antitrust).
• Possible solutions:
  • Consult LF Legal on structure; consider limited-scope working sessions focused on conformance and migration guidance.

---

Set “AI” due dates 24 hours before meeting (Fantastic Gopher) — (+1)

• Context: Last-minute prep hurts meeting quality.
• Summary: Tie artifact deadlines to agenda publishing (≥24h).
• Possible solutions:
  • Close agendas days in advance; require supporting material at agenda finalization.
• Action points: Tie action-item due dates to the published agenda; enforce ≥24h pre-read availability.

---

More whitepaper/async comms for complex topics (George Parker) — (+1)

• Context: Pre-reads improve meeting productivity.
• Summary: Circulate short whitepapers a couple of days before meetings to frame decisions.
• Possible solutions:
  • Require 2–3 page pre-reads for major/contested topics and schedule silent read time.

---

Dedicated time or TF for process improvement (Michael Flanakin) — (+1)

• Context: Process ideas surface but don’t always stick.
• Summary: Allocate explicit agenda time to apply and track process changes.
• Possible solutions:
  • Add a standing “process improvement” slot to member/TF agendas; track in GitHub.

---

Define/measure release success KPIs (Sarah McMullin)

• Context: Validate that releases achieve intended outcomes.
• Summary: Partner with data generators to gauge real-world impact.
• Possible solutions:
  • Co-define release KPIs with vendors (e.g., adoption, conformance coverage, migration time).

---

Use a Requirement Viewer based on JSON requirement file (Joaquin Prado)

• Context: JSON requirement artifacts now exist per merged PR.
• Summary: A viewer enables programmatic analysis (conditions, criteria, dependencies), helping developers implement faster.
• Possible solutions:
  • Socialize the JSON viewer; integrate into developer enablement flows.

---

Break FRs into an execution plan but keep under one FR (Fantastic Gopher)

• Context: Complex FRs were scoped out late.
• Summary: Divide & conquer within a single FR to keep context while delivering incrementally.
• Possible solutions:
  • Maintain a plan with sub-milestones under the parent FR; revisit regularly.

---

Quality over quantity; partner up on FRs (Fantastic Gopher)

• Context: Pairing improved outcomes (e.g., Karl & Q in 1.3).
• Summary: Encourage co-authoring and early/continuous feedback (pair-programming style).
• Possible solutions:
  • Pair maintainers on complex PRs; solicit feedback before leaving draft.

---

Formalized discussion with providers on blockers to adopting new versions (Happy Jaguar)

• Context: Adoption feedback is ad hoc; need quantifiable insight.
• Summary: Establish a formal mechanism to learn provider blockers without demanding roadmaps.
• Possible solutions:
  • Lightweight surveys or structured sessions to capture “why not this version/feature?”; feed into prioritization.

---

Stop

Debating semantics without concrete data (Matt Cowsert) — (+4)

• Context & Summary: It’s a time/energy sink; stop early and require written proposals/examples.
• Possible solutions:
  • Cut short circular talk; request written proposal + data for next meeting.

---

Chasing new areas without hardening quality of existing spec (Christopher Harris) — (+4)

• Context & Summary: Risk of going “wide” too fast; ensure quality and adoption of current areas first.
• Possible solutions:
  • Balance gap-closing with frontier pushing; apply consistent quality bars across new and returning items.

---

Circular debates without a path to resolution/action (George Parker) — (+2)

• Context & Summary: Lack of decision framework fuels loops.
• Possible solutions:
  • Use pro/con notes, opposing write-ups, and pre-reads; identify decision criteria upfront.

---

Bulk of release work falling on longest-serving members (Christopher Harris) — (+2)

• Context & Summary: Onboarding barriers hinder distribution.
• Possible solutions:
  • Buddy-Mentor program, office hours, targeted expert invites for limited engagements; clearer enablement packs.

---

Frequent release cycle (Jason Wu) — (+2)

• Context & Summary: Multiple versions across vendors cause integration/migration strain; backward compatibility definitions unclear.
• Possible solutions:
  • Revisit cadence; tighten backwards-compat definition and apply semantic versioning; differentiate internal milestones vs. external provider milestones.

---

Toxic communication within debates (Christopher Harris) — (+1)

• Context & Summary: Passion sometimes crosses lines; impacts participation.
• Possible solutions:
  • Re-establish debate norms (invalid arguments list/principles); strong facilitation to enforce tone and focus.

---

Continue

Bring new contributors into the fold (Buddy-Mentor, intro calls) (Matt Cowsert) — (+9)

• Context & Summary: Early days, but critical for long-term health.
• Possible solutions:
  • Keep office hours, mentorship, and onboarding touchpoints; consider opt-out calendar holds.

---

Advocate for more ways new members can join/participate (Christopher Harris) — (+6)

• Context & Summary: Remove barriers; scope limited engagements.
• Possible solutions:
  • Invite topic-specific SMEs for limited time; publish clear how-to for repo/navigation.

---

Keep thinking about backwards compatibility (George Parker) — (+5)

• Context & Summary: Needs rigor and shared definitions.
• Possible solutions:
  • Define what “backwards-compatible” means; use comparative checks across versions; apply SemVer policies.

---

Project management in GitHub (Shawn Alpay) — (+3)

• Context & Summary: Big upgrade over sheets; some companies block certain tools.
• Possible solutions:
  • Keep PM in GitHub; be mindful of tooling access constraints.

---

Make our work more accessible to new members (George Parker) — (+3)

• Context & Summary: Office hours and reminders help reduce intimidation.
• Possible solutions:
  • Slack reminders, focused emails, and pre-reads to lower the activation energy.

---

Meeting 4Ps & facilitation to keep calls on track (Larry Advey) — (+2)

• Context & Summary: Strong facilitation keeps focus and pace.
• Possible solutions:
  • Maintain 4Ps; consider brief roundups at member meetings as the single “one-stop” update.

---

Focused emails on what to review/feedback (Sarah McMullin) — (+1)

• Context & Summary: Complements GitHub AIs and improves clarity.
• Possible solutions:
  • Continue targeted emails with explicit asks.

---

Break work into smaller chunks to boost velocity (Matt Cowsert) — (+1)

• Context & Summary: Helps avoid end-cycle logjams and eases async.
• Possible solutions:
  • Reflect sub-scoping in 1.4 planning and milestone structure.

---

Chase down provider columns to drive conformance (George Parker) — (+1)

• Context & Summary: Knowing provider custom columns highlights gaps.
• Possible solutions:
  • Consolidate provider custom columns to identify theme gaps for future scope.

---

Coordination between Shawn, Matt, Joaquin on 4Ps

• Context & Summary: Visible benefit in 1.3; keep it going.
• Possible solutions:
  • Continue cross-lead coordination and progress tracking.

---

Additional notes raised during the retro (not in the original bullets)

• AI-readable future versions: Ensure spec/data structures are AI-friendly, enabling querying against datasets and mapping to use cases.
• Agenda hygiene & deadlines: Close agendas days in advance; require supporting material at agenda finalization; enforce ≥24h pre-reads.

---

Consolidated Action Points

• Resource constraints: Use sponsorship/WIP limits to surface gaps; recruit targeted help.
• Migration plan: Provide provider-specific + common migration guidance, samples, and clear backward-compat definitions (consider SemVer).
• Constrain TF throughput: Enforce 2 active FRs per TF (WIP limit) or an effort budget; keep a prioritized backlog.
• Contentious topics: Require written perspectives and pre-reads 24h+ in advance; tie due dates to agenda publication.

---

[shawnalpay]

We will conduct a Members retro on Nov 6, and then we will conduct an internal meeting next week to synthesize themes across the retros and form a response plan to share back with the working group.

[Matt-Cowsert]

We will push the members retro to this week 2025-11-13, as we didn't have sufficient attendance to conduct a 1.3 retro on 2025-11-06

[shawnalpay]

Setting new due date to Nov 24, to give us a week to synthesize feedback and present back to the Maintainers next week. Internal meeting scheduled for Nov 20.

[shawnalpay]

@Matt-Cowsert Can you please:

• Share the responses to feedback (pasted directly as a comment, not linked to a spreadsheet) here?
• Share with the working group via the #working-group Slack channel and email?

Then we can close this issue. I have modified the definition of done to include these items.

Pushing out due date to Nov 28.