Aaron Trehub, Alexis Manheim, Amanda Ros, Ann Della Porta, Axel Dörrer, Brooks Travis, Charlotte Whitt, Gang Zhou, Harry Kaplanian, Ian Walls, Jana Freytag, Jenn Colt, Julie Bickle, Karen Newbery, Kristin Martin, Marc Johnson, Martina Schildt, Martina Tumulla, Owen Stephens, Peter Murray, Paul Kloppenborg, Sharon Wiles-Young, Stephanie Buck, Tiewei Liu, Tod Olson
Return to Criteria for Evaluating New Modules
Purpose: Finalize discussion for a Slack vote
Kristin has received feedback from the other councils and incorporated that information. This document will go into a new "cross-councils" wiki space. (The TC can move its content to the cross-council space if desired, noting that we need to be careful of how emphasis is placed on documents based on where they are located.) Wanted to make sure the definition of terms was as clear as possible. There will be a space on the wiki to track the PC's process on module approval. Feedback from the Community Council on the memorandum of understanding with contributing teams is included; this section may not be finalized.
The governance document is already in the Community wiki space, and this might be the best location for this new cross-council document. The signatures take on good faith that the person signing it has the authority to do so on behalf of the institution; we recognize that the memorandum of understanding (MOU) is not formally binding on the institution but is a signal of trust. Groups of modules can fall under one MOU. In the case of work-for-hire, it is the organization(s) providing the funding that should be signing the MOU. The transfer of copyright is a legal notion and goes against the "community agreement" form of the remainder of the MOU text.
Kristin will post a call for vote on the PC elected-member-only channel. There are potentially two modules that want to get into Orchid; we might want to set this new process until after the Orchid release.
Purpose: Information sharing
Moving forward with asking Marcia to return to help with documentation management starting in February to work with Paul Kloppenborg to be a community-based documentation manager going forward. This will put the documentation work on a firmer foundation.
The onboarding group is working on a PowerPoint presentation that explains the community structure, how the software works, and how the community SIGs work. This will emphasize that documentation and testing are good roles for new participants, and teaming up new members with existing members in a mentorship role. Aiming to share this with the PC on January 22nd (at the earliest).
The documentation for Nolana is done, and there is just a little bit of work to make it live on the website.
Future of Proposed Vision for Future FOLIO Builds
Purpose: brainstorming about the future of the group
The work that has been done has been marked as archived, and the work has concluded. There were conversations with the technical council about overlapping areas, especially on the notion of "platform minimal" and the vision of what an app store might look like. Platform minimal is a little beyond the design stage, and the app store parts are in the early design phase. The work is big and requires coordination, and that makes it a big effort. One way to move forward is to work on the lower-level technical details and see where that leads.
Product Owners are reporting that the release process is getting harder, and running the major release side-by-side with the hot-fix release was very hard. Fixes for translations requiring a hot-fix release make the support process harder, too. The additional policies and process is adding to the burden of maintaining the release process.
Future meeting topics:
January 5: Knowledgeware demo
January 12: Cross-Council meeting
Revisit idea of LTS (subgroup of Harry Kaplanian, Kristin Martin, Mike Gorrell, and Steffen Köhler met)
00:07:35 Charlotte Whitt: + 100 Owen 00:08:06 Charlotte Whitt: And most new customers going live with ERM first implementations 00:08:17 Martina Schildt | VZG: +1 00:08:28 Marc Johnson: Does anyone know where did the initiative come from? 00:09:14 Charlotte Whitt: We can do a new version, right? 00:10:34 Owen Stephens: Absolutely Charlotte 00:10:41 Marc Johnson: +1 Charlotte itâ€™s important we acknowledge contributions 00:10:47 Peter-Paul Kloppenborg: +1 00:12:49 Tod Olson: Yes, good on Oleksii for motivating this. Better to have a first go that we can fine-tune from. 00:13:33 Harry: +1 00:13:39 Owen Stephens: Yes - I hope Iâ€™ve been clear on that. I have to admit to being a bit upset when I saw this at first, and it has led to me spending considerable time at the end of last week preparing materials to be added 00:13:59 Owen Stephens: But I do support the concept overall 00:15:41 Marc Johnson: Will the TC content also be moved to this new space? 00:24:11 Ian Walls: is this MOU meant to carry legal authority? 00:24:21 Harry: No, it does not 00:25:40 Ian Walls: if the copyright for a new module is done as work-for-hire to an institution, then the institution would need to be involved in the legal transfer of copyright to OLF 00:27:33 Harry: Ian, yes. 00:28:24 Harry: +1 Tod 00:28:39 Brooks Travis: This MOU would have to be reviewed by legal at MO State if they were to sign one 00:29:04 Tod Olson: @Brooks: Yes, exactly 00:30:59 Brooks Travis: That would be a separate process 00:31:15 Brooks Travis: That the MOU is â€œcommittingâ€ the contributor to 00:32:09 Brooks Travis: A lot of the institutions that would actually end up going through this probably have open-source contribution policies that would apply here. 00:32:42 Marc Johnson: Every org that has contributed modules thus far has had to negotiate this legal aspect 00:33:24 Ian Walls: I think the challenge I'm having here is that copyright transfer is not actually required to make this project work... so long as the code is licensed openly, it can be owned by anyone 00:33:36 Steph Buck: Retrospective? 00:33:48 Harry: +1 Ian 00:34:00 Kristin Martin (University of Chicago; she/her): Yes, retrospective 00:37:41 Brooks Travis: I would assume that mod-entity-links is part of the MARC authorities 00:38:23 Marc Johnson: It does relate to authorities 00:39:42 Marc Johnson: Clarifying plug-ins is part of the scope of the TC working group to review the process 00:40:40 Owen Stephens: Hereâ€™s the request for TC review of mod-entities-links https://issues.folio.org/browse/TCR-21 00:41:10 Brooks Travis: One problem weâ€™re going to have is that the PC should really only be â€œapprovingâ€ features/sets of features for inclusion, and then TC would be tasked with reviewing the modules necessary to implement themâ€¦ 00:42:15 Tod Olson: Yes, that's exactly right. It's the level of abstraction that the PC works at, and highlights the problem of not having settled on a good-enough definition of "app". 00:44:30 Brooks Travis: I wonder if we need to revisit how weâ€™re using Epicsâ€¦ 00:44:54 Ian Walls: my model: 1. PC decides on goals for functionality 2. PC assigns discussion of functions to new or existing SIGs 2 00:45:17 Ian Walls: 3. SIGs work with POs and dev teams to make the requirements, do user acceptance testing, document, etc 00:45:24 Brooks Travis: Because that may be the level at which PC should be reviewingâ€¦ that or a bundle of UXPROD featuresâ€¦ 00:45:33 Marc Johnson: This impedance mismatch has been a fundamental challenge since the beginning 00:45:49 Ian Walls: 4. once satisfied, the SIGs bring the work to PC with their endorsement "this work means your articulated need" 00:45:51 Brooks Travis: I would argue that itâ€™s covered by the prior approval of MARC Authorities work by PC 00:46:06 Ian Walls: 5. PC decides to include work in the next Flower release 00:46:10 Marc Johnson: Brooks, whilst I like that idea, we donâ€™t necessarily have alignment between bundles of features and modules 00:46:37 Brooks Travis: â€¦ wouldnâ€™t they be linked to projects in Jira? 00:46:50 Brooks Travis: And those stories linked to UXPRODs/Epics? 00:47:03 Brooks Travis: Ratherâ€¦ â€œFeaturesâ€ and Epics? 00:47:14 Marc Johnson: Changes in modules SHOULD be linked to issues in a JIRA project dedicated to that module 00:47:25 Marc Johnson: That doesnâ€™t always happen 00:47:39 Brooks Travis: Wellâ€¦ maybe thatâ€™s something we need to addressâ€¦ 00:48:07 Marc Johnson: However UXPROD features can (and likely does) include changes across multiple modules 00:48:16 Brooks Travis: Yep 00:48:34 Marc Johnson: Thus, features arenâ€™t isolated to modules 00:48:44 Brooks Travis: Thatâ€™s what I was getting at 00:49:15 Brooks Travis: So, if a module is created to meet a requirement of an already approved feature/epic, then it can go straight to TC for review 00:49:32 Marc Johnson: Agreed, itâ€™s a fundamental misalignment of the product domain and the technical architecture 00:50:34 Brooks Travis: The new module just needs to be linked to that feature 00:50:49 Marc Johnson: Alas, the new process specifically states reviews of modules NOT bundles of features 00:52:03 Brooks Travis: I have to admit Iâ€™ve not paid as close attention as I probably should have to that outputâ€¦ 00:53:01 Marc Johnson: Itâ€™s a compromise because the TC process is fundamentally aligned to modules and we have no sufficiently specific definition of the unit of work for the PC 00:57:13 Harry: This is great news! 01:00:29 Kristin Martin (University of Chicago; she/her): https://wiki.folio.org/display/PC/Proposed+vision%28s%29+for+future+FOLIO+builds 01:04:33 Marc Johnson: +lots to Ianâ€™s point about essential need 01:04:44 Julie Bickle: Agreed 01:06:21 Brooks Travis: Iâ€™ve been making some suggestions on the review policy document that may help provide better delineation. 01:08:34 Aaron Trehub (Auburn): Mike Taylor's presentation: https://wolfcon2022.sched.com/event/14ANV/folio-modularity-in-practice-seamless-deployment-of-modules-from-multiple-sources 01:09:20 Tod Olson: Here's the talk on YouTube: https://www.youtube.com/watch?v=i-OebyVFKaE 01:09:35 Owen Stephens: 100% to that Marc 01:10:06 Ian Walls: I would fully advocate halting the current release process until we've figured out these deeper questions 01:13:52 Ian Walls: Owen++ 01:15:16 Marc Johnson: +1 to what Owen said 01:15:55 Marc Johnson: The translation challenge is a trade off from the decision we made to include all translations inside modules 01:16:45 Charlotte Whitt: Hear, hear Harry 01:17:19 Owen Stephens: We can release ui-agreements x.x.1 (or whatever) with translation updates (or other trivial changes in code terms) - but that just wonâ€™t be seen by libraries until a Flower release Hotfix is agreed and the whole process gone through 01:18:22 Ian Walls: 1. put the Orchid release on hold 2. agree that all modules are meant to be distributed as containers 3. All modules must ahead to Semantic Versioning 01:18:26 Owen Stephens: Ironically from a development team perspective the more stuff we push code outside the actual folio modules and pull it in at build time, the more agile we can be 01:19:00 Owen Stephens: Ian - I think 3. Is already the case? 01:19:07 Owen Stephens: It definitely is for us! 01:19:18 Tod Olson: @Owen: Like some kind of translation pack, in this case? 01:20:10 Ian Walls: if we have semanticly versioned containers, then we could define version _ranges_ that work together, so sysops can deploy anything within that range and know it'll function compatibly. 01:20:28 Owen Stephens: Exactly Ian - and thatâ€™s the way its meant to work 01:20:35 Owen Stephens: But we lock down those in a flower releas 01:20:47 Brooks Travis: LTS is critical updates (mostly security and data integrity fixes) 01:21:57 Owen Stephens: So for Flower release we have dependency: "@folio/agreements": "8.3.2" 01:22:24 Owen Stephens: Not: "@folio/agreements": "~8.3.2" (which would allow point releases to be automatically included) 01:22:46 Ian Walls: I propose we fix that ^ 01:23:02 Owen Stephens: @tod - yes something that pulled in at build time 01:23:18 Tod Olson: Or maybe at run time? 01:23:24 Marc Johnson: Harry, Ian - semantic versioning is not applied consistently across all modules 01:23:40 Ian Walls: concrete action: make it be 01:23:55 Brooks Travis: The compression of the release schedules for MG and Nolana is problematic on the â€œLotus is not supportedâ€ front. 01:23:58 Marc Johnson: We canâ€™t make it be ðŸ˜ƒ 01:23:59 Owen Stephens: At run time sure but I suspect that would require more substantial changes to the structure of how we appraoch translation 01:24:51 Marc Johnson: It would indeed be a very substantial change to how we do translations 01:25:07 Owen Stephens: But including at build time wouldnâ€™t be I donâ€™t think 01:25:28 Brooks Travis: Isnâ€™t that the kind of thing that is covered by that one groupâ€™s translation work that isnâ€™t being included as of yet? Peter? 01:26:01 Marc Johnson: Ranges make builds not repeatable. There is nothing technical stopping an operator changing the version of a module in their environment. 01:26:28 Marc Johnson: Brooks, are you referring to the K-Ware work? 01:26:38 Brooks Travis: Yes 01:26:56 Marc Johnson: That mostly handles translations of the labels of reference values 01:27:10 Brooks Travis: Ah, ok 01:27:22 Brooks Travis: Iâ€™ve not paid a lot of attention. Itâ€™s runtime, though, right? 01:27:38 Harry: I agree with Owen 01:27:40 Marc Johnson: Including at build time is still a substantial change as our entire translations process is built around them living in the modules 01:28:04 Marc Johnson: Brooks, it is runtime. 01:29:04 Marc Johnson: Weâ€™ve told folks not to release stuff without approval and not to take releases into their environments until an overall hotfix is blessed 01:29:39 Marc Johnson: This is why Iâ€™ve resisted labelling a UI as a given flower release 01:30:18 Brooks Travis: Hear hear 01:30:47 Marc Johnson: One of the major considerations for translation separation is knowing which translations are compatible with which versions of modules 01:31:30 Owen Stephens: No blame on Julie 100% 01:31:39 Harry: +1 01:32:16 Tod Olson: Yes, to all of the above, and KM & JB. 01:32:30 Brooks Travis: Thanks, everyone! I have to run. 01:33:01 Harry: Bye everyone. Good discussion! 01:33:06 Ian Walls: thanks, everyone. happy new year! 01:33:17 Owen Stephens: Iâ€™d really like to come back to this in the new year. I feel that there are things we can do to improve matters 01:33:29 Tod Olson: Aye. 01:33:31 Owen Stephens: Iâ€™m drained at this point, but I would want to help make this happen 01:33:44 Owen Stephens: And in the new year I will have 2023 supplies of energy ðŸ™‚ 01:33:53 Sharon Wiles-Young: Happy New Year all 01:33:59 Owen Stephens: Happy Holidays to all! 01:34:02 Karen Newbery: Happy Holidays!