2020-03-04 Meeting notes

Review previous action item and meeting results. See Cross-Team PR Reviews meeting notes:

• 2020-03-03 Cross-Team PR Reviews Discussion
• 2020-03-04 Cross-team PR Review Discussion Part 2

All recommended policies were approved:

• The tech lead from each team is responsible for reviewing PRs created by their team, regardless of the repository.
  • May be delegated to a backend/frontend lead, but the responsibility ultimately lies with the tech lead.
  • The lead maintainer for each repository is still responsible for their designated repositories.
• Tech leads must have a succession plan with sufficient overlap for knowledge transfer.
  • Onboarding/handoff must ensure that the new tech lead understands their responsibilities and duties.
  • Updating team documentation (who is the tech lead(s)) is the responsibility of the Tech lead.
• Issues discovered after a PR is merged will be addressed by the tech leads involved during retrospective, out-of-band discussions, etc.
• Feature-level design must be captured on the wiki for purpose of early feedback / knowledge sharing among tech leads

 Review the discussion on the Tech Council channel

Ian presented:

An "App" is something that is independent of any other App. It may be made up of several modules. We kind of have Apps as a Front end thing, but perhaps we should think about it as both a frontend and a backend thing.

Apps talk to each other through a messaging system.

If two apps require the same module...however it's solved is fine as long as they remain independent from each other. A challenge might be if the apps were dependent on different versions of a module.

"I would like to deploy Inventory but not Circulation" as an example.

Wanted to raise this for discussion but no specific "ask" of Tech Council.

Comments on this: Not totally new concept. Perhaps most significant when deployment concerns are considered.

One possible implication to get true independence would be more duplicated data than we prefer.

May require some definition of system level services that might not exist today.

Want to definitely make sure that services have whatever data they need in order to be independent. 

"Application Packaging" item raised as a possible architectural blueprint item.

Summarize discussions related to architectural blueprint as well as documenting architectural patterns and other requirements and/or recommendations.

FOLIO Architectural Blueprint discussed - all agree that it's valuable.

Continuing to discuss, right-size, reconcile and prioritize the blueprint. Will be bringing items to TC in upcoming meetings