Versions Compared

Old Version 5

changes.mady.by.user Jennifer Eustis

Saved on

compared with

New Version Current

changes.mady.by.user Jennifer Eustis

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

...

Before Development

...

Submission

...

Evaluation

...

Review

...

Feedback

...

Product Council reviews new functionality at the earliest possible stages in terms of the idea of that new functionality in order to consider it in relation to the FOLIO as a whole product.

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.

...

The Template will includes these prompts. The Submitter should provides answers to and documentation for the following criteria:. The answers to these questions can be done in collaboration with the appropriate Special Interest Group and can reference any presentations done in a Special Interest Group meeting.

  • 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

...

  1. The Evaluator sets the JIRA issue from SUBMITTED to REVIEW.

    1. The Evaluator will add a statement to the ticket on the criteria provided and any other information needed for a successful endorsement.

  2. The Evaluator 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.

  3. The Evaluator will work collaboratively with the Submitted to ensure all criteria has been answered in the JIRA issue and that the submission is set up for a successful review.

  4. Timeline: JIRA issues needs to pass to the next step within one week after submission. If that deadline falls on a holiday or weekend, then the week deadline is the next business day.

...

  1. The Submitter presents 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. Product Council members can also review the recording and materials asynchronously.

    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 decides, using its standard protocols, to accept, accept with a follow-up, or reject the new functionality under review within 2 weeks after the presentation. The following statuses can be assigned:

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

      1. The JIRA issue transitions from UNDER REVIEW to APPROVED ENDORSED.

    2. An evaluation where some criteria are met will typically result in an accept with a follow-up:

      1. 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.

      2. The JIRA issue transitions from UNDER REVIEW to APPROVED ENDORSED WITH FOLLOW-UP

    3. An evaluation where none of the criteria even after the presentation are met will typically result in a status of rejectedcancelled, blocked, or deferred. The Product Council will work with the Submitter to understand how to ensure all criteria are met and which status is appropriate.

      1. The JIRA issue transitions from UNDER REVIEW to REJECTED to CANCELLED, BLOCKED, or DEFERRED.

        1. The Evaluator will add a statement to the ticket on the reasons for the status change.

  3. Timeline: JIRA issues needs to pass to the next step within two weeks after submission. If that deadline falls on a holiday or weekend, then the week deadline is the next business day.

...

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

    • For a follow-up, the Jira Issue is transitioned from APPROVED ENDORSED WITH FOLLOW-UP to REVIEW.

  • Timeline: JIRA issues needs to pass to the next step within two weeks after submission. If that deadline falls on a holiday or weekend, then the week deadline is the next business day.

Resubmission, Blocked, Deferred, or

...

Cancelled Status

The Product Council plays a role in the decisions about what is included in the “Flower release” of FOLIO. This role doesn’t dictate what can or cannot be developed. This roles also doesn’t dictate what can or cannot be included in a FOLIO release supported by any particular service provider.

  • If none of the criteria are met even after the presentation, the Product Council will work with the Submitter to understand what is needed for a re-evaluation. to continue the endorsement process. The ticket should be updated with decisions and any information relative to the successful endorsement of the new functionality.

  • The Submitter can also elect to withdraw cancel the submission.

    • 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 the Submitter resubmitscan elect to resubmit, then all issues are resolved and the Submitter requests a re-review.

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

  • The Submitted can also elect to withdraw their submission.

    • JIRA workflow: the ticket is transitioned from REVIEW to CANCELLED.

  • The Submitted can also elect to defer their submission.

    • JIRA workflow: the ticket is transitioned from REVIEW to DEFERRED.

  • The Submitted and Product Council see that the new functionality is blocked.

    • JIRA workflow: the ticket is transitioned from REVIEW to BLOCKED.

  • Timeline: JIRA issues needs to pass to the next step within two weeks after submission. If that deadline falls on a holiday or weekend, then the week deadline is the next business day.

...

  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 approvalendorsement.

  3. Point of Contact

    • Communicates relevant 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.