2022-09-02 WOLFcon Cross Council Meeting - Project retrospective

Friday 9/2/22, 1:30-3pm

Scope criteria

Kristin Martin presentation from group: https://docs.google.com/presentation/d/1Z_8o12ajwN3gIba9SSPgbNHMS-rqr3UuObxv3833Q7w/edit#slide=id.p1

In the earlier Scope Criteria meeting, we came up with short term practical next steps. The PC will work with a group to come with lightweight criteria to help support review of new FOLIO modules. They will use what the SC group came up with and pear it down a bit.

Jeremy: In TC, we are looking at technical criteria for modules where the PC gives seal of approval, TC vets from tech perspective. Is that the way all councils see this working? Want to verify that assumption with the group.

Harry: Yes, if someone is going to provide code, if the project has to maintain it, it needs to meet certain criteria. What is the plan to maintain it, though? Project as a whole, PC, TC don’t manage dev resources or money. There needs to be a plan, including confirming code is good, and whoever proposes it agrees to maintain it for at least a certain amount of time.

Kristen: Is this a practical solution? Not sure the PC should tell anyone to maintain code for a certain amount of time.

Harry: Can there be an MOU that includes promise?

Kirsten: Institutions are already signing MOUs. Can institutions also agree tol maintain what they build? Already wrote up a draft MOU, but it needs feedback. Could the MOU come from the CC? CC would manage the MOU even if PC is approving the module.

Brooks: There does need to be a plan for near term maintenance, but it doesn’t need to be the dev team or sponsoring institution.

Harry: The MOU can include as a condition of acceptance the criteria from TC and PC.

Code has to be localizable, accessible, etc. -- this should all be in the MOU.

Make sure new features added follow these guidelines as well.

Tod: TC can set technical bar, PC determines fit for product. Would like to see the ongoing relationship of contributors to project as a CC role. Don’t think PC or TC can make that statement.

Kirsten: MOU should flow through PC to CC to get help on legal questions. If an institution really wants the functionality, they would be motivated to sign the MOU and be recognized.

Mike: Should consider consistency. What kind of formal agreement do we have from those who have already built modules? When implementing new requirements, also need to look at what we did in the past and align.

Jesse: If there are MOUs in place, there should also be a way for community members to contact the module creators to find out more about the future of that module.

Jeremy: Seems empowering for institutions to take that on and may increase engagement. A negative side effect is if ownership of a module would conflict with open source nature. 

Harry: 98% of the time, dev teams don’t go into the code of others. Only time it really happens is when there is no other option.

Brooks: Teams mostly maintain their own code, but sometimes there is jumping in.

Craig: Yes, if one team develops a module and another team comes along, they are expected to work with the team that created it.

Kristen: Action Item: find someone on CC to review a draft MOU

Mark: add specific points to MOU, commitment time, how many releases will be supported by the org that develops it. Also, responsible for making module compatible with subsequent releases.

Kirsten: MOU should be signed by the hiring institution not the dev team so the institution can find a new one if the dev team goes away.

MIke: I volunteer to review MOU. Also wants to ask orgs that are already doing dev work to agree to it as well with existing modules.

Jeremy: should the hiring institution be required to sign? Wouldn’t want to too narrowly define who could take responsibility for a module.

Ex: VuFind is 2 guys

Harry: VuFInd is very different from FOLIO, but there is something to what Jeremy is saying.

Functionality can sit on the outsides and not be part of the main product.

Noted as “May not be maintained, use at your own risk”

Craig:  If we eventually get to the base LSP and extended apps concept, some of this need might go away. Modules certified by a certain organization, not FOLIO

Kristen: This sounds like the concentric circle model. Should it be looked at again? That model goes beyond the original charge of the Scope Criteria group. Is that something the architecture group could take on?

Tod: Concentric circle model has been around for a long time.

Harry: This is more of a vision. SC (or PC?) should schedule some time next month, also with folks on the TC to present that idea. Serves as a future target of what we are trying to approach and tie things together into a more well defined project. 

Platform vs Product

Kristen: this relates to scope criteria -- how do you define a product?  I think of it as the software that I use in the library to do my work in tech services. Does the product include support, training, etc. that vendors add in?

Harry: The user group is the valuable part of a product. 

Tom: Do we need to articulate a combined vision -- cross council working group?

Product dev, tech dev, community mgmt.

Simeon: Product or products? FOLIO China, EBSCO FOLIO, etc?

Owen: The product is the flower release now. That is what the 3 councils control.

Harry: If there is a version of FOLIO that is being created and used at one or more libraries…is that a separate product? Not the PC’s product. Someone else's? 

Owen: Common platform, but different products depending on what modules are running.

Files that define what is in a build of software…that is platform (minimal)

