| Time | Item | Who | Notes |
|---|
| 1 min | Scribe | All | Ankita Sen is next, followed by Jakub Skoczen Maccabee Levine will fill in today. |
| - | TCR Board Review | | |
| - | RFCs | All | |
| 5-10 min | Technical Council Sub Groups Updates | | - Charter revisions: scheduled first meeting for 12/5.
|
| 1 min | Additional meeting time dedicated to topic discussions | | Doodle poll coming today! Topics: - Tools/Dependencies Versions (see previous notes for details)
- Goals & Objectives (see previous notes for details)
- TBD
|
| 5 min | Cross-council communication/meetings | | FOLIO chairs met yesterday, discussed several topics - Quarterly tri-council meetings. Details are still being sorted out, but aiming for January 12 at 9:30 AM ET (use the PC meeting time slot and zoom)
- Main Topic: What is FOLIO - project vs product
- This was a topic of discussion at WOLFcon
- Simeon Warner & Kristin Martin are pulling together something for us to use as a starting point
- Craig McNally is getting a status update on several initiatives (Platform Minimal, Applications, Layered platforms: Base → LSP → Extended)
- Quarterly community updates
- Also targeting January
- Updates going back to May 2022 since we missed the last update.
- Possibly change these to align with releases ... 3x/year instead of quarterly
- What could be better about FOLIO
- Discussed possibly having a jamboard session (e.g. at a future tri-council meeting) to identify possible action items.
- Scheduled the next FOLIO chairs meeting - Early January
|
30 min
| "new FOLIO Modules Group": Evaluation of New FOLIO Modules | | Previous: From Kristin Martin in #tech-council: Hello @here The work of the Functional Evaluation for new FOLIO Modules Group has completed and we are ready to share our work with the Councils for feedback, and hopefully a path for adoption. We have written an overview of the entire evaluation process here, in the document titled, “Evaluation Process for New FOLIO Modules.” This document, if approved, would become a wiki page under the Product Council space that covers the full evaluation workflow for new modules, under the current system of flower releases for FOLIO. Criteria for how the PC would evaluate modules is included in this document, which also links to the Technical Council’s technical review process. Finally the document provides a link to a proposed MOU for module contributors to sign. We would like to present this process to the three councils for discussion and welcome comments and feedback in the documents directly.
- Let's all take a look and familiarize ourselves with this.
- Kristin will be joining us on the 11/30 to present and discuss (allocating 30-40 minutes)
Today: - Kristin Martin presented: “Evaluation Process for New FOLIO Modules.” <I'm not taking notes on most things directly in the proposal>
- Near/medium-term solution, can be updated in the future. Not looking at retroactive review of existing modules, or of new code in existing modules. Simplified from earlier workflow.
- Serials management module is an example that would go through this process. Not new modules already turned over to the TC.
- MOU: MOU
- Process helps to document the purpose of a module, not always done in existing modules.
- Using 'module' language from TC, because 'app' doesn't have a consistent definition
- Wiki will track proposals and approved/rejected result.
- If someone wants to build a module, they need it, so bias to include. Balanced by weight of support and dependencies.
- Jenn Colt Make the conversations required instead of optional? Important if we have a bias to inclusion. Should design the process to lead to acceptance.
- Kristin Martin CC strongly did not want it to be required. Out-of-nowhere modules less likely to be approved.
- Jenn Colt People doing the process should have a say on the process. If PC and TC agree, they should push back to CC. Especially if a two-week review is suggested.
- Kristin Martin PC has an easier job than TC because review is not as exacting.
- Tod Olson Benefit of flower release is participating in QA / BugFest, testing in coordination with the rest of FOLIO. App store style deployment (discussed at WolfCon talks) also needs to be taken up.
- Marc Johnson This work deliberately excluded that, since it's an interim solution. Two groups currently working on that.
- the CC working group on capacity challenges which is also talking about how to structure development (facilitated by Tom Cramer )
- the desired future state group that split from the evaluation process group (facilitated by julie.bickle )
Kristin Martin Creating a bounded solution. Had left TC in an unfair place without PC criteria before TC review. - Jenn Colt Some PC criteria sound technical: API, testing. How do we avoid submitters having to do this twice (later for TC also)? Be clear PC is asking for the "what" of them, not the "how".
- Kristin Martin Tried not to duplicate. But can highlight those points.
- Tod Olson Both PC and TC have interests in those topics, different but overlapping. API and permissions in particular. Summary vs. gory details. Benefits for operations down the line. Good to represent in both places.
- Marc Johnson Some TC criteria may change/go away after this is in place. I.e. how it's licensed. TC tries to ignore what the product actually does, that could be a gap if not addressed here. Be clear on these overlapping topics of what info lives where.
- Jeremy Huff Agree with Marc, several elements of TC review could be removed if covered in PC process.
- Backend-only modules?
- Kristin Martin Yes we still want to hear about it.
- Marc Johnson TC started with a mixed list of FE and BE criteria, lately have separated them to be more specific. Expecting similar to happen with PC criteria.
- Kristin Martin Not imaginging a scorecard. Will still be some flexibility.
- Maccabee Levine Add a pre-build convo with TC as well. We've often noted it would help to avoid problems later.
- Kristin Martin PC could also suggest further convo with TC. So not a surprise to developers.
- Craig McNally Agree with including TC in pre-build process. Convo about whether it's a good architectural fit.
- Craig McNally Challenge is communicating process out to teams. Iterated several times but still maybe not clear to teams. How will PC communicate this out to teams?
- Marc Johnson Have a narrative for wider community on how different these two connected processes are. PC process will be highly qualitative, what is value of functionality, and managed in wiki. TC is deliberately more objective, and managed in Jira. Explain how & why they are different.
- Jenn Colt Release planning "New modules introduction checklist" wiki page is related. Evaluation timeline should relate to release timeline.
- Kristin Martin Craig McNally TC had preferred to keep the processes separate. New modules shouldn't target specific releases. Even if best-case scenario it takes several weeks. If they want it in a particular release, they have to submit it early enough.
- Jenn Colt For expectation setting, they should see that they need to have the modules in X months ahead of time. Because there is time pressure once a module is put forward. So having the timing clear sets expectations and helps with that pressure.
- Marc Johnson Current release schedules do say when a module has to be included, but only takes into account TC process. "Deadline for acceptance of new modules by Technical Council". Sympathize with keeping it separate from flower releases, but the only release people are doing this is to get into a flower release.
- Craig McNally That's on them. Can set general expectations like 3m in advance.
- Ingolf Kuss Officially adopted yet?
- Kristin Martin No. Taking feedback from council, presenting back to PC and asking for adoption. Currently there is no official process.
- Craig McNally will talk about the impact on TC.
- Craig McNally Suggests PC have a retrospective of process after a few modules go through it.
|
|
|
| WE RAN OF OUT TIME BEFORE ANYTHING BELOW THIS. |
| 5-10 min | MODCONF-131 | All | Previous: Mike Taylor is looking for "buy-in" from the TC on his proposed changes to mod-configuration. See Fixing the security problem in mod-configuration for proposal and Configuration and customization in FOLIO for context. How do we evaluate this w/o considering the bigger picture (distributed configuration vs centralized configuration vs both)? - Concern registered that this creates more confusion unless there is a concrete plan to migrate
He points out inconsistency in configuration APIs, does this proposal address that? Is there a gap in our decision making processes? There's sentiment that the RFC process is too "heavy". - Seems like this is already a proto-RFC and this is exactly the sort of wide-reaching thing we would want to go through the RFC process.
- The off-putting thing is how long the RFC process takes.
- Points to the challenge of getting people to come to the TC for a decision when they are blocked. Effectively, a team needs to bring a proposal to TC one full release cycle before the work can be done.
- There's a wish to accelerate the process, but that seems optimistic.
- Impression is that he's most concerned about the time issue and ongoing effort that goes into the RFC process.
- Noting that under our current processes we cannot prevent him from making these changes and using them for himself.
- There does seem to be agreement that this is a concern, and that there are multiple reasons to get a handle on the configuration situation.
- Was raised sometime earlier and discussed in core-platform, but was deprioritized for some reason. Unclear why.
- Does this conflict with an earlier decision, possibly undocumented, about moving toward distributed configuration?
- Possibly endorse tentatively, make changes to the API, and then go through RFC process.
- Must be prepared to decide differently, that we might decide to move to distributed after all.
- If long-term decision is to move to central configuration, then we need to coax people into migrating
Decision: - Mike can go ahead with changes to
mod-configuration if he needs in order to unblock his work - TC is not formally approving the proposal at this time, but will move in parallel with an RFC process.
- TC needs someone to champion the RFC and shepherd it, does not need to be a current TC member but should be familiar with the RFC process. Have tentative volunteer but will revisit next week.
- Following RFC process, will need to socialize outcome with development teams.
Today: - Need to find a champion/sponsor to draft an RFC framed around the broader topic of distributed vs centralized configuration
|
| Time permitting | Cyber Resilience Act | | From Craig McNally in #tech-council: This was brought to my attention earlier today...
https://blog.nlnetlabs.nl/open-source-software-vs-the-cyber-resilience-act/
While it's still just a proposal, I think FOLIO should keep an eye on, and maybe even try to get ahead of in anticipation of this. I will add it to the agenda for next week's meeting. This is a short read that does a decent job of laying it all out. Please take a look prior to next Wednesday. Thanks! - Have folks had a chance to read through any of this?
- What, if anything do we think the TC should do about this?
- Raise awareness among other councils?
- Seek legal advice in anticipation of this being passed?
- Is there anything else we want to do to be more prepared for this in the event it does get passed?
Today: |
| * | Topic backlog | All | Review/introduce/triage unprioritized items, and if there's time start discussion items. |
Topic Backlog |
20 min | WOLFcon Hot Topics | All | An overview was provided of the "hot topics" at WOLFcon. It seems clear that the TC ought to be involved in these discussions/efforts; what is the best way to participate? - Platform minimal
- Applications/bounded contexts & application management
- Blue/green deployments
- Kafka/messaging improvements
- FOLIO governance
- API technical debt
- ???
Notes: |
| How can/should the TC weigh in on the architectural impact of new modules? | | Introduce the topic - What do we want to get out of this conversation?
- Does this require a subgroup or individual to generate a proposal?
|
| 10 min | Consolidated Decision Log | | Today: - Maccabee Levine (from #slack) - Hi, I was out last week and just caught up on the meeting recording and the brief discussion of my suggested "Consolidated Decision Log" item. Two follow-ups:
- The work would complement (not duplicate) @Radhakrishnan Gopalakrishnan(Vijay)’s work on the ADR review. Specifically it solves the last action item listed from the retro.
- I made three specific recommendations in that slack thread a few weeks ago, and my suggestion for the TC would be that a subgroup get together to approve the first two (and perhaps defer the third).
Last Week: What, if anything should we do with the Decision log in the Technical Designs and Decisions wiki space? Is it worth consolidating those decisions with the TC's ADRs? Should we cross-reference? Clarify the scope of these decisions, and whether or not decisions should still be made/logged here? See discussion in #tech-council for additional details. - Craig McNally Decision log left when Tech Leads group fell apart with new governance structure. Are decisions still made or logged in that space? Where does this lie in the backlog.
- Maccabee Levine Motivations are to have a single list of decisions, to build developer-buy in and solve the longstanding issues with what decisions TC has authority to make. Also to know what we have to keep updated vs archive.
- Craig McNally By consensus, added to the middle/bottom of the list.
Today: Marc Johnson : Decision about Optimistic Locking: this is done. Optimisting locking can be used using the API. Bulk/Batch APIs especially for migration should use Optimistic concurrency control.
|
| Optimistic Locking interfering with batch update in inventory | | Conversation started in slack: The Data Migration subgroup of SysOps has been struggling with how optimistic locking has interfered with batch update in Inventory. They've asked me to bring it to TC to see if there's a way to push this forward. The current open ticket is MODINVSTOR-924 Batch update with optimistic locking disabled. (This was split off from MODINVSTOR-910.)
Topic has been addressed. Core team has agreed to implement as separate API that disables optimistic locking. See also Bulk Operations redesign, different issue but seems related. |
| Ease of Installing FOLIO | | From last week: - Ease of installing/deploying FOLIO - Ian Walls , Marc Johnson , Jeremy Huff
- Primary task the Tc would take on by making FOLIO easier to get up and running. Would also reduce AWS costs so that the money coming from Membership groups can be flowed to other aspects of FOLIO. Tc is the best equipped group to decide on how to make installing and deploying Folio easier and cheaper.
- Craig McNally - Brainstorming open ended session with Ian Walls and then discuss further before or after WOLFcon depending on the brainstorming session. Ian Walls and Tod Olson to frame the topics of discussion for the brainstorming.
Today: - Probably defer, but keep on the agenda so we don't lose track of this...
|
| Revisiting FOLIO Governance | | Slack discussion: Revisiting FOLIO Governance - Ian Walls - should be best discussed in cross council meeting possibly at WOLFcon. Idea to was bring this up at a high community level not necessarily the Pc or TC. Doesn't need to be on TC agenda next week. Aspects to be discussed at WOLFcon.
- See also: messages to PC and CC council channels
|