How to submit an open source contribution for Product Review

 

Overview

The goal is to define how new contributions will move through the product review process. Currently, contributions go through product review after PRs have been submitted and development work is already complete. We want to invert the process, so the product review and approval happens earlier, before the PRs are submitted. That way, when the PRs are submitted, the community and all relevant stakeholders have already come to agreement on the specs and expected behavior of the contribution.

 

Proposed process

  1. A product manager creates a proposal with user stories and a proposed solution

    1. Templates: https://openedx.atlassian.net/wiki/spaces/COMM/pages/3890249759

    2. All product proposals need to be represented on this board: https://github.com/orgs/openedx/projects/4 - new tickets should be created here: https://github.com/openedx/platform-roadmap/issues/new/choose. The GitHub ticket may contain the proposal and/or link(s) to external documentation

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

  3. At each bi-monthly meeting, the Core 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 Core 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 Core 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 Core 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.