Background:
Last week:
- Let's review what we have done and what's remaining. What improvements can we realistically put in place before we start reviewing the next RFC(s)?
- Merge PR with metadata field changes
- In flight PRs will get updated
- Action: Previous PRs will have their outcomes and numbering updated
- Between stages PRs are closed, not merged. They only get merged at the end.
- Action: review readme to make sure merged/closed is documented correctly
- Clarify draft review stage - meant to be exploratory and get small group detailed feedback from domain experts
- We stopped our process review at the draft stage, pick up there next time we discuss
Today:
Meeting Notes today:
The RFC Lifecycle
We have a pull request in draft status. Jenn will mark it for review.
Copy of RFC process
"domain experts are giving feedback to improve it or refine it"
Can we reject it ?
Not a single expert should be able to reject it. The TC needs to vote about it.
We could call it a "stop" rather than a "reject". It's an iterative process.
If the TC thinks that this is never going to "fly", it will not pass the preliminary review state.
We should accelerate the first step. We should get done with the preliminary state very quickly.
In the past 2 or 3 persons gave feedback and then we voted.
People only look at the details once it is in the PR stage.
The question of "any merit of the RFC" is a very low bar and could be done very quickly.
The preliminary review starts when the submitter does the elevator pitch in the TC meeting. The prelimiary review stops after 8 days.