...

Overview

This document outlines the processes for product evaluation of new functionality for inclusion in a FOLIO release. The following activities are covered:

1. Before Development

2. Submission

3. Evaluation

4. Review

5. Feedback

6. Approval/Rejection

Supporting documentation

• Details of the JIRA workflow are captured in a separate document.

• Functionality evaluation by the Product Council is part of a larger process involving the other FOLIO Councils (PC/CC). A description of the full process is currently being developed by a cross council working group. Upon completion a link to this process will be added here.

Before Development

• Please review the Evaluation Process for new FOLIO Functionality and Evaluation FAQ Frequently Asked Questions before (or as early as possible during) development, to avoid any issues which would lead to delay or rejection of the module.

• The Product Council welcomes questions. In particular, if you anticipate that the functionality will introduce any cross-app changes or other innovations that might conflict with existing PCR criteria, or would imply significant changes to the hosting environment or required infrastructurefunctionality, please do reach out to the Product Council ASAP.

...

Submit a Review Using JIRA

1. The Submitter fills out a form in JIRA (using a template) and submits it to the PCR Board for review.

   • See JIRA workflow for details.

   • An Evaluator will only respond to submissions from the official Submitters Submitter as defined in the 'Roles' section of this document. The JIRA ticket is set to Submitted.

JIRA Template To Be Answered For the Product Council

The Template will includes these prompts. The Submitter should provides answers and documentation for the Product Council:

• Functionality Name

• Functionality Description

• Desired release date

• Expected TC review period

• Describe how this functionality is unique

• Describe how this functionality impacts or compliments existing functionality

• Describe how this functionality fits into the roadmap

• High level description of how the functionality is being built (back and front end aspects, interactions with existing functionality, etc.)

• Describe any dependencies

• Describe your user acceptance test plans

• Links to documentation (technical and users) or describe documentation plans

• Link(s) to presentation materials

Initial Review

1. The Product Council will update the JIRA within 1 week (See JIRA workflow for details) with the following information:

   • Confirm receipt of the submission

   • Who will be performing the role of Evaluator, as defined in the 'Roles' section of this document

   • Provide a rough estimate for the initial evaluation to be completed

     • Should be 3 weeks or less.

   • Request additional information

   • If there are missing points of contact, the Product Council will be contacted

   Any questions about the module will be directed to the points of contact.

   such as a presentation of the what the new functionality

   • Request a demonstration of the module

     • In some cases the PC may request a demonstration of the module

     • In such instances the The Evaluator will contact the Submitter with a request for a demonstration, and a mutually suitable time for the demonstration will be scheduled.

Submission form

Information gathered includes:

• Functionality name

• Description of functionality

• Link to source - a tag/commit in a publicly accessible git (preferably GitHub) repository

• List of related functionality (e.g. is this a Frontend/backend pair? Business logic/storage pair? ePC.)

• Points of contact (Subject Matter / Domain / Technical)

  • Each point of contact's role should be clearly identified.

  • A single, main point of contact must have an account in http://issues.folio.org JIRA.

• Free form section for notes, clarifications, background, links to supporting documentation.

• Link to self evaluation results

• Informational Section - provides info, instead of eliciting it.

  • A link/pointer to the most recent version of the Acceptance Criteria.

  • The PC has a maximum duration of 3 weeks to perform the initial review.

    • The evaluator may have between 2 and 3 weeks, depending when the PC meeting happens during that first week.

    • This does not include activities that happen after feedback is given, ePC.

  • The applicable deadline for submissions in the release timeline (not the date, but the name of the milestone/deadline e.g. "deadline for new modules")

Evaluation

1. The Product Council reviews a JIRA board to see if there are any new submissions, and check on the status of evaluations in progress.

2. If there’s a new submission, the Product Council finds one or more people to perform the role of Evaluator.

   • The review team will be formed in a way to allow for a fair review and avoid either perceived or actual conflicts of interest. No members should have participated in the module's development, and at least one member should be independent of the submitter's organization. The lead evaluator will be assigned in JIRA; if the submitting team has concerns about the chosen evaluator they should contact the PC chairs within one week of the assignment.

   • JIRA workflow: the ticket is transitioned from SUBMITTED to UNDER EVALUATION

   • In order to improve notifications when the Jira is updated, the primary reviewer should be the Assignee and other members of the review team should be issue watchers.

3. The module is evaluated.

   • If the Evaluator(s) have questions, they may reach out to the Point of Contact for clarification.

     • This may be an iterative process: the evaluator and submitter may choose to iterate on the submission, making adjustment to address the questions raised.

     • Whenever changes are made, the submitter should update the commit hash in the Jira.

   • If answers aren't provided in a timely manner, the criteria in question may be failed.

4. Upon completion of the evaluation the JIRA will be updated to indicate this.

   • JIRA workflow: the ticket is transitioned from UNDER EVALUATION to PC REVIEW

Review

