PC reviewed Browsers Support statement and endorsed it. There was some support for Owen's ideas of providing some guidance. Owen had proposed in Slack. There is no specific action right now. People should be aware that they should file Jira tickets if there are any.
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 will ping Jeremy.
- - Folio Summit - Chairs from each council will be in attendance including Jeremy Huff and Craig McNally
Holiday for many, probably best to not schedule anything
RFC Retrospective
---------------
Tod: There is a meeting following up the Stanford meeting. Pushes on data import. There is representation from ARLEF and from the commercial partners, EBSCO, Knowledge Integration , IndexData and the German consortia.
Jenn et. al.: Why is this not being discussed at WolfCon ? Or we can have 3-hours-lasting meetings at Zoom. Why is this being discussed aside ?
Tod: How can we mobilize resources; how to we mobilize work that is not getting mobilized otherways. It is a response.
Maccabee: I am glad that our governance leaders are there.
Tod: Governance is set up more for influencing than actually directing effort. Various groups insert influence.
5-10 min
TC member roles
All
I believe what we discussed was keeping the liaisons as-is for now. The situation with the chairs was less clear. One idea was to phase a new chair in so there's less disruption once the next terms are up. Let's discuss and decide today.
Chair:
Deputy Chair:
CC Liaison:
CC Liaison backup:
PC Liaison:
PC Liaison backup:
CSP Liaison:
---------------
No change in the liaisons. Marc is CC and PC Liaison backup. Tod is the PC liaison.
Chair / Deputy Chair: We agree on a phased-in approach. No volunteers. We will wait until next year's elections.
Time permitting
Officially Supported Technologies - Upkeep
All
Previous Notes
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
I need someone to run this meeting as I'll be out on vacation. Craig will ping Jeremy.