Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
@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
5 min
Liaison Updates
@Maccabee Levine / @Tod Olson / @Jakub Skoczen
Updates from CC:
@Maccabee Levine via slack:
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.
Updates from the PC @Tod Olson :
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 (Unlicensed) 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 (Unlicensed) 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
@Ankita Sen@Craig McNally@Tod Olson have volunteered to participate in the architectural review. @Marc Johnson volunteered to be the backup content leader and @Jenn Colt volunteered to be the admin leader
1 min
Java 17 Discussion
All
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
5 min
Upcoming Meetings
@Craig McNally
Jun 12, 2023 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
Jun 19, 2023 is holiday for several members - probably won't meet
Jun 26, 2023 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.
Jul 3, 2023 Holiday for many
Jul 10, 2023 RFC Retrospective
5 min
Platform Definition
@Craig McNally
@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 (Unlicensed) 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?
@Craig McNally asked why we needed the statuses?
@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