Skip to end of banner
Go to start of banner

Review Process: Submit a Review for Product Council

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »


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

Before Development

  • Please review the Evaluation Process for new FOLIO Functionality and Frequently Asked Questions before (or as early as possible during) development.

  • 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 functionality, 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 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

    • Request additional information such as a presentation of the what the new functionality

    • Request a demonstration of the module

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

  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, accept with a follow-up, or reject the new functionality under review within 1-2 weeks after the presentation.

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

      • The JIRA issue transitions from UNDER REVIEW to APPROVED.

    • An evaluation where some criteria are met will typically result in an 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.

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. The Evaluator asks the Submitter if they have any feedback on the 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 JIRA, once it has been created by the submitter.

    • Includes developers, product owners and other team members.

  • No labels