1. Fast Track Changes

For small, low-risk improvements (like UI tweaks, content updates, or minor backend/frontend code changes) follow this process:

• Create a GitHub Issue and select “Fast Track Change” in the form

• Get approval on the issue from:

  • One Product Manager (required): Ping the @openedx-product-managers team on your pull request to request product review

  • (Optional) A Product or UX/UI Contributor. Only one review is required, but the Product Manager may request an additional review if needed.

  • Submit a Pull Request once the issue is approved

2. Clear-Scope Bug Fixes

For obvious, user-facing bugs that are straightforward to resolve from a product perspective, follow this process. These fixes are limited in scope, low risk, and don’t require new feature design.

1. File a GitHub Issue in the related repository.

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

   • The reporter or another contributor may do this.

3. Get approval from one Product Manager. This may be done by you or the author of the pull request.

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

   • If no response after ~7 working days, ping the OSPR Manager assigned to the PR for help.

4. Move to engineering review.

   • Once a Product Manager signs off, notify the OSPR Manager assigned to the PR. They will mark the PR as ready for engineering review and assign technical reviewers.

   • Alternatively, you (or the PR author) may ping the team or individual that maintains the parent repository yourself and let them know the changes are ready for engineering review. 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

   • Maintainer information can be found under Projects > Contributions on the right-hand side of the PR.

Open

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

3. Feature Ideas

Follow this lighter-weight process that feeds into the full Product Proposal process when you have an idea you’d like to validate, or if you’d like a feature developed by the community.

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

4. Product Proposals

Anyone in the community can create a Product Proposal. A Product Proposal outlines a suggested change to the Open edX platform. Proposals can be submitted by organizations with a software team ready to implement the change, or by individuals and groups without engineering resources. Clear and detailed proposals are key to helping the community understand and evaluate the idea. Follow the steps below to submit a proposal:

Step 1: Create a Product Proposal that includes the following:

• Link to relevant GitHub ticket and review deadline (see Step 3 for further clarification)

• TL;DR summary

• Overview: 1–2 sentences summarising 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].

• Proposed solution:

  • Indicate how you'll solve the problem.

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

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

• Long-term ownership and maintenance plans

• Contact person (submitter is the default coordinator)

• Optional additions:

  • Open questions about rollout or releases

  • Supporting product designs

  • Supporting market data or user data

  • 2–5 minute video pitch

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

  • Other approaches considered and why they don’t work

Step 2: Submit a Product Proposal on Confluence

• Add your proposal to the Proposed section on Confluence

Step 3: Create GitHub Issue

• Create a GitHub Issue and select “Product Proposal” in the form

• Once created, add a link to the GitHub ticket to the top of your Product Proposal in Confluence, and set a review deadline (7–10 working days is recommended). Example:

Step 4: Coordinate Review

As the Proposal Submitter, your job is to make sure the proposal gets reviewed. Your responsibilities are to:

• Share your proposal in relevant Slack channels, @mention potential reviewers, and bring it up in a Core Product Working Group meeting

• Ensure at least one reviewer is from a different organization

• Ask reviewers to leave comments directly on the Confluence page

• (Optional) Post your proposal in the Feature Ideas forum category, tagging it as a “Product Proposal” to get broader community feedback

If you’re not sure who to approach, use the stakeholder list provided to start conversations:

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

Post an update in the #release-planning Slack channel, mentioning that your proposal has been approved and should be added to the next Named Release on the Community Release Sheet.

• Include a link to your Product Proposal.

• Include a link to your main GitHub issue (or epic) so the Release team can easily reference it.

• Tag the following people to ensure it’s picked up promptly:

  • Group Chair: Maria Grimaldi (edunext)

  • Release Manager: Farhaan Bukhsh (OpenCraft)

  • Release Testing Coordinator: María de los Ángeles Aguilar (edunext)

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