Jenn Colt will take notes today since Tod will be late.
Reminder: Please copy/paste the Zoom chat into the notes. If you miss it, this is saved along with the meeting recording, but having it here has benefits.
5 min
Eureka RFCs
All
Notes from last week:
Craig: Is the RFC format appropriate for this big change, or could it have been split into smaller RFCs with an overview document for all of them?
Jenn: Supporting diagrams are helpful. Other option: Overview RFC linking to detailed documentation.
Marc: RFCs can be used to have the discussion and investigating different solutions before the implementation starts; Eureka decisions and development has started before the RFC was created allowing for only yes/no decision.
Jason and Marc: Both ways are possible.
Jenn: Even if it's only yes/no decision the RFC process explains the reasons why the solution has been chosen and explains the details.
Marc: Eureka and Application Formalization might be independent decisions.
Craig: Wonders whether putting more details into the RFC text help the RFC process or is too much information.
Tod: Would like a high level RFC about Eureka. All low level details should be separate, whether as RFCs or in other form.
Marc: Most feedback is from TC members only. SysOps are trying to install Eureka.
Marc: mod-lists has been accepted before the architectural change RFC has been created. Eureka has huge architectural consequences so we should be careful.
Craig: I can provide an overview RFC. Whether to go this way should be decided by TC on Monday.
Meeting runs out of time. All following topics are moved to next Wednesday.
Today:
If we have a quorum, we should try to make this decision today. Otherwise we can aim for Monday .
DECISION: Craig will move forward with the overview RFC
30-45 min
RFCs in the wiki
All
Adapt the RFC process to use the wiki
GH has ability to limit who/when to have comments. In the wiki some things may also be able to be restricted.
Aligns with dev docs moving to wiki
Restrictions, moving pages, may help with controlling interactions when needed
What to do with current GH?
Migrate and retire?
Move the narrative, etc
Stub for existing RFCs in the wiki that link out to the full RFC
New things go on the wiki
What does the decision record vs the RFC represent?
Will need space in wiki, template, archive, etc
Where on wiki?
Rethink metadata?
Tracking outcome, status
PR info no longer needed
What can change if RFC and DRs are both in the wiki?
Not having to DRs might be more efficient but need to be able to 'freeze' RFCs like we do DRs
Live under RFC Process? Rather than create new space. People can watch RFC pages but not a way to watch all RFCs but that might be okay. See if it becomes an issue.
Process page might be able to be streamlined as complexity decreases
Can revise the process page to include a tldr like the GH readme has if needed
Update process document after doing the other steps
Update process to remove DR step
Might want to come back to a general review of distinction between decision process and RFC process. questions of scope & granularity? how similar is the metadata?
General guidance at bottom of RFC process page needs a refresh
I think we want to be clear about what kinds of communication and coordination we need to facilitate. That is, what kinds of agreements do we need about how FOLIO behaves at the technical level. And where have we had problems because of not having common agreements or breaking those agreements.
Notes:
What is covered by FOLIO technical governance and needs an RFC?
Want the remit to be as small as possible without causing problems, only cover the things that cause problems if they don't line up
Could lead to fewer RFCs
DRs were maybe a hack to cover things that are important but don't warrant RFCs
Some might get refined again
DRs process was intended to be more lightweight than what are RFCs are
For now have DRs still, RFCs just don't ouptut DRs