Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


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.

Guiding Principles

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),

  • Ian Ibbotson

  • 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