Harry: There is a variant in the Middle East used by 10-20 libraries, closer to 100 in coming years. It is FOLIO in that part of the world.

Jeremy: This reinforces Owen’s perspective that flower release is the product. Can’t latch PC to what the ME is doing. Same scenario could pop up elsewhere. Our version of the product, flower release, is what we do have control over.

Alexis: Is a customized version of a product not the same product?

Owen: Common technology underneath is same, but differences make a different product. What we are talking about goes beyond customization.

There is a difference between product and community, many can be part of the community without using the same product.

Craig: iphone scenario, different apps different, not a different product.

Kristen: Product council -- what does that mean? That is the issue we are trying to solve.

Can’t define scope of the product if don’t have a definition of the product.

Tom: This is a taxonomy issue. When we say platform in this room, we should all know what it means.

Kirsten: Community can be bigger than product. PC, CC, TC are responsible for what is under OLF. If a platform is built in China, they are still part of the community, but it doesn’t sit under the OLF.

Harry: These other orgs are doing valuable things. We would like to see some of those come back to the project. See some of what they built appear under the OLF as well.

Is there a China PC, ME PC? Yes, we heard about it at the updates from FOLIO China presentation.

Tod: would like to see more active engagement with those other folks. Not complete merging, but more overlap. If they have technology that makes us more available to a wider international community, that is good.

Owen: We should look at what is happening across the world and use it when we can, bring them in to the discussion, but in scenario when ME was turned away from adding their code to the flower release, brings back to the what makes a maintainable module to contribute…what ME wanted to contribute was incompatible with current code.

Jeremy: Responsible for the integrity of code, we need to protect it. There is a discrete thing called a product that we are responsible for. Glad we built something that could be forked, need pathways for code to come back in, but it needs to be a monitored process.

Mark: It’s all about execution. If we deliver a better platform, more features, others might be more willing to adapt what we built and then return code. We need to figure out resourcing issues and just do it. If we don’t do it, someone else will and whatever they bring will become FOLIO.

Simeon: Flower releases with everything in lock-step were not the original vision. Are we going to be in this business for the foreseeable future?

Jeremy: Before flower release idea came about, there was no rhythm, but now there is. It has served the community well so far.

Kristen: What about FOLIO as a continuous release? 

Tod: Get bug features out more quickly with continuous releases. Some like it, makes others nervous.

Mike: Thinks we need flower releases and that is what the library community wants and we need to draw a line around the FOLIO product. There may be others, but we need to define the one we control, which are the flower releases.

Brooks: Do we want to consider whether other versions of FOLIO should legally be called that? OLF ok with that? 

Jeremy: Seems unwise to get combative about it. Would be within our rights, but a bad idea.

Harry: It has become a problem (terminology) in the past year, was not before. Get a group to clarify this. 

Owen: Yes, it’s a problem. Words we have are too generic. We should be more specific. If we mean the flower release, call it that. People want to install software to run their library.

Tom: TC is essential to this, but it is not just a technical matter. This needs to be a tri council effort, CC should organize one.

Jeremy: Work up a draft definition and pass it around.

Harry: PC should create a list of what our products are.

Simeon: Reflections on engagement at conference, have they worked? Tri council alignment?

Sharon: Need alignment, make sure we all agree on definitions, commonality is necessary for more communication.

Tom: Has had a hard time knowing what other councils are doing and this was great to find out about it.

Jeremy: Should we have a quarterly cross council meeting? 

Jesse: Positive, face to face is great, idea to put more council meetings before or after the main sessions so we can go to content driven meetings.

Kristen: Do a pre-conference for these meetings? It is hard to keep communication up with all our other responsibilities and a lot of us are in that position. Having a periodic opportunity to step away is helpful

Face to face of councils? Fund a meeting with CC $?

Paula: logistics might be hard to do a face to face for US and Europeans, maybe US gets together and Europe zooms in and vice versa?

Kirsten: Around the time of another conference to reduce cost? Face to face meetings can be $ well spent if a lot gets done.

Jesse: Multiple days allow ideas to build.

Sharon: One day meeting to summarize everything after having been to a lot of other sessions?

Simeon: Everyone wants more face time. What are other ways to improve communication?

Harry: Get something else in place other than zoom calls, asynchronous options?

Kathleen: Everyone needs to do their homework. If there is no discussion, the proposal is approved.

Craig: Suggestion -- someone comes up with a proposal, puts it somewhere visible, requests comments offline. This starts the conversation. At some point, a group meets to cross the finish line.  

Harry: Need a better way to record decisions, need other tool to do this work, Slack is not the best choice

Tod: Tool for long term discussion…Discuss. Use fell off, but maybe there is a use case for it.