2024-07-24 RFC Process Continued

Owned by Craig McNally
Last updated: Jul 24, 2024 by Jenn Colt
3 min read
Translator


Date

Attendees 

Discussion items

TimeItemWhoNotes
1 minScribeAll

Tod Olson is next, followed by Jason Root

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 minEureka RFCsAll

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 minRFCs in the wikiAll

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 template: Jenn Colt
  • RFC parent page with process, template, RFCs underneath
    • Craig McNally will set up the page hierarchy
      • parent has tldr, other pages underneath it
  • 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
  • Use a wednesday to update process doc Jenn Colt Craig McNally will schedule
Time PermittingAdditional RFC process feedback Tod Olson

From Tod in slack:

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
NAZoom Chat