Zak Burke advised that the evaluation of ui-service-interaction should be ready for TC review next week. ..So far, only some accessibility limitations have been encountered. Maccabee Levine is shadowing this review
There was a brief discussion about the funding proposals from TC and PC; they were initially focused only on the joint TC/PC Community Developer Advocate proposal which Alexis, Owen and I recently updated, but I reminded them there were several others as well submitted by the two councils. CC has not made progress on defining a process to consider them but recommitted to doing so before the next meeting. And it sounds like they will meet at WOLFcon to consider the proposals specifically.
List App: EBSCO heard from a lot of former Innovative Interfaces customers that they really wanted actionable lists, the List App is being developed, to be offered to the community. Technical presentation to be made to the TC. Expect review requests to PC and TC
WOLFcon planning update: 56 proposals as of meeting time, room for some more.
Tomorrow: Browser support statement will be a topic in PC. Have already introduced in Slack, expect PC to discuss and vote tomorrow.
updates Updates from CSP group:
...Review of various issues (mostly security) for inclusion in upcoming service packs
Development freeze for Poppy was yesterday, so migrating all modules to Java 17 will not work for Poppy, but support for Poppy runs longer than Java 11 support.
Marc Johnson Merging Poppy and Quesnelia may be rather skipping the release schedule for Poppy and the next Release will still be named Poppy, but it is not clear and confusing. This affects updating the officially supported technologies page.
Craig McNally proposes to update the DRs scope to "the release happening toward the end of this year". After some discussion, changed to "For the release happening in Fall/Q4 2023 (release name to be added later) all java-based FOLIO modules must be implemented using Java 17, and the use of Java 11 for FOLIO modules is no longer acceptable."
The TC accepts the DR using lazy consensus.
Today:
jroot advised that there was no meeting for the breaking changes sub-group yesterday, however an asynchronous discussion has begun for the remaining public review comments
jroot advised that Jeremy Huff is working on the scripting for the presentation to be discussed at the meeting tomorrow
Florian Gleixner advised that the distributed configuration group is still trying to agree on a regular meeting time
Marc Johnson advised that it has been decided that the Poppy release has been deferred to the fall of 2023, making it the name of the next release. And that Oleksii is already putting together an initiate for upgrading modules to Java 17
Craig McNally to update the decision record to apply to the Poppy release
Craig McNally Suggested that we should include a topic for how we indicate that the RFC has been approved/accepted ? Looking at GitHub it isn't clear to me.and for how we approve the decision record
Continuation of our conversation about Cross-tenant/consortia and tenant checks. Calendar already updated. Olamide Kolawole explained some details in last meeting.
Cancelled due to scheduling confusion
is holiday for several members - probably won't meet meet
Continuation of our conversation about Cross-tenant/consortia and tenant checks. Calendar already updated. Olamide Kolawole explained some details in last meeting
I need someone to run this meeting as I'll be out on vacation.
Craig McNally advised that the topic of definitions came up at the Chair's meeting. He advised them that the TC agreed to defer that until after elections and would be considered as part of the upcoming architectural review sub-group
Marc Johnson Asked if it could be worth having the first iteration of the architectural review be about defining the platform term, especially given we have external impetus for this and we are trying to keep groups short lived?
Craig McNally suggested the group discuss that as their first order of business
Time permitting
Officially Supported Technologies - Upkeep
All
Craig McNally successfully locked down the pages so that only TC members can edit
Craig McNally will roll out the headers to the remaining pages
Review the page status enumeration from the perspective of how/when/which modules are affected
Lock down is done, headers are there and now labels are added so things are appearing as they should be! Good progress.
Does "accepting" imply once and done or can things circle back through the statuses? How do we expect the statuses to drive what we are going to do? What process ties the statuses together?
It would be helpful to have a workflow diagram (like what JIRA has) about how the statuses transition from one to another. Need something written down.
As far as new modules, trying to show only the active one applies to a module being released right now
Some process is needed because of impact on scope. Impact can be at product level because of scope but the knowledge is at the dev level.
RFC too heavyweight for these decisions
Due diligence/communication to not surprise people
Who needs to be told? PO meeting and they communicate back
Bring to a monday meeting
ADRs might be a good solution
Should move Poppy to active, need to get Quesnelia up soon
Today:
Didn't get to this today - defer to next week.
Time permitting
Terminology Document
All
Craig McNally the term "platform" is something that we wanted to revisit but the terminology document otherwise has been accepted by the three councils
Jenn Colt has been talking with Marc Johnson on Slack and was thinking that could be part of a larger conversation about architecture
Marc Johnson is okay leading this conversation and rolling it into the Architecture discussion, we could use platform as the first topic on the Architecture sub-group
The Folio Chairs were asking if we thought this could be sorted out in time for WOLFcon...
Topic Backlog
Action Items
Marc Johnson suggested that he didn't understand what the term active meant in the statuses defined in the document
Craig McNally suggested that it meant the actively supported release and asked if Poppy should be marked as active in that case?
Marc Johnson stated that this depends upon our use of the term active. And advised that we can have up to 4 releases being actively supported or in development at any one time
Craig McNally suggested the reasoning for the use of active was to include changes made in service packs. And Asked if it made sense to include an additional status?
Marc Johnson suggested using Supported for the releases available for production use and supported and active for the one open for module reviews by the TC, however that leaves a gap for the release that is past the review threshold but not yet out for production
Craig McNally suggested that means we would be better off keeping only the Active status
jroot suggested that for operators, the dividing line is what is considered generally available for production release
Marc Johnson suggested that would mean the active release(s) would not be the one applicable to new modules. As long as folks are happy that they know which release applies to new modules, then we can leave the statuses alone and move on
Craig McNally suggested we leave the statuses as is, because these reflect which releases are should be fairly stable and only updated for significant security issues
Marc Johnson suggested that for the release(s) being actively developed, we would expect the versions of these technologies to be changing, for example, the recent Java 17 decision
Craig McNally Asked if that was an exception due to releases being rescheduled?
Marc Johnson advised that the only difference would be that the Quesnelia release would be the one that changed instead of Poppy. This is a general challenge with our release management
Craig McNally asked what the intended purpose of these statuses was?
Zak Burke suggested it would be really helpful to the UI folks planning changes due to the longer runway for Poppy to have a process for these kind of changes
Tod Olson suggested that these statuses are loosely related to that status of the releases themselves. And that the audience includes developers and module evaluators
Craig McNally suggested the audience also includes module evaluators. And that the process at the moment is very loose and will be updated when we know more
Marc Johnson agrees with Zak, getting a process in place is more important than agreeing on these statuses. And raised the concern about how we've embedded some policies in these statuses and that the guidance around them does not match up with how they will be used
Craig McNally captured open questions for us to review
what are the relevant milestones in the release process for moving the status of these pages?
do we want a single status for the current release and in support or multiples statuses?
what is the process for making changes to these documents?
Marc Johnson stated the reason we wanted to statuses was to avoid ambiguous edits to the pages and arbitrary text reflecting their status. We could not have any statuses and instead, only update the pages when we've decided, however that makes it harder to evaluate draft changes to these documents
Topic Backlog
Action Items
Craig McNally to update the Java 17 decision record to apply to the Poppy release