2022-12-15 Product Council Meeting notes





Discussion items

5 minAnnouncements

Nolana (R3 2022) officially released.

There was a summary of the Morning Glory release in video and PDF form. It focused on the work of the EPAM teams, and there are efforts underway to broaden the scope of the release summary (Owen Stephens has been talking with Oleksii Petrenko about this).

 20 min

Return to Criteria for Evaluating New Modules

Purpose: Finalize discussion for a Slack vote

Kristin Martin  

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.

10 min

Documentation Update

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.

20 min

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.

5 min

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)

Chat log

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
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!