| New Modules, new teams and impacting our reference environments' CD pipeline | TC | What is our process for accepting a team and/or its work into the FOLIO distribution (folio `core` and/or folio `complete` as defined here: Team vs module responsibility matrix - including its impact on our reference environments (snapshot, snapshot stable, testing, etc.)
Discussion: - Who will own ongoing maintenance once something is proposed should be answered.
- Do we need a way to verify the module's quality, and who does that?
- Do we need a way to assess whether their practices meet FOLIO's recommended/required practices (i.e. definition of done, code part of OLF's domain, CLA signed, code style guidelines, etc.)?
- How do we assess their inclusion's impact on our standard build and deployment processes?
- Does this process apply to only "community contributors" vs "project teams"? We should probably identify a single set of guidelines. (Assuming we are applying current guidelines to existing community teams today)
- We would expect the teams to adjust to the project release cycle as necessary?
- Is the project responsible for the quality of the FOLIO distribution (and how to we define the FOLIO distribution) - it is likely implied for something that is included in the Distribution.
- So the question comes down to whether modules "need" to be included in an official distribution.
- For those modules that DO need to be included...
Other points: - The notion of "Core" might be outdated. At one point it represented the minimal set of modules/pieces to "run" FOLIO. Things continue to expand and we might be at the point where this is no longer very useful.
- Allowing FOLIO modules to be grouped/combined in functional bundles/subdivisions might be very useful.
- Ian suggested the following "categories" of apps might be helpful FOLIO LSP App, FOLIO "Certified" App, and then any ole app that someone built. Note these align with what was documented previously as the definition of FOLIO.
- There is another issue that exists when an existing team creates a new module that introduces new technology and/or requirements for our CI/CD pipeline. This item is closely related to the topic below.
- One of the issues we are facing is our current "monolithic" release process
- Recall the "App Store" idea that was part of the early FOLIO vision that would present new "add-on" functionality. Note that this might be implemented very trivially.
Bottom line: We need to define the problem more clearly before we can make progress.
To be continued 3/17/2021
|
| New Technology requests - evaluation criteria | TC | was not time The TC needs to develop a set of criteria/checklist to be reviewed when new technologies are suggested/requested... so that we can make consistent and transparent decisions. As an example, our previous conversation about the following item sparked the need for our establishing the criteria: During today’s (20-Jan-2021) Tech Leads meeting a question was raised regarding the Spring Batch framework and whether the TC needs to approve its use in FOLIO. Spring Batch has been proposed as a building block for the new Data Export architecture (Data export by using Spring Batch (aka Export Manager)). Brainstorming Notes:
|