Date
Attendees
- Jeremy Huff Mikhail Fokanov Ingolf Kuss Marc Johnson Florian Kreft Ankita Sen @Maccabee Levine Tod Olson Jenn Colt Zorian Sasyk Ian Walls Jakub Skoczen Owen Stephens Raman Auramau
Discussion items
| Time | Item | Who | Notes |
|---|---|---|---|
| 1 min | Scribe | All | Ingolf Kuss is next, followed by Maccabee Levine |
| - | TCR Board Review | All | No news. |
| - | RFCs | All | No news. |
| 1 min | Things FOLIO could do better | All | |
| 10-15 min | Technical Council Sub Groups Updates | All | Ingolf and Tod went over the Pain Points page and worked it into the Goals & Objectives page. Tod wants to wrap up this week. Translation subgroup didn't meet. Breaking Changes: Ankita started working on the RFC. Will send it by the end of next week. New subgroup "Improve the TCR process": Marc Johnson volunteers to participate. |
| 5 min | Spring Boot 3.0 | All |
Although we don’t recommend it for production, you can try Spring Boot 3.0 milestones today to see how hard it will be to migrate your project.
Today: Jeremy: It seem we have not come to a conclusion of this topic. Marc: We have to signal that it is not our business right now. Let us wait for Craig. There is a technical decision. We could make that ... for any of the modules. ... It means that the TC does not need to have an official stance on it. We do not have policies in place. Vijay comes in here... I find it mind-boggling how Spring Boot handles this. You have to upgrade a new version of this and that and to a major version of Spring itself which is not yet supported. This goes beyond my mind. Jeremy: I can not follow this, either. It does seem like we can offer some specific guidance. We have to defer this discussion. |
| 5-10 min | Tools/Dependencies Versions | Previous:
Today: | |
| 5 min | Retrospective on the ADR Process |
Notes: There are some candidates on the Doodle Poll. | |
| 10-20 min | Officially Supported Technologies and Mod OA | A discussion, explored by Marc Johnson in this slack post (https://folio-project.slack.com/archives/C02HP10PPGB/p1665740976370339), should be had concerning the role of Officially Supported Technologies in our new module evaluation process. Notes: Marc: Jeremy did a review of mod-oa. Zak did not understand the reasoning, because Groovy is not on the supported technology list. Without changes in our policies, there will be no way to pass mod-oa to pass the acknowledgement process. Shall we stay with this policy ? The supported technologies list was written as a backend for the module acceptance criteria. Now we are talking about how to make changes to modules. So now it also applies to existing modules. There are numerous modules that are currently written and use technologies that are not on the supported technologies list. We do need to answer the "new modules" list. Jeremy: It is clearly a discrepancy. If mod-oa would be submitted again it based on the same technologies it would be rejected again. It would have to be completely rewritten. Jeremy: mod-oa passed on the specific criteria; it did not fail the acceptance criteria because of the technology it uses. Technologie that we have experiences with are on this list. If you do implement a technology that is not on this list. This is intended to be a guideline. Jakub: Why don’t we add Groovy/Grails to the allowed list? Owen: They were added to the project before the module acceptance criteria / process was in place Marc: Most folks are familiar with Java and Spring. ... Folks want to be at the Flower releases. ... Do we want to be so restrictive ? We can just add Groovy and Grails to the list. That would solve the issue immediately. But support and boot tooling issues are then unresolved. And: Where do we stop ? Do we add all new technologies in ? | |
| Topic Backlog | |||
| 20 min | All | Previous Notes: TC charter has been updated recently, how would the TC like to review it? Jeremy Huff Was it written by TC or by someone else? - Craig McNally It was written by TC? Craig McNally Let's create a draft version, discuss it, communicate to other councils before publishing Tod Olson A comment to Guiding Principles .... (smth that should be explicitly stated as a GP) - Tod will add a comment to the doc Some conversation followed.. some comments were added to the doc itself Review and comments from TC members are welcome After review, what will our rewrite process be? Suggestion: make a subgroup to handle the rewrite. What's the value of continuing the review in TC as a whole? Would provide a general summary of feeling about the current charge. Useful onboarding, or better to onboard with a revised charge? Seems like a subgroup has formed: those who have actually commented Decision: will continue with review, try to be quick and then hand to a subgroup Notes: Jeremy: This needs to be either a new subgroup or an individual charge. After we have identified what needs to change we need to ... (initiate actions). Marc: We need to continue to review. ReviewGuiding Principles:Need some revision per above, make these clear as they are what we go to when we are uncertain. Motivation review:Much language needs to change: relationship with PC is different, TC does not do resourcing, "platform" is a dubious term now. Structure and Composition:Much of this is redundant with FOLIO Governance Model. Should refer to that document, and retain only those items that supplement that document. Responsibilities:What does "own architecture" mean? When we reviewed a year ago, concluded we were not doing this well. There are some abandoned blueprint documents. Do we think we are still responsible for this? Yes. The purpose of TC is to set some constraints or shared agreements about how the platform develops. TC does not have many options for enforcement, want compliance. Might affect how we approach the architectural guidance. Opposing view: approach as agreement and consent rather than enforcement and compliance. Giving teeth or power to the councils balances the weight of more powerful community members, like a check and balance. One challenge for the councils is that some voices have made decisions and councils have to retroactively accept these decisions. This creates a disincentive to talk to the councils as they may disagree. So incentive is to do first and ask permission later. Define processes, etc.: need to be clear about project requirements v dev team domain Maintenance of Contributor licenses, etc., CoC, etc.: Many of these seem to be for CC Out of Scope: need to update the audience for these bullet points, broader than PC. Key deliverables:Much language inconsistent and out of date, some things up in discussion and may change radically. May need two phases: short term immediate changes, then long term after other discussions resolve. Architectural blueprint - have provided but need to update the deliverable. RFCs: need to add ADRs | |
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?
Notes: |
| How can/should the TC weigh in on the architectural impact of new modules? | Introduce the topic
| ||
| Optimistic Locking interfering with batch update in inventory | Conversation started in slack:
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 | All / Ian Walls | From last week:
Today:
| |
| Revisiting FOLIO Governance | All / Ian Walls | Slack discussion: Revisiting FOLIO Governance | |
Action Items
- Craig McNally investigate a calendar to track long term TC responsibilities