- 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
- Continue reviewing the draft process documentation adjustments. See Copy of RFC Process
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.
We have never rejected anything that went this far.
There hasn't been too much feedback in the public review stage. Most people have already given their feedback before.
Domain experts don't have the attitude to bring it to public review.
We could change "draft review" to "draft refinement (stage)" or similar
Will people really be comfortable with this 1 week period ?
One could still raise one's objections in the public review stage.
We don't need to vote
Public review
RFCs of non-technical nature will not be raised, but if there is non-technical feedback to a generally technical RFC, that's O.K.
Marc Johnson: Folks are right that I have concerns about the combinatorial complexity in FOLIO. And whilst I accept expansion in that area for transitional purposes. Those options tend to hang around afterwards. This is where the refresh tokens is different to the Kafka changes, because the former has a plan to remove some of the options / paths, whereas Julian’s feedback on Kafka led to perpetually having two completely different configuration options.
I have similar concerns with apps and modules co-existing in perpetuity
Jenn : It would be interesting to know if these types of concerns could be addressed at all via the ‘platforms’, like is what kafka config is used part of a platform definition?
Marc: Possibly, that probably depends upon the details of each proposal.
The Kafka options are potentially messier because they can vary at the module level and is independent of the choice of combination of modules (which is all platforms are AFAIK)
--
Announcement will be made depending on the issue. The Kafka topics will be announced in the Kafka channel.
Topics which touch installation will be posted to the SysOps channel.
Some of these things could also happen in small groups. Making the small group as good as possible seems like where TC should spend time.
Some things are really a community council things, like the AWS questions.
The TC should list a few groups as appropriate for the topic for the RFC, like SysOps or DevOps or a dev team.
Some are product wide, like the application RFC, translations as well. The will have a different "rhythm" than the date format. The RFC portion should be the broad thing.
Marc: Translations is a good example here. Any technical solution really relies on a good understanding of the product needs.