2022-06-13 Meeting notes

Attendees

Discussion items

ItemWhoNotes
WOLFcon Session Timebox 

Review the planned WOLFcon Timebox schedule and consider CC and other community meetings and whether there are any conflicts 

  • CC sees no conflicts and is fine with the timebox
Scope Criteria Group

Review Flow on slides 7 and 8 - comments and/or concerns?

  • Dracine: related to "contributor signs MoU"
  • who is the contributor?
  • Ian Ibbotson: initially it was software provider, who comes along and develops new software
    • maybe this needs to be broadened up
  • Harry: ownership goes to OLF
    • does that make sense, if OLF cannot take care of code
    • does it make sense to change that going into the future
  • Marc Johnson: agrees to Harry; there is a relationship between owner and contributor
    • needs to be granted that contributor stays around
  • Harry: can this be granted by anyone?
  • Ian Walls: transfering ownership is transfering responsibility
    • expectations need to be clear
    • business arrangements are needed to have FOLIO supported
  • Simeon: code is given to OLF only in edge cases
    • slide 10: functional criteria for FOLIO development is where expectations are given
  • Mike: need to look at higher level when looking at ownerhsip of code → FOLIO is open source and should stay open source
  • Harry: has issues with slide 7 "included in FOLIO build"; meanwhile there are multiple FOLIO builds
    • example for China: acquisitions is not usable in China, they have to build a new acq in China
    • we have to encourage multiple FOLIO builds (one for China, Germany etc.)
    • core FOLIO with basic set of functionality
  • Ian Ibbotson in chat: "Open Core" is a well trodden path for this kind of architecture
  • Dracine in chat: I  like that language.
  • Marc Johnson: need advice from broader community on ownership; different sense of meaning when discussing in scope criteria group
    • slides represent a proposal for today; not for future
  • Dracine in chat: I can see a scenario where Duke might consider the Chinese FOLIO build for it's campus in China.
  • Keven in chat: This is why we want to emphasize the role of regional communities, and it becomes necessary to maintain a "standard" regional version, otherwise compatibility is difficult to control and can cause difficulties in promotion FOLIO.
  • Mike: this is the sticking point; what exactly is the MoU
  • maybe need to find a better word
    • do you have to turn over ownership and contribute under Apache 2
  • IanW in chat: so in this case, the kernel would Okapi + Postgres + Stripes, etc, and the builds would include the different functional modules
  • Ian I in chat: @ianW - yes - that matches my understanding of core (possibly with users, permissions, auth also)
  • Ian W in chat: Yes, Ian I., we'd need to auth/permissions, too.  and Messaging (Kafka), storage (S3/Minio), and maybe some other cross-cutting utitilities
  • clarification needed for: "Contributor signs MoU"; otherwise it is difficult to agree to the new process
  • feedback: it should not be needed to have the PC approve at pre-build state
  • Ian W: difficulty to use "FOLIO"; different meanings (Community, product) → we need qualifiers
    • boundaries of power
    • PC says what goes into flower releases
    • everybody else can remix and bundle up
    • there is a mechanism needed
  • Harry disagrees partially: the PC should not make decisions on what is in a release in e.g. China
  • Marc: that would be a very different understanding of what the group was trying to achieve
  • Harry: this is because the slides are contracdicting each other
  • Simeon: PC is charged with managing the product
  • Feedback from CC:
    1. clarification needed for: "Contributor signs MoU";
    2. it should not be needed to have the PC approve at pre-build state; due to inpracticality reasons
    3. (by Harry) how do we make sure that we have a process in place for builds in other countries (e.g. China) | how do we endorse different builds of FOLIO throughout the world
      1. Marc asks for explanation; not in scope of this proposal
      2. Keven in chat: We need that
FOLIO Community Member status/questions

New Members - all "Supporting Member" level - all in hebis network:

  • University Library Kassel
  • Darmstadt University and State Library
  • University Library Johann Christian Senckenberg (Frankfurt / Main)

