...
The FOLIO project and its governance councils propose a process for evaluation of new functionality for inclusion into officially sanctioned FOLIO LSP releases. Each Council reviews potential new functionality using complementary processes. Under the current “flower release” system, the Product Council will review and assess any proposed new apps that will require the addition of new modules. 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, the Technical Council considers evaluation at the Module level, and the Community Council determines the appropriate level of documentation and financial commitment to fulfill, maintain, update, and support the functionality. Functionality that passes the Product Council review will then be communicated to the Technical Council where resulting modules will receive a technical review before inclusion in an officially sanctioned release. If modules are of a technical or backend nature, the Product Council may decline a functionality review, and refer the module developers directly to the Technical Council for review. Once approved, contributors will be directed to the Community Council to explain investment and commitment which may include, at the Community Council’s option, a requirement to sign a MOU and contribute the code to the Open Library Foundation. We recommend contributors review the functional, technical, and license requirements in advance of submission. We welcome and encourage discussions of new apps as they are being designed in addition to a final review when the underlying module(s) are ready to be added to a flower release, to ensure a smooth, fast, and transparent process. Regardless, the PC always welcomes discussions around new or existing functionality. If contributors are unsure, we encourage questions to be brought to the PC for discussion and next steps.
...
The Product Council values and criteria are as follows:
Category | Information requested | Evaluation Process | 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 approved, 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 theproduct 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 approval, 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.
The Community Council will review the long-term viability of the contributing team and the code to see whether the FOLIO project can accept it into an official FOLIO LSP release. Definitions for support and the process to share the code with the Open Library Foundation may be detailed in a Memorandum of Understanding.
...
- Any retroactive assessment of existing modules.
- Review of new code to be placed within existing modules. The Councils are always interested to learn about new functionality under development, especially as it relates to the roadmap or other planning, but changes to existing modules should follow existing processes and do not require a special review process. Product Owners with responsibilities for existing modules and areas of functionality should work through the respective SIG(s) as enhancements and updates are made.
- A review of code which will not be distributed as part of the FOLIO LSP under the FOLIO project and where the intellectual property rights will not be turned over to the OLF. As an open-source project, the FOLIO code is available for anyone to use, enhance, or modify outside of this process.
- A blueprint for long-term vision for FOLIO. This process has been designed to support the inclusion of new functionality and features under the current release framework.
https://issuesfolio-org.folioatlassian.orgnet/secure/RapidBoard.jspa?rapidView=236
Submissions and Tracking
The PC will track new app submissions that result in new module(s) via a wiki page. A recommended timeline for the PC review is 2 weeks. Status updates will appear on the wiki page, including the final decision of the Product Council. This review can occur prior to coding work being completed, so it doesn’t have to extend the development timeline. A PC representative will be in touch with the contributors with the results of the review. The PC may recommend follow-up conversations and put the contributors in touch with the appropriate SIGs. The PC can also help proposals by recruiting subject matter experts to create a new SIG or working group that can support development work, as appropriate. When the module(s) are ready for Technical Council review, the contributors can submit their ticket to have the module(s) reviewed via Jira. The Product Council will indicate by comment that they support inclusion of the new module(s). If a new module is purely of a technical nature, the Product Council will indicate in Jira that no PC review is needed.
...