2023-04-05 Meeting notes



Discussion items

1 minScribeAll

Jeremy Huff is next, followed by Marc Johnson 

1 minTCR Board Review


Nothing new
5 minCC / PC Updates

Any updates from the PC and/or CC?

CC: No meeting since the last TC.

PC: No meeting since the last TC.

10-15 min

Technical Council Sub Groups Updates



  • Revisit the "Distributed vs Centralized Configuration" subgroup - reform with a new set of leader.  Review and adjust deliverables/goals as needed, etc.
  • Form a subgroup to review the Developer Onboarding documentation and update as needed.
    • Wait until after elections?


  • Translation Subgroup: the group has been closed/archived

AWS: Maccabee Levine a first meeting is on the calendar

Distributed vs Centralized Configuration: Craig McNally we will need to find a new leader for the Distributed vs Centralized Configuration subgroup Radhakrishnan Gopalakrishnan will need a replacement. No volunteers were forthcoming. We might defer finding a leader until after the elections. Vijay's name was removed. We will revisit this next week.

Onboarding documentation: Craig McNally Should we wait on forming a group until after the elections? Jenn Colt Should we create a documentation subgroup? We may not want to have a standing subgroup. Craig McNally Feels that we should have shortlived well-defined subgroups. Maccabee Levine maybe this should be a subgroup to the documentation sig. Jenn Colt That group is mostly focused on docs.folio, which has high overhead. Do we have two classes of documentation? The TC sidebar needs cleanup, which Radhakrishnan Gopalakrishnan started, maybe we should have a subgroup for cleaning up our wiki presence?

Craig McNally A subgroup may be overkill for updating the wiki presence

Marc Johnson is in favor of case-by-case volunteers to clean up the sidebar. He also does believe that we do have multiple forms of documentation, docs for those who use FOLIO, and another for those who contribute to it. Docs.folio is not aimed toward contributors.

Jeremy Huff maybe we should ask a volunteer to approach the documentation sig and ask if they have the capacity for onboarding documentation. Maccabee Levine volunteered for this, he agrees that it is important to reach out to these groups. 

Craig McNally if we are going to do the work, we might as well track it as a subgroup, Maccabee Levine has become the owner of the onboarding documentation subgroup and will be reaching out to find additional members.

Tod Olson there is a documentation-wg slack channel, and it seems like it is a subgroup of the support sig. They maybe an additional place to start when reaching out.

5-10 minRFCsAll

Last week:

  • Olamide Kolawole Some discussion/comments in the RFC. Olamide is able to resolve the comments. Julian Ladisch is in vacation, and Olamide will present in one of the next TCs


Craig McNally will reach out to Olamide Kolawole for an update on this

15-20 minTCR Process Improvements

Review slide deck: Jeremy Huff this will be deferred until next week.

1 minTechnical Goals & Objectives

Goal: wrap up this effort/working group.

What needs to happen to get us there?

Tod Olson - All we need is votes on whether to accept the documentation. Asked people to read on and give their votes. 


  • "Periodically revise" → how often?  1-2x? per year?  Quarterly? 
  • Jeremy Huff raised concern over the list including things that aren't very clear.  "feels like we're signing a blank check"
  • Marc Johnson provided the history of this effort and clarified that we don't have a good way to prioritize these things
  • Jenn Colt maybe we could accept this as-is, but immediately start a group to go through the list and capture the status of each item.  Also note that the charter revisions mention this type of planning/vision work.
  • Do we really want to start another subgroup?  How do we prevent that group from falling into the same trap (working on this forever)?
  • Voted to accept the document in its current form and start a conversation about the next steps, e.g. how to use this document.


Tod Olson felt that we had decided to let it sit for a time before forming a new group to work on this again.

leemarci@gvsu.edu if we do leave it, we should put something on the calendar to remind ourselves to do this. Also, what do we hope to learn from waiting?

Craig McNally is hesitant to form another group quickly and wants to wait and see how/if it becomes useful 

Tod Olson Points out that it has an expressed purpose to be used in the context of discussions and is to be periodically updated.

Marc Johnson When are we going to decide about this, if we do not plan on updating it, then it is like we are abandoning it

Tod Olson What about putting a date in the calendar for after the elections to do a check-in on the document with the new TC.

Craig McNally let's set a date for the end of the summer, the date was set for September 20th.

10 minOnboarding DocsAll

Reminder on our calendar to review and update onboarding documentation.  How shall we proceed?


5 minUpcoming meetings
  • TC dedicated discussion:   11:00 AM ET
    • Topic:  Breaking changes RFC
    • Q:  Will the Easter holiday be an issue?  Maybe defer this until  
  • FOLIO Chairs meeting:   
    • Will probably focus on agenda for the next Tri-Council meeting (see below)
  • Tri-Council meeting:   9:30 - 11:00 AM ET
    • Agenda:  2023-04-13 Tri-Council Meeting (WIP)
    • We need to pull together an update for the other councils (what we've been doing since last Tri-council meeting in January)
      • Craig McNally will write a summary.  We will review on


Craig McNally Breaking changes will be discussed on Monday, the 10th

Craig McNally The goal of the chair's meeting will likely be to fill out the agenda for the tri-council meeting.



Craig McNally changes are being made to this list without the TC being consulted

Jeremy Huff maybe we should put a disclaimer at the top of the document that stated that the TC is responsible for updating that page

Craig McNally That may work, but it does not address all of the concerns. Maybe we need a reminder to create new pages for new releases

Florian Gleixner Maybe we should add a header that expresses the status, instead of "draft draft draft" Marc Johnson agrees. 

Marc Johnson The versions are likely to change over time, so we need a process to support that

Jeremy Huff There are multiple purposes behind this list, which leads to differing levels of granularity

Craig McNally The differences are present in places where it is important to the build processes

Marc Johnson Some of these differences are due to different people editing this. We should put controls in place for editing

Craig McNally We can put a disclaimer that says don't edit this page, leave a comment instead

Jeremy Huff The granularity of the spring modules is excessive for the purpose of new module technical evaluation but may be needed for other purposes. This posses a conflict.

Craig McNally Maybe we can change the presentation and use verbal framing to avoid this conflict

Marc Johnson Agrees with Craig's suggestion, as does Jeremy Huff 

Craig McNally We should:

      1) add a section at the top with some clarifying comments on how this is used and updated

      2) Change the wording of the spring module enumeration to imply that the modules listed are examples

      3) Add dates to our calendar to create new pages for each release

Florian Gleixner volunteers to make a draft header for the next meeting 

Tod Olson Would we also want to be explicit about the purposes of this document? Craig McNally yes

Topic Backlog

?Officially Supported Technologies - UpkeepAll

A process was proposed for how to keep these pages up-to-date, we need to revisit and put some processes into place.  As it stands right now, we have members of the community making changes w/o consulting the TC.

Action Items

  • When we look at RFC process again we should review comm protocols Marc Johnson