MoU Status

Question about paying multiple years

  • Some institutions have inquired about prepaying their membership fees for the next few years.
    • Keven in chat: Paying membership fees for multiple years at a time should generally be encouraged, which helps community maintain financial stability.
  • Potential issues:
    • Accounting?
      • Paula will talk to new accountant to check whether this is doable
    • Rate changes (supposed the level they choose becomes obsolete in future years)
    • Other?


  • CC agrees that prepaying their membership fees for the next few years should be made possible
ElectionsSimeon Warner 

Update

  • voting closes this Friday
  • Simeon will send a reminder to vote
Other Business

Chat

Von Simeon Warner (he/him) an alle 04:08 PM
50%
Von Harry an alle 04:08 PM
50%
Von Ian Ibbotson an alle 04:12 PM
via the CLA
Von Ian Ibbotson an alle 04:23 PM
"Open Core" is a well trodden path for this kind of architecture
Von Dracine Hodges an alle 04:23 PM
I  like that language.
Von Ian Walls an alle 04:24 PM
so in this case, the kernel would Okapi + Postgres + Stripes, etc, and the builds would include the different functional modules
Von Dracine Hodges an alle 04:25 PM
I can see a scenario where Duke might consider the Chinese FOLIO build for it's campus in China.
Von Keven Liu an alle 04:28 PM
This is why we want to emphasize the role of regional communities, and it becomes necessary to maintain a "standard" regional version, otherwise compatibility is difficult to control and can cause difficulties in promotion FOLIO.
Von Ian Ibbotson an alle 04:30 PM
@ianW - yes - that matches my understanding of core (possibly with users, permissions, auth also)
Von Ian Walls an alle 04:32 PM
Yes, Ian I., we'd need to auth/permissions, too.  and Messaging (Kafka), storage (S3/Minio), and maybe some other cross-cutting utitilities
Von Simeon Warner (he/him) an alle 04:33 PM
I second Dracine's comments. This is part of defining what our community mean
means
Von Keven Liu an alle 04:37 PM
We already have our own version name of Chinese FOLIO application 😊
Von Mike Gorrell an alle 04:37 PM
@keven
Von Dracine Hodges an alle 04:37 PM
Flower name?
Von Keven Liu an alle 04:37 PM
No
Von Mike Gorrell an alle 04:37 PM
where is the code for the Chinese FOLIO Application?
Von Keven Liu an alle 04:38 PM
Local gitlab site
Von Mike Gorrell an alle 04:38 PM
Is it publicly available?
Von Dracine Hodges an alle 04:38 PM
what naming convention are you using, Keven?
Von Keven Liu an alle 04:40 PM
We use YunHan δΊ‘η€š which is named by vote
The code is not publicly available by now
Von Simeon Warner (he/him) an alle 04:40 PM
That is good, I think there should be just one meaning to a release name which implies different names for different mixes (even if aligned in some way)
Von Keven Liu an alle 04:40 PM
but by the members of Chinese FOLIO Community
Von Simeon Warner (he/him) an alle 04:40 PM
Would be better if public though
Von Mike Gorrell an alle 04:40 PM
To me, if the code isn't publicly available then we can't consider it a “part of FOLIO" or a “version of FOLIO” in a practical sense. It's a private fork.
Von Keven Liu an alle 04:45 PM
We plan to make it publicity when successfully implemented in Shanghai Library
We need that!!!
Von Harry an alle 04:48 PM
I agree with you Ian
Von Marc Johnson an alle 04:49 PM
The TC gave exactly the opposite feedback. They felt that the group overstepped it’s remit by defining terms like app and module
Von Keven Liu an alle 04:55 PM
Paying membership fees for multiple years at a time should 
If rate changes,  it can stipulate that the fees paid are non-refundable, and to choose the closest lever of membership, or recognize that it does not have to make up the difference if the payment rate changes in the future.