2023-10-18 - RFC Process Improvements

Owned by Craig McNally
Last updated: Oct 18, 2023 by Ingolf Kuss
5 min read

Date

Attendees 

Discussion items

TimeItemWhoNotes
1 minScribeAll

Marc Johnson is next followed by Ingolf Kuss (Jeremy is actually next, but he is unable to attend Wednesday meetings.  He will be next on Monday)

*

RFC Process Improvements

All

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.

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)

--
Annocunement will be made dpending 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.

NAZoom Chat

Anuar  to  Everyone 11:17 AM
Hi everyone. Sorry for being late 

Maccabee Levine 11:18 AM
Hi and nice to meet you!

Anuar 11:24 AM
Likewise 

You  to  Everyone 11:27 AM
Welcome Anuar!

Marc Johnson  to  Everyone 11:27 AM
The breaking changes RFC was an outlier anyway because most of the vocal folks in the TC had been involved in writing it

You  to  Everyone 11:27 AM
JFYI Anuar is serving as Tara's proxy today, and likely next week too

Marc Johnson  to  Everyone 11:27 AM
I’d also be inclined to move it to public review even if I disagree with the details

Maccabee Levine  to  Everyone 11:30 AM
I am all for giving feedback during the draft review.  I was saying I might vote to approve even if I think *others* (i.e. public) might object at that later stage

Maccabee Levine 11:30 AM
And then I might ultimately vote not based on that public feedback.  (Or not)

Maccabee Levine  to  Everyone 11:32 AM
++ Draft Refinement

Marc Johnson  to  Everyone 11:37 AM
That’s what I meant when I said I’d proceed to the public review and raise the concern there

Marc Johnson  to  Everyone 11:43 AM
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 Colt 11:45 AM
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 Johnson 11:48 AM
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)

Maccabee Levine  to  Everyone 11:44 AM
In "Draft Refinement" TC might still need to vote, just to indicate that we're ready for public review

Marc Johnson 11:44 AM
Like the TCR, the group provides a recommendation, the TC signs off

Marc Johnson  to  Everyone 11:46 AM
Reference implementations are where I get the “development starts before the RFC is approved” concern from

Jenn Colt  to  Everyone 11:50 AM
Some of that should happen during small group recruitment too

Marc Johnson 11:52 AM
Maybe we should add that as part of draft refinement?
That the group should represent the impacted audiences

Jenn Colt 11:52 AM
Step 3 kind of says it

Tod Olson  to  Everyone 11:53 AM
That sounds right, make the announcement at every stage and be clear what stage the RFC is at.

Marc Johnson 11:54 AM
That relies on the audiences understanding what they are expected to do at each stage

Jenn Colt  to  Everyone 11:55 AM
Making the small group as good as possible seems like where TC should spend time

Maccabee Levine  to  Everyone 12:00 PM
Sorry I have to drop off, another meeting

Marc Johnson  to  Everyone 12:00 PM
Translations is a good example here. Any technical solution really relies on a good understanding of the product needs

Action Items