Page Comparison

...

1. Anyone/everyone in the community can create a proposal with user stories and a proposed solution

   1. Templates: Choose Your Template - Open Source Product Contributions

   2. Create a Product Proposal ticket in the platform-roadmap GitHub repository

      1. You may need to first make a free account, https://github.com/signup

      2. Create your Product Proposal ticket here

   3. The ticket will get auto-added to the Open edX Roadmap project board: https://github.com/orgs/openedx/projects/4/views/2420

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 triage 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. Criteria:

         1. The Coordinator can be any member of the community, but it is helpful if the Coordinator has some connection to the Product Core WG or knows who might be a stakeholder in the project.

         2. The Coordinator can come from any organization, including the one that submitted the proposal.

         3. The Coordinator should do an initial review of the proposal, making sure all needed information is in the spec and it is clear and easy to read.

         4. The Coordinator for a given product proposal will be in charge of keeping status and labels of the corresponding roadmap ticket up-to-date. General OSPR management activities don’t include managing the product review process via the platform roadmap board.

      2. The group, coordinator, and/or proposer should add the appropriate label(s) to the GitHub ticket:

         1. What labels do we add to product proposals?

   2. The Coordinator and/or the Core PWG finds volunteers from any of the Product Working Group sub-groups to review the spec to offer general feedback on scope and approach.

      1. Criteria:

         1. Anyone with expertise in the product area can review, even folks from the same organization that submitted, but must have at least one reviewer from a different organization.

         2. See detailed information about finding reviewers here: https://openedx.atlassian.net/wiki/spaces/COMM/pages/3875962884/How+to+submit+an+open+source+contribution+for+Product+Review#Finding-Volunteers-To-Review-Specs

4. Reviewing The Spec

   1. The Coordinator should determine appropriate time boxes for review, and communicate that clearly to all reviewers

   2. Reviewers and/or coordinator should tap others to pull into the process based on the nature of the proposal (other product folks, end users, UX/UI experts, engineering leads)

   3. The Coordinator shares the proposal via the Forums to get broader community input. Please use the Collaborative Proposals section of the forums.

5. Finalizing the spec

   1. Feedback is incorporated by the Submitter

   2. Document release plans/roll-out plans, for proposals with a committed development team

6. Final approval comes from the Core Product Working Group and the proposal reviewers

   1. A proposal is considered approved if there are no outstanding objections

   2. If there are objections, then discussions continue until consensus (3/4 majority) is reached

   3. If consensus is not reached after the Core Product WG’s discussions:

      1. The Axim Product Team will make a final decision;

      2. If there is still discussion and disagreement, the TOC will be the final decider

   4. The Core Product Working Group determines if the proposal is part of the Core Product Offering or lies outside of it

      1. [needs further documentation/reference points - how is it determined? What evidence is needed? What consensus is required?]

7. Steps after product review is complete:

   1. Engineering/architecture review, if applicable (consult the Core Product WG if you need assistance determining if this is needed)

   2. Refinements or additional user stories

   3. Usability testing/AC testing

   4. Maintenance plan

8. Submitting Code

   1. All pull requests should clearly link to the Product Proposal GitHub Ticket. This will have the benefit of linking the pull request back to the Product Proposal ticket.

9. Refinements and Implementation Changes

   1. Any changes made during the implementation and delivery phases that veer away from the original designs or specs must be discussed with the original reviewers and approver(s) of the proposal. Discussion should take place in the original wiki proposal, including a description of the changes, justification and screenshots of any new designs.

...