MODULE_EVALUATION_TEMPLATE.MD

Module acceptance criteria template

Module Name

mod-XXX or ui-XXX etc.

How to use this form

When performing a technical evaluation of a module, create a copy of this document and use the conventions below to indicate the status of each criterion. The evaluation results should be placed in the module_evaluations directory and should conform to the following naming convention: {JIRA Key}_YYYY-MM-DD-{module name}.MD, e.g. TCR-1_2021-11-17-mod-foo.MD. The date here is used to differentiate between initial and potential re-evaluation(s). It should be the date when the evaluation results file was created.

• ACCEPTABLE
• INAPPLICABLE
• UNACCEPTABLE
  • comments on what was evaluated/not evaluated, why a criterion failed

Criteria

Administrative

• Listed by the Product Council on Functionality Evaluated by the PC with a positive evaluation result.

Shared/Common

• Uses Apache 2.0 license
• Module build MUST produce a valid module descriptor
• Module descriptor MUST include interface requirements for all consumed APIs
• Third party dependencies use an Apache 2.0 compatible license
• Installation documentation is included
  • -note: read more at https://github.com/folio-org/mod-search/blob/master/README.md
• Personal data form is completed, accurate, and provided as PERSONAL_DATA_DISCLOSURE.md file
• Sensitive and environment-specific information is not checked into git repository
• Module is written in a language and framework from the officially supported technologies page¹
• Module only 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
• Module gracefully handles the absence of third party systems or related configuration
• 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.
  • See Rule Customization details.
• Uses officially supported build tools¹
• Unit tests have 80% coverage or greater, and are based on officially supported technologies¹

Frontend

• If provided, End-to-end tests must be written in an officially supported technology¹
  • -note: while it's strongly recommended that modules implement integration tests, it's not a requirement
  • -note: these tests are defined in https://github.com/folio-org/stripes-testing
• Have i18n support via react-intl and an en.json file with English texts
• Have WCAG 2.1 AA compliance as measured by a current major version of axe DevTools Chrome Extension
• Use the Stripes version of referred on the Officially Supported Technologies page¹
• Follow relevant existing UI layouts, patterns and norms
  • -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)
• Must work in the latest version of Chrome (the supported runtime environment) at the time of evaluation

Backend

• Module's repository includes a compliant Module Descriptor
  • -note: read more at https://github.com/folio-org/okapi/blob/master/okapi-core/src/main/raml/ModuleDescriptor.json
• Module includes executable implementations of all endpoints in the provides section of the Module Descriptor
• Environment vars are documented in the ModuleDescriptor
  • -note: read more at https://wiki.folio.org/pages/viewpage.action?pageId=65110683
• If a module provides interfaces intended to be consumed by other FOLIO Modules, they must be defined in the Module Descriptor "provides" section, and must conform to FOLIO interface naming conventions.
• All API endpoints are documented in OpenAPI.
• All API endpoints protected with appropriate permissions as per the following guidelines and recommendations, e.g. avoid using *.all permissions, all necessary module permissions are assigned, etc.
  • -note: read more at https://dev.folio.org/guidelines/naming-conventions/ and https://wiki.folio.org/display/DD/Permission+Set+Guidelines
• Module provides reference data (if applicable), e.g. if there is a controlled vocabulary where the module requires at least one value
• If provided, integration (API) tests must be written in an officially supported technology¹
  • -note: while it's strongly recommended that modules implement integration tests, it's not a requirement
  • -note: these tests are defined in https://github.com/folio-org/folio-integration-tests
• Data is segregated by tenant at the storage layer
• The module doesn't access data in DB schemas other than its own and public
• Any dependencies, other than on defined interfaces, are declared in the README.md.
• The module responds with a tenant's content based on x-okapi-tenant header
• Standard GET /admin/health endpoint returning a 200 response
  • -note: read more at https://wiki.folio.org/display/DD/Back+End+Module+Health+Check+Protocol
• High Availability (HA) compliant
  • Possible red flags:
    • Connection affinity / sticky sessions / etc. are used
    • Local container storage is used
    • Services are stateful
• Module only uses infrastructure / platform technologies on the officially supported technologies list.¹
  • e.g. PostgreSQL, ElasticSearch, etc.

TCR Process Improvements

[Please include here any suggestions that you feel might improve the TCR Processes.]

Footnotes

1. Refer to the Officially Supported Technologies page for the most recent ACTIVE release. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