Process was approved by PC May 2, 2023 for a six month pilot period.
Reviewed and adapted Feb. 28, 2024.
Overview
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. These steps can happen simultaneously in order to expedite inclusion of desired functionality. 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 The Councils recommend contributors review the functional, technical, and license requirements in advance of submission. We welcome and encourage The Product Council in particular welcomes and encourages 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.
What requires review by the Product Council?
It can be difficult to answer this question. In general, if a grouping of new features requires changes to the front of end and the back-end of FOLIO and results in new modules, the Product Council would like to know about it. You can see examples of previous functionality reviewed and approved by the PC on the Decision Log wiki page. If a contributor is unsure whether engagement with the PC is warranted, please reach out and we can have a conversation. Similarly, the PC will endeavor to check in with the Product Owners group regularly to get a sense of new functionality coming and note where conversations would be helpful.
Plug-ins are an exception and do not require this review.
...
Last, the Community ensures longevity and support for new contributions by vetting the contributor’s ability and willingness to continue to engage and maintain any new modules on a long-term basis. New functionality needs to meet all standards to be included in the standard FOLIO release.
All that said, the Product Council views itself in a supportive role for the inclusion of new functionality and wants to check in with product owners regarding new functionality, to understand how it fits into FOLIO as a whole, and consider ways to best integrate new functionality into the software 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 and criteria are as follows:
Category | Information requestedEvaluation Process | 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 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 |
...
https://folio-org.atlassian.net/secure/RapidBoard.jspa?rapidView=236
Submissions and Tracking
The PC will track Recommended steps for engagement with PC:
- Reach out to PC member to get on the PC agenda. We place functionality review as one of the highest priorities.A recommended timeline for the PC review is 2 weeks. This process can happen concurrently with TC’s Technical Review.
- Present new functionality to PC. Please include information in the checklist above. Presentations, diagrams, prototypes, UX mock-ups–these are all welcome, depending on the stage of development.
- PC tracks new app submissions that result in new module(s) via a Decision Log wiki page.
...
- Follow-up conversation can take place in Slack and people can post comments to the pending Decision.
- Voting on new apps takes place in Slack and is recorded on the wiki and announced in Slack.
- Set a time for follow-up, if needed.
What the PC may recommend to help the development:
- Suggest follow-up conversations and put the contributors in touch with the appropriate SIGs.
...
- Help recruit subject matter experts to create a new SIG or working group that can support development work
...
- Recommend a follow-up meeting with PC closer to the release date to see work in action.
MOU and Next Steps
Once the module(s) are approved by the Technical Council, the module contributors will need to reach out to The PC will facilitate communication between the module contributors and the Community Council, who will, at their option, supply an MOU detailing their commitment. The FOLIO SMLLC will supply MOU and store the final results. The Community Council will manage the renewal of the MOUs as appropriate.