Skip to content

Latest commit

 

History

History
112 lines (94 loc) · 9.11 KB

MODULE_ACCEPTANCE_CRITERIA.MD

File metadata and controls

112 lines (94 loc) · 9.11 KB
Raw

FOLIO Module Acceptance Values and Criteria

version 2.0 (ratified 2022-06-10)

Overview

The Technical Council (TC) has defined a process for technical evaluation of modules for inclusion in a FOLIO release. This document outlines the high level values and specific criteria used when evaluating modules as part of this process. The distinction between values and criteria is as follows:

  • Values are high-level factors that are unlikely to change over time. They should be understandable even to a non-technical audience.
  • Criteria are specific, verifiable tests as to how we’re meeting the Values within the current state of affairs. Criteria will evolve over time to respond to changes in the Project’s technology stack, current best practices, etc. They may require a degree of technical expertise or domain knowledge to fully understand.

In some cases, we may not yet have comprehensive Criteria for assessing a module’s adherence to a Value. In such cases, subjective review and analysis will be applied, and may lead to discussion.

This document provides the criteria against which a module will be assessed for inclusion into a FOLIO release, following the New Module Technical Evaluation Process.

Existing FOLIO modules ideally conform to the same Values and Criteria. It is understood that not all existing modules currently do so, especially modules created before the Values & Criteria were initially defined. The Technical Council will work with development teams to align the current reality of the code with the Values and Criteria over time, as practicable. Such processes will need to be developed and documented.

Please see Before Development for any planned development to new or existing modules that may intentionally diverge from these Values or Criteria.

Values

  1. Module adheres to Community Code of Conduct
  2. Module license is compatible with the FOLIO Project
  3. Module can be included in existing community build processes
  4. Module has robust testing that can run with existing community testing processes
  5. Module can be deployed in the Community’s reference environments without undue burden
  6. Module is secure
  7. Module is multi-tenant
  8. Module is internationalized
  9. Module meets current accessibility requirements
  10. Module offers a cohesive user experience consistent with the rest of FOLIO
  11. Module has developer and end-user documentation
  12. Module depends ONLY on other modules and infrastructure that are already included in FOLIO
  13. Module has a long-term development and maintenance plan
  14. Module is scalable
  15. Module supports high availability
  16. Modules conforms to FOLIO upgrade mechanisms

Criteria

Administrative

Shared/Common

  • Uses Apache 2.0 license (2)
  • Module build MUST produce a valid module descriptor (3, 5)
    • This is not applicable to libraries
  • Module descriptor MUST include interface requirements for all consumed APIs (3, 5)
    • This is not applicable to libraries
  • Third party dependencies use an Apache 2.0 compatible license (2)
  • In order to ensure reproducible builds, snapshot versions of build-time dependencies should not be referenced.
  • Installation documentation is included (11)
  • Personal data form is completed, accurate, and provided as PERSONAL_DATA_DISCLOSURE.md file (6)
    • This is not applicable to libraries
  • Sensitive and environment-specific information is not checked into git repository (6)
  • Written in a language and framework from the officially supported technologies page1 (3, 5)
  • Uses FOLIO interfaces already provided by previously accepted modules e.g. a UI module cannot be accepted that relies on an interface only provided by a back end module that hasn’t been accepted yet (3, 5, 12)
    • This is not applicable to libraries
  • Must not depend on a FOLIO library that has not been approved through the TCR process
  • Gracefully handles the absence of third party systems or related configuration. (3, 5, 12)
  • Sonarqube hasn't identified any security issues, major code smells or excessive (>3%) duplication (6); and any disabled or intentionally ignored rules/recommendations are reasonably justified.
  • Uses officially supported build tools (3, 5, 13)
  • Unit tests have 80% coverage or greater, and are based on officially supported technologies1 (3, 4)

Frontend

Note: Frontend criteria apply to both modules and shared libraries.

  • If provided, End-to-end tests must be written in an officially supported technology1 (3, 4)
  • Have i18n support via react-intl and an en.json file with English texts (8)
  • Have WCAG 2.1 AA compliance as measured by a current major version of axe DevTools Chrome Extension (9)
  • Use the Stripes version of referred on the Officially Supported Technologies page1 (10, 16)
  • Follow relevant existing UI layouts, patterns and norms (10) -note: read more about current practices at https://ux.folio.org/docs/all-guidelines/
    • E.g. Saving state when navigating between apps (or confirming that you'll lose the state)
    • For UI links to documentation, there is no rule on where that documentation should be hosted, i.e. docs.folio.org, or wiki.folio.org, or module-specific destinations, as long as it is publicly accessible.
  • Must work in the latest version of Chrome (the supported runtime environment) at the time of evaluation (10)

Backend

Note: Backend criteria apply to modules, shared backend libraries, and edge modules.

Footnotes

  1. Refer to the Officially Supported Technologies page for the most recent ACTIVE release. ↩ ↩2 ↩3 ↩4 ↩5 ↩6