docs(rfc): add RFC 000.0002 Flutter RFC Review & Decision Process - #4
docs(rfc): add RFC 000.0002 Flutter RFC Review & Decision Process#4jtmcdole wants to merge 4 commits into
Conversation
|
TODO: make sure to have wording around "no pocket vetos" |
Piinks
left a comment
Piinks
left a comment
There was a problem hiding this comment.
Big fan.
Note to follow up on:
- Current design doc page: https://github.com/flutter/flutter/blob/master/docs/contributing/Design-Documents.md
- Current design doc template: flutter.dev/go/template
- Breaking changes docs: https://github.com/flutter/flutter/blob/master/docs/contributing/Tree-hygiene.md#handling-breaking-changes
- Mentions getting fcontrib accounts for design docs: https://github.com/flutter/flutter/blob/master/docs/contributing/Contributor-access.md
| * **Subsystem Tech Leads (TLs)**: The technical leads overseeing the domains touched by the proposal. | ||
| * Flutter TLs **SHOULD** know about designs touching their systems. | ||
| * Formal sign-off requires approval from the primary Subsystem TL (or an appointed member) and affected secondary domain TLs (or their appointed members). | ||
| * **Flutter TLs Group**: The collective body of Flutter Tech Leads (`flutter-tls`). Serves as the first-line escalation path for deadlocks. |
There was a problem hiding this comment.
We could make flutter-tls a GitHub team that is taggable, assignable for reviews?
There was a problem hiding this comment.
Caveat: the members of this team would be visible.
There was a problem hiding this comment.
But not their email - just their github account? That seems "fine" given you could figure that out from PRs, comments, and social media?
| Note over Author,Forum: Stage 2: Socialization & Feedback | ||
| Author->>Repo: Async review via GitHub PR comments | ||
| opt Needs Broader Visibility / Contentious | ||
| Author->>Forum: Book 45-min Dash Forum slot (>=7 days lead time) |
There was a problem hiding this comment.
Dash Forum is only currently mentioned in the design doc page I linked above. It is only accessible by members of the org (right now, flutter-hackers), folks not in flutter-hackers (or in the future, on the contributor ladder) cannot attend or present. do we want to change this? How do we manage acces?
There was a problem hiding this comment.
If someone writes an RFC that is complex enough that it gets through some TLs - I think we'd be OK inviting said person to present at the forum. The real question is: What if they cannot or will not present? I would vote for the Shepherd to step in and make a decision on presenting or not.
Thoughts?
| 1. **Required Approvals**: | ||
| * The proposal **MUST** receive a formal GitHub PR **Approve** from the Shepherd. | ||
| * The proposal **MUST** receive a formal GitHub PR **Approve** from at least one Subsystem TL representing each secondary subsystem listed under `tags:`. | ||
| 2. **Sequential Number Allocation (Pre-Merge Requirement)**: |
There was a problem hiding this comment.
I imagine folks will deviate from this in all sorts of ways. Any linting we could do?
There was a problem hiding this comment.
I think we'll write a github action.
| * **Two-Pagers**: Projects with broader scope that consume other teams' APIs or subsystems in new ways without altering their public API/ABI contracts. These **SHOULD** be handled via GitHub Discussions or lightweight design docs with informal alignment between team TLs. Authors **MAY** optionally author these as lightweight RFCs if they seek broader community feedback, but a formal RFC is not required unless system boundaries or contracts change. | ||
|
|
||
| ### 2. MUST Require an RFC (Full Design Docs) | ||
| A proposal **MUST** go through the RFC process if it meets any of the following criteria: |
There was a problem hiding this comment.
Are there any changes to infrastructure or Flutter contributor workflows that would need an RFC?
There was a problem hiding this comment.
Yes. E.g. external embedders would be a GREAT rfc.
| * **Subsystem Tech Leads (TLs)**: The technical leads overseeing the domains touched by the proposal. | ||
| * Flutter TLs **SHOULD** know about designs touching their systems. | ||
| * Formal sign-off requires approval from the primary Subsystem TL (or an appointed member) and affected secondary domain TLs (or their appointed members). | ||
| * **Flutter TLs Group**: The collective body of Flutter Tech Leads (`flutter-tls`). Serves as the first-line escalation path for deadlocks. |
Establish the review, socialization, and decision-making lifecycle for Flutter Requests for Comments (RFCs) to disentangle high-level architectural decision-making from code review across Flutter-owned repositories. Key elements established: - Self-contained threshold criteria distinguishing One-Pagers, Two-Pagers, and mandatory Full Design Docs / RFCs. - Clear roles for Author, Shepherd, Subsystem Tech Leads (TLs), the Flutter TLs group, and Flutter Leads. - 3-stage review lifecycle: Proposal & Draft PR (AAA.000), Socialization & The Dash Forum, and Asynchronous Approvals. - Optional Final Comment Period (FCP) for cooling off without stalling uncontroversial consensus. - Pre-merge sequential numbering constraint guaranteeing that AAA.000 never lands in main and rejected designs never burn sequential numbers. - Federated escalation path to the Flutter TLs group for deadlock resolution. Fixes: #3
This is a non-blocking note right? As in "land this, and then we update all these other places"? |
jtmcdole
changed the title
3 participants
Establish the review, socialization, and decision-making lifecycle for
Flutter Requests for Comments (RFCs) to disentangle high-level
architectural decision-making from code review across Flutter-owned
repositories.
Key elements established:
and mandatory Full Design Docs / RFCs.
TLs group, and Flutter Leads.
& The Dash Forum, and Asynchronous Approvals.
uncontroversial consensus.
never lands in main and rejected designs never burn sequential numbers.
Fixes: #3
Stack created with GitHub Stacks CLI • Give Feedback 💬