1. The Product Council reviews the evaluation results.

   • The evaluators present the evaluation results, and optionally reccommends a PC decision.

   • Asks any questions they have for the evaluators.

   • Weigh in on any subjective criteria.

   • The Product Council may ask the Evaluator(s) to make changes to the evaluation.

   • This review may happen either out of band, during the regularly scheduled Product Council meeting, or a separate meeting scheduled specifically for this purpose.

2. The Evaluator sets the JIRA issue from SUBMITTED to INITIAL REVIEW.

Review

1. The Submitter present at the schedule time to the Product Council.

   1. This presentation is a time for Product Council members to become familiar with the new functionality, understand how it works, and how it impacts current functionality.

   2. The Product Council members will strive to see how this new functionality fits into FOLIO as a whole and as an international product.

2. The Product Council has 1-2 weeks to consider the new functionality as defined by its criteria and values.

3. The Evaluator transitions the JIRA issue from INITIAL REVIEW to UNDER REVIEW.

Endorsement

1. The Product Council reviews the materials and discussions.

2. The Product Council decides, using its standard protocols, to accept, provisionally accept with a follow-up, or reject the module, or else to defer a decision pending other actionthe new functionality under review within 1-2 weeks after the presentation.

   Evaluation results are published (in markdown format) to the tech-council GitHub repository and linked to the JIRA ticket.

   • An evaluation where all criteria are met will typically result in the acceptance of a module by the Product CouncilProduct Council’s Endorsement of the new functionality.

     • The JIRA issue transitions from UNDER REVIEW to APPROVED.

   • An evaluation where not all some criteria are met will typically result in the rejection of a module by the Product Council. However:

     • If some of the failures are due to proposed architectural (or other cross-module) changes, the PC may request that Submitter first propose those changes via the RFC process to get sufficient community input. In that situation the PC may defer its decision pending the resolution of the RFC. (See Before Development.)

     • If PC and Submitter unanimously agree on module changes that would resolve any failures, the PC may decide to provisionally accept the module with an agreed-upon timeline for the changes to be completed. When Submitter notifies PC that the changes are complete, the reviewer(s) may update the evaluation and PC may adjust its decision.

     • If the PC determines that some failed criteria would be resolved by non-controversial changes to the criteria themselves (or referenced requirements like the Officially Supported Technologies), PC may decide to accept the module and make the agreed-upon changes.

   • When the Product Council's decision is contrary to the evaluation, or after any provisional acceptance or deferral, the Product Council is required to provide written justification for their decision.

3. Upon completion of the review, the JIRA will be updated to indicate this.

   • JIRA workflow: the ticket is transitioned from PC REVIEW to APROVED or REJECTED

Feedback & Acceptance/Rejection

1. • An Evaluation Results Template will be used for thisan accept with a follow-up:

     • Because Product Council reviews should occur early in the development process, not all intersections might have been seen before the review. A follow-up allows the Product Council to reach out to additional stakeholders and work collaboratively with the Submitter on questions that arose during the review.

     • The JIRA issue transitions from UNDER REVIEW to APPROVED WITH FOLLOW-UP

   • An evaluation where none of the criteria are met will typically result in a status of rejected.

     • The JIRA issue transitions from UNDER REVIEW to REJECTED.

Review Documentation

• Evaluation results are published in the Functionality Evaluated by the Product Council within 1-2 weeks after a decision is made. The JIRA Issue is in the decision for each review.

• Interested parties (e.g. release coordinator, contributor points of contact, Product Council members,

...

• SIG convenors) are notified, and provided a link to the results.

...

JIRA workflow: notification is in the form of transition from PC REVIEW to APROVED or REJECTED

...

Follow-Up Status

• If there is a follow-up, the Evaluator will contact the Submitter, and a mutually suitable time for the follow-up will be scheduled.

Rejected Status

• If there is a rejection, the Product Council will work with the Submitter to understand what is needed for a re-evaluation.

  • The comments section of the JIRA may be used for this purpose.

  • If a meeting is required or desired, it's the responsibility of the Point of Contact to find a time that works and set the meeting up with the

...

• • Product Council

...

• • .

• If applicable,

...

• all issues are resolved and the Submitter request a re-review.

  • JIRA workflow: the ticket is transitioned from REJECTED to SUBMITTED

Process Feedback

1. PC The Evaluator asks the submitter Submitter if they have any feedback on the New Module Technical Evaluation process.

   • PC considers that feedback as part of the next process evaluation improvement round.

Roles

1. Submitter

   • Creates the JIRA ticket on the PCR board.

2. Evaluator

   • Processes a PCR ticket through the JIRA workflow

   • Can be a member of the PC or a delegate appointed by the PC

   • Must not be a member of the development team seeking approval.

3. Point of Contact

   • Communicates relevent module information through updates to the PCR Issue in jiraJIRA, once it has been created by the submitter.

   • Includes developers, product owners and other team members.