$customHeader
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 7 Next »

What is the Product Review process?

Product Review is the process by which contributions are considered for inclusion in the Core Product. Contributions require product review if the subsequent PRs will result in a change, big or small, to the end-user experience. This includes learners, course authors, course teams, or course/instance administrators.

Does my contribution require Product Review?

If the answer is “yes” to any of the following questions, then your contribution requires Product Review.

  • Does this change or impact a feature that a learner would interact with?

  • Does this change or impact part of the authoring flow?

  • Does this change or impact the experience of configuring content or a course run?

  • Does the change or impact reporting?

  • Is this change related to Studio or Content Libraries?

  • Is this change related to the LMS?

  • Does this change impact the initial installation or the upgrade of the instance?

  • Does this change impact a course’s OLX?

When should I participate in the Product Review process?

The Product Review process must take place before PRs are submitted. The goal of the Product Review process is to ensure the contribution aligns with the overall strategic direction of the open source project and the community roadmap. It may result in recommended changes or adjustments in approach. The process is intended to be a two-way dialogue between the contributing organization and the Product Working Group, with the goal of landing on the best possible implementation to serve the greatest need for the majority of the community.

How do I participate in the Product Review process?

  1. A product manager creates a proposal. The Product Working Group provides two proposal templates.

  2. The Submitter pings the Product Working Group in slack (#wg-product-core) and shares the proposal

  3. At each bi-monthly meeting, the Product Working Group will review incoming proposals as follows:

    1. Assign 1 Coordinator per proposal. The Coordinator works with the Submitter to shepherd the proposal through the review process.

      1. Find 2-3 volunteers from the group to review the spec to offer general feedback on scope and approach

        1. Document release plans/roll-out plans

      2. Alert any product stakeholders who may own the repo associated with the proposal

      3. Share the proposal via the Forums

      4. Determine appropriate time boxes for reviews

  4. The Product Working Group determines if the proposal goes into the Core Product Offering

  5. Feedback is incorporated by the Submitter and the spec is finalized

  6. Final approval comes from the Product Working Group and the product owner on the repo

    1. If both parties approve, then the spec is considered approved and can be implemented

    2. If either party disagrees, revisions continue until agreement is reached

    3. If agreement is not reached, the Product Working Group will make a final decision

  7. The spec is implemented and contributed. It is expected that, as long as the spec is implemented according to expectations, the corresponding PRs will be accepted without delay or argument.

For more how-to documentation, see here.

Can I see examples of Product Review proposals?

There are many examples here.

  • No labels
$customFooter