This document describes the charter and governance structure of the FOLIO Community’s Technical Council.
STATUS: Draft for review by FOLIO Product Council and the FOLIO community. Next step: after comments are addressed, ratification by the FOLIO stakeholders and appointment of the first council members.Accepted.
As a community driven open source project, FOLIO aspires to operate using the following guiding principles:
Appointments to the Technical Council are approved by the FOLIO Stakeholders.
Each of the FOLIO Stakeholder organizations will have at least one seat on the Technical Council.
Recommended no more than 10 appointed members
Technical Council meets every other week or on an as-needed basis.
Technical Council meetings are open for anyone to attend, and meeting recordings are held for two weeks. Meeting minutes are posted on the FOLIO project wiki. Only the appointed members of the Technical Council can vote.
The Technical Council appoints a convener from its membership. The convener is responsible for calling meetings, preparing agendas, facilitating consensus among TC members, and ensuring minutes are posted. These responsibilities can be delegated as needed.
The Technical Council strives to reach decisions by consensus. In the event that consensus is not possible, the convener can conduct a vote among the appointed TC members.
Recommended Members for the Initial TC:
OLE: Tod Olson (U Chicago), Zak Burke (Cornell),
Index Data: Jakub Skoczen, Peter Murray, Mike Gorrell
EBSCO: Vince Bareau, Mike Gunning, Mark Veksler
Only the appointed members of the Technical Council can vote.
- Set general technical direction, carefully abiding by our ‘local decision making where possible’ guiding principle. For example:
- Own architecture and provide general Technical Direction for Platform and Core Apps
- Empower local decision making for non-core apps/modules and ensure decisions are documented/maintained and reported to TC
Define processes, procedures and standards required for contributing code to the project. For example:
- Software Development and Quality Assurance best practices, including definition of done for a feature, sprint, release
- Ensure documentation and prioritization as necessary of all Non-Functional Requirements
- “RFC” (request for comments) process and maintain a repository of RFCs
- Security, Accessibility guidelines
- Maintenance of Contributor License Agreements (CLAs) for license compatibility, IP assignment to OLF, etc
Mediating technical conflicts between Collaborators or Foundation projects, for example
- Ensure proper code of conduct goes into appropriate areas and followed by all.
- Selection of testing frameworks
- Appeal/Impasse on PR (may result in a technical decision made by the TC and/or reassignment of a PR approver)
- Proactively advise the Product Council on technical issues that will require effort and prioritization.
- Respond to requests from the Product Council on technical issues
Out of scope
Resourcing - -- addressed by the Product Council
Prioritization of functional requirements -- addressed by the Product Council
Personnel Management (Code of conduct violations) -- report to Product Council
Long term strategic Architectural Blueprint - updated with each major release
defines the technical strategy for the platform beyond the current major release targeted by development
serves as a guideline to ensure that “local decision making” by development teams remains compatible with long term visions
accounts for strategic directions beyond the current scope of the platform.
Definition of what constitutes the FOLIO Platform vs Core Apps LSP Base vs FOLIO Extended Apps - on an ongoing basis
Umbrella Definition of Done
Definition of Done for a feature
Definition of Done for a sprint
Definition of Done for a release
Document describing “Best Practices” as collected from development teams on an ongoing basis
Document and publish the Request For Comments (RFCs) process
Repository of the RFCs
Publicly accessible notes from all formal meetings (Wiki?)
Publicly accessible description and resolutions of any conflicts presented to the TC
Produce white papers as required to describe and contextualize key technical issues that are seen to affect Folio (e.g. GDPR, Security, 3rd Party Integration,...)
Establish a mechanism for ensuring compliance with TC policies and procedures
On-boarding documentation for developers, testers and others
Platform: infrastructure components, such as OKAPI, Stripes, RMB, Users, Authentication, Permissions
Core applications: a set of applications that are needed to run a library, e.g. Inventory
Third party= non-core applications
LSP = Library Service Platform = Platform + Core applications