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 from CSP group:
Review of various issues (mostly security) for inclusion in upcoming service packs
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
Leaving this on the agenda as a reminder to update the DR once a decision has been made about the P/Q release(s)
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 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
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
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