7 June, 2018
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.
Guiding Principles
As a community driven open source project, FOLIO aspires to operate using the following guiding principles:
Open, transparent and respectful collaboration
Enable local decision making authority wherever possible
Create a sustainable community and ecosystem
Motivation
The FOLIO project has identified a number of needs that would be well-served by a dedicated Technical Council (TC) working alongside the Product Council (PC):
As a large open source community, there is the need to provide common guidance to help keep the community aligned on technical goals and directions
A group is needed to address technical issues concerning the long-term vision, coherence, continuity, and stability of the Platform.
Proactive identification of Technical Issues and Resourcing Needs that the project will need to deal with (e.g. end of life of an underlying technology, resources needed deliver on the roadmap). The TC would bring issues to the PC as part of communicating out to the rest of the community or to request resources. By way of example:
End of life of an underlying technology.
Resources needed to deliver on the roadmap (following some sort of cadence) as proposed by the PC.
Investigation/advice at the request of the PC. An example would be how to handle GDPR requirements.
As additional communities are showing interest in the Platform, there will be a need to coordinate needs placed on the Platform, e.g. the FOLIO LMS and the Resource Sharing group may have non-identical needs for the Platform and the TC may need to bring those needs into harmony or otherwise address them.
Arbitrate ‘disputes’ amongst the community on technical matters. An example would be two different groups lobbying for adoption of different testing frameworks.
Structure and Composition
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
Responsibilities
In-scope
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
Key Deliverables
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 vs FOLIO 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
Terminology
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