Fast Track Changes

Process for small changes:

• Create a GitHub Issue: Use the standard feature request issue (the same one is used for both small changes (“Fast Track Change”) and large changes (“Product Proposal”)). We propose the form includes:

  • Radio button: “Fast Track Change” or “Product Proposal”

  • Title: Clear and descriptive

  • Feature Description: What is being proposed (Copy TL;DR from your proposal if you have one)

  • Link to product proposal (optional for “Fast Track Changes”)

  • Set the issue status and labels:

    • Label: product proposal

    • Status:

      • New or In Review

  Open

  

• Get async approval on the GitHub Issue by:

  • One Product Manager -- Current list of product managers

  • (Optional) Additional Product or UX/UI Contributor (does not have to be a Core Contributor). One review is enough, but the Product Manager reviewer may request an extra review from a Product or UX/UI contributor if they feel it’s needed.

• Raise a PR if approved: Once the GitHub Issue is approved, you can submit a pull request.

Clear-Scope Bug Fixes

• File a GitHub Issue for any user-facing bug in the related repository.

• Fix the issue and open a pull request with the changes.

  • This may or may not be done by you as the reporter of the GitHub Issue.

• Get async approval of the fix from one Product Manager. This may be done by you or the author of the pull request:

  • Ping the current team of project managers (@openedx-product-managers) on the pull request for product review.

  • If nobody from that team picks up the review after ~7 working days, ping the OSPR Manager assigned to the pull request for help.

• Notify the OSPR Manager assigned to the pull request once the Product Manager signs off on the changes, so they can mark the pull request as ready for engineering review and start the process of finding technical reviewers. Alternatively, ping the team or individual that maintains the parent repository of the GitHub Issue and corresponding pull request yourself and let them know that the changes are ready for engineering review.

  • This may be done by you or the author of the pull request.

For an example of this contribution pathway, see:

• Original bug report: frontend-app-learner-dashboard#684

• OSPR that fixes the issue: frontend-app-learner-dashboard#716

Information about who maintains the parent repo of a pull request can be found under Projects > Contributions on the right-hand side of the pull request:

Open

Here, the maintaining team is @openedx/wg-maintenance-edx-platform.

Feature Ideas  

This is a lighter-weight process that feeds into the full Product Proposal process when needed.

1. Visit the Open edX “Feature Ideas ” category

2. Create a new topic for each idea.

3. Select the “Feature Ideas” category when posting.

4. Include the following details in your post:

   • Overview: 1–2 sentences summarizing the idea.

   • Problem: 1–2 sentences describing the main user problem or barrier.

   • Use Cases: As a [course author/instructor/learner], I need to [do something] in order to [achieve a specific outcome].

   • Supporting Data (optional): Interview notes, survey results, etc.

5. Share your idea: Once posted, share it with others! You can:

   • Mention people who might be interested

   • Share the link in relevant Slack channels

   • Bring it up in a Working Group meeting

6. Voting & Prioritization: From time to time (timeline TBD), we’ll post a poll to help identify the most valuable ideas. Your votes will help guide which ideas are prioritized for development.

Product Proposals

As agreed by majority, Confluence is the most suitable tool for product proposals as it offers version history, in-line comments and editing features.

So, proposals will be created on Confluence using following template:

1. TL;DR summary

2. Overview: 1–2 sentences summarising the idea.

3. Problem: 1–2 sentences describing the main user problem or barrier.

4. Use Cases: As a [course author/instructor/learner], I need to [do something] in order to [achieve a specific outcome].

5. Proposed solution:

   • Indicate how you'll solve the problem.

   • Include screenshots of the current and proposed UX and UI for better context.

6. Implementation plan (including technical implementation, resources and funding status)

7. Long-term ownership and maintenance plans

8. Contact person (submitter is the default coordinator)

9. Optional additions:

   1. Open questions about rollout or releases

   2. Supporting product designs

   3. Supporting market data or user data

   4. 2–5 minute video pitch

   5. Competitive research (e.g., how Canvas/Moodle/Coursera solve this)

   6. Other approaches considered and why they don’t work

We will also have a stakeholder matrix in the template. This will allow submitters to quickly initialize conversations with relevant stakeholders/domain experts and speed up the review/feedback process.

Step 1: Submit a Product Proposal on Confluence

Then share it widely:

• @mention potential reviewers in Slack

• Share in relevant Slack channels

• Raise it in a Core Product Working Group meeting

Step 2: Create GitHub Issue

• Create a GitHub Issue by using the standard feature request issue template, which we propose includes:

  • Radio button: “Fast Track Change” or “Product Proposal”

  • Title: Clear and descriptive

  • Feature Description: What is being proposed (copy TL;DR from your proposal)

  • Link to product proposal (mandatory for “Product Proposals”)

  • Set the issue status and labels:

    • Label: product proposal

    • Status:

      • New or In Review

Step 3: Coordinate Review

As the submitter, you are the Proposal Coordinator by default. (This will be communicated by a note within the template)

You are responsible for:

• Recruiting reviewers via Slack and Forum (based on product area and impact)

• Ensuring at least one reviewer from a different organisation

• Setting a review deadline (7–10 working days recommended)

• Asking reviewers to comment directly on Confluence

Step 4: Finalise the Proposal

• Once the proposal has been reviewed, update it to reflect reviewer feedback and decisions

• Ping the reviewers again on Confluence to notify them that the proposal has been finalized

Step 5: Seek Approval

• The proposal is approved if there are:

  • No objections from reviewers or the Core Product Working Group

  • General agreement (e.g., 3 out of 4 rule)

  • Lazy consensus rule

    • If 1 person explicitly approves and there are no objections.

    • If no one responds, but also no objections are raised, the submitter can escalate to get an explicit review (so we don’t accidentally merge without any eyes).

    • If any objection is raised, it needs discussion and explicit resolution before moving forward.

• If needed, escalate to:

  • Axim Product Team

  • TOC (for broader prioritization)

as long as there are no outstanding comments, and as long as there is consensus on the proposal and no adverse feedback, the proposal can be considered approved.

Step 6: Execute Post-Review Steps

Once the proposal is approved:

Add the project to the Community Release Sheet under the appropriate tab, once a team is committed to implementation.

Step 7: Teams Execute Product Proposal

Designers

• Design wireframes, prototypes, and final UIs

• Discuss any deviations from the approved proposal with the Proposal Coordinator and/or Core Product Working Group

• Update the original proposal (in Confluence) with:

  • Design changes and rationale

  • Final design screenshots or links

Developers

• Link all pull requests to the related GitHub issue to ensure traceability

• Follow the documented workflow for code contributions (proposal → PR → merge)

• If the implementation deviates from the proposal, update the original proposal with:

  • Technical changes and justifications

  • Supporting diagrams or screenshots