Evaluation Process for New FOLIO Functionality
- Kristin Martin
- Jennifer Eustis
Reviewed and adapted Feb. 28, 2024. Updated on Dec 16, 2024Ā
Overview
The FOLIO project, under the auspices of the Product Council and Technical Council, review new functionality for inclusion into officially sanctioned FOLIO LSP releases using complementary processes. Under the current āflower releaseā system, the Product Council will review and assess any proposed new functionality and assess that in relation to product suitability. Adjustments in already established apps that are added to existing modules do not need to be reviewed by the PC at this time. The Product Council generally will work at the app level and the Technical Council reviews technical components at the Module level. Functionality endorsed by the Product Council will then be communicated to the Technical Council where resulting modules will receive a technical review before inclusion in an officially sanctioned release. In other words, the Technical Coucils is about technical suitability whereas the Product Council is about product suitability. These reviews by both Councils can happen simultaneously in order to expedite inclusion of desired new functionality. If modules are of a technical or backend nature, the Product Council may decline involvement and refer the module developers directly to the Technical Council for review. The Councils recommend contributors review the functional and technical requirements in advance of submission. The Product Council in particular welcomes and encourages discussions of new apps as they are being designed and solicits input from Special Interest Groups and possibly a follow-up discussion when the underlying module(s) are ready to be added to a flower release. This can help raise issues or questions early in the design process and ensure a smooth, fast, and transparent process.
Product Council considers new functionality to be
New FOLIO App
New functionality that requires new back-end modules and makes significant changes to existing front-end user interface
See the Frequently Asked Questions for examples and more explanation
See the Product Council Decision Log for what has been endorsed
Apps, modules, and other definitions can be found in the FOLIO Terminology document.
Motivation
The purpose of these evaluations is to ensure that substantial new functionality included in official FOLIO LSP releases meets the values of the Product Council for FOLIO as a whole. The Product Council aims to ensure the longevity and usefulness of the FOLIO as a whole product to all stakeholders. The Product Councilās review will be focused on the type of functionality that would be provided to FOLIO. This includes: uniqueness, fit with existing FOLIO functionality, and support of Roadmap objectives. To state it very simply, the Product Council deals with the āwhatā and the āwhyā of new contributions in relation to FOLIO as a whole. The Product Council does not deal with the āhowā or ensuring that any new modules conform to specific technical characterizations.
The Product Council views itself in a supportive role for the inclusion of new functionality and wants to check in with product owners and Special Interest Groups regarding new functionality, to understand how it fits into FOLIO as a whole, and consider ways to best integrate new functionality into the product and socialize it within the large FOLIO community. We recognize all new development is desired by at least one institution, and part of the goal of the review is to see how we can make it work even better for the broader community.Ā
The Product Council Values
Category | Information requested | Why we ask | Timing |
App Description | Explain the Appās functionality, including any ways this app supports the FOLIO Roadmap. | Understand the reason for the app. Understand whether the functionality in the app supports the Roadmap, such as by filling a need identified through community priorities or a ādesired stateā that in an area is not actively being developed. Understand whether the app provides the FOLIO LSP with needed functionality to fill a market need. | Before development begins |
App Delivery Description | Explain how the app will be built, including anticipated modules, integrations with existing functionality, and how delivery of the feature will occur. | Understand, at a high level, the technical underpinnings of the app. Understand the process for feature development. | Before development begins |
Uniqueness | Explain whether the app introduces new functionality lacking in FOLIO or if it duplicates existing functionality. If the functionality duplicates existing functionality in FOLIO, explain why the duplication is beneficial (e.g., existing functionality doesn't work for select institutions, additional connectivity required). | Consideration of whether alternatives exist and what unique aspects the app will bring to FOLIO.Ā | Before development begins |
Dependencies | Explain how the app will interact with existing features in the FOLIO LSP. Share specific dependencies and plans to address adjustments that may need to be made with existing apps or modules. | Understand how functional dependencies are accounted for and thought out. New functionality that has an impact on existing apps or modules should demonstrate that the product owners in those areas have been consulted to make sure solutions for managing that connection make sense. May recommend conversation with App Interaction or other groups as appropriate. | Before development begins Return back as needed |
Testing | Explain local testing process for the app and how work could be translated to BugFest (once endorsed, new functionality will be tested within FOLIO BugFest, or comparable testing mechanism, as part of the release process. | Provide understanding of reliability and interoperability of app with the rest of FOLIO. Provide support for FOLIO testing processes. | Before development begins Return back as needed |
End-user Documentation | Share end-user documentation that is available for the app that can be provided to the product documentation. This may include information about the data model and a data dictionary. Explain how documentation will be provided for the new module and plans for managing its upkeep going forward. Technical document is covered by the TC review. | Apps will need to be well-documented using the same style as at docs.folio.org. Proposers will need to work with the Documentation Working group, which maintains https://docs.folio.org upon endorsed, and when it is released, to ensure general documentation covers the new functionality. Technical documentation is a requirement of the Technical Council review, which happens are part of the TC review. | After app development is mostly completed |
The Technical Councilās criteria are available here.
Steps to Start a Review Process
The Submit a Review to the Product Council explains the steps needed to start the review process with the Product Council. This process is in place to allow those developing new functionality to submit a new review at any time without having to contact the Product Council directly. The process relies on JIRA where the submitter submits an issue at which point the appropriate person (the Evaluator) from the Product Council will begin working with the submitter and any other stakeholders such as the appropriate Special Interest Group convenors to gather information needed for the issue. The Product Council will seek out functionality to review and is willing to work with stakeholders on creating an issue that starts the review process.
The Submit a Review to the Product Council also provides the roles of the Product Council (the Evaluator) and the Submitter, a time frame for which the issue moves through each status, an explanation of each status, and what happens if none of the criteria are met.
The JIRA Workflow page explains what each status means and clarifies the role of the Evaluator and Submitter.
Contributing New Features to FOLIO: Flowchart of Steps
