Page Comparison

TC Update on evaluation external code contributions (Tod Olson):

The Tech Council spun off a working group to define acceptance criteria for external code contributions. That will take the form of a high-level values statement and a draft list of verifiable criteria supporting those values. We anticipate this statement and list will be ready by the end of the day 2021-09-03 and will be used to evaluate external contributions for inclusion in Kiwi. 

While we anticipate the list of values will be stable and final, we anticipate the need to substantially expand the list of supporting criteria in order to further refine, illustrate, and more precisely explain what contributions must do to align with the values. Together, the statement of values and list of criteria will provide both high-level expectations as well as clear and comprehensive guidelines for evaluating code contributions to FOLIO.

Does the Product Council have a similar criteria-based process for determining which Apps would be desirable to include in FOLIO? Such a list would be useful to allow the TC to confirm that the proposed App does technically fulfill the expectations.

• PC should come up with these criteria - we need to consider whether this is something that we want to support over the long term? How should we assess the benefit to the project?

ACTION ITEM: PC will charge group to get these criteria together next week

There is a new member-onboarding video covering how to use the Wiki and Issue Tracker:

Thanks, Anne-Marie!

SysOps SIG has operational and technical debt concerns. Some of these are listed here https://wikifolio-org.folioatlassian.orgnet/wiki/pages/viewpage.action?pageId=735315042097841. There is one common thread among all of these issues, which is the need to reduce the manual processes and the complexity so that it is easier for people to contribute new modules/code to FOLIO and to help increase the ability to add features and/or changes to FOLIO without the need for large releases.

Threads of problems (jroot ):

• Documentation: not cohesive, consistent, or comprehensive. Biggest barrier for entry and biggest hurtle for individuals to contribute back to the community
• FOLIO has been developer-focused and developer-centric, which focus on getting many features out there. Maybe time to shift focus to getting FOLIO more fine-tuned and in alignment with micro-services.
  • Project seems to be moving away from continuous development and continuous deployment. Reducing number of releases per year. "Fail fast and fail often."
• Service Discovery: when a service comes up, the platform is supposed to be aware of it. But standing up a FOLIO instance is a very manual and hit and miss process. Okapi is not intelligent, too much configuration management by hand (e.g., getting edge users set up involves running a Perl script by hand)
• Dependency resolution: cumbersome to get all of the artifacts together to be able to update an installation. Would like to focus on "what constitutes a minimum FOLIO install?"

Stanfords issues (jpnelson ):

• problems with getting Kubernetes operational
• Very manual process involving a lot of troubleshooting
• Would like to integrate Sinopia linked data editor stack to FOLIO, but hampered by problems listed above - want to know what is a minimum FOLIO installation to help with work

Discussion

• Harry: releases are getting too complicated; too much time focused on getting releases out the door
• Need to return to the app store concept - simplify
• PC previously decided to move to longer release cycle, wanted to give process more time, to reduce amount of time focused on release cycle
  • Jason: suggests that decision did not do what we wanted it to
  • Harry: 3 releases a year not considered a good long-term solution, but the only thing we could do as a time
• Philip: what does it mean to "fail fast and fail often"?
  • James: spread out releases more evenly, will allow failures to be identified and dealt with earlier and fixed faster.
  • This is at the development face, not for the whole project
• Ian: microservices process would be better than need whole platform "hotfix" - be better to get smaller fixes rolled out more quickly
• Tod: want to identify and fix problems before they get to BugFest
• Brooks: how do we handle dependency resolution and interaction between documents (semantic versioning) - maybe we need to start there, so you can't deploy versions of modules that don't work together
  • Okapi does do dependency resolution, but the time you get to this point, you've done a lot of work already and it's too late
• Jesse: return to question of what is a basic installation of FOLIO
  • E.g., Circ installation needs these X apps to run
  • Harry suggests: start with users, then go from there
  • Kristen: what is a developer seeing when they run FOLIO to know if it is something for their library?  SMEs at potential libraries are going to want to see functionality to know if what FOLIO has to offer now matches their needs....is this a question of documentation?
  • Tod: TC does not have consensus on what is "core" and what is need to demonstrate capabilities for libraries.  With the effort to link the strategic goals to functionality, there are goals that aren't reflected in Jira and the roadmap team is looking to make sure this is covered.
  • Ian: How do different library goals (e.g. physical circ versus ERM) get reflected in having demonstration versions of FOLIO?
  • Owen: "minimal install" should mean the bare minimum of something that works as opposed to the combinations of different apps that are meaningful to a library
• Next steps:
  • Jason: the document in the SysOps SIG has priorities listed. 
  • Can the TC take this on (in collaboration with the SysOps SIG) and refer items to the PC that need to make their way to the roadmap?
  • PC needs to have a view of how FOLIO is deployed and used in a library.  Libraries want stability and predictability in the software they are using and the timing of when releases are made.  "What is the FOLIO product...as a suite of apps to manage their day-to-day business."
  • All this will require some well-written documentation for, which apps are bundled together, and when a platform feature like Kafka is required.

Discuss and decide how to best identify topics, prioritize, then set agendas for PC meetings

Possibilities include: Continue an ExecPC group, work with all elected PC members, fully open on PC Slack, other possibilities...

For a few years, there has been an ExecPC group—upcoming, current, and past chairs plus a few others—that gathered topics of interest from their own work and from suggestions from others.  The Exec PC would help presenters focus their presentations for the PC meeting.  The past few weeks, the elected-PC-only Slack channel has been used to gather topics and draft an agenda.  Prior to PC Exec, the last part of the PC meeting would be used to form the new agenda—but this caused a lot of discussion with little information.  Exec group was a clearinghouse set up to make this process more efficient and make PC meeting time more productive.  TC and CC are not using exec-like structures to set agendas.

Harry: if an exec-like structure continues to exist, the Slack channel should not be locked and the discussion process open; and the name "exec" needs to be changed.

Philip: People need to know how to approach PC to get something on the agenda.  There is value in what Exec does.

Paula: Sometimes topics came to Exec that presenters thought should be private initially.

Harry: CC is drafting guidelines on when closed channels in Slack are appropriate with the goal of making them rarer.

Proposal: use the open Product Council Slack channel to bringing up topics and initial discussion; include in the description of the channel a description of a way to get a topic into PC without publicly posting it on the PC Slack channel.  At a specified time (close-of-business Tuesday?), one of the chairs will pick from the available topics to form an agenda with the option for PC members to advocate for getting an item on the next agenda.  (The agenda, once proposed by the chair, is open to be changed in discussion with the PC members.)  A role for the secretary is to pull items from the Slack channel and put them on a list on the wiki.

Brooks: reluctance to eliminating the closed channel.

Kristin: a caution—this plan does disengage a group brainstorming about agenda items.

•  Jesse Koennecketo write up a description of his PC Agenda Setting proposal by 07 Sep 2021 for lazy consensus consideration at the next PC meeting, but will operate under this scenario for the next PC meeting.