2.2. Contributing#
Contributing your custom code to the Open edX project is a two-step process: review of your idea by the product team (the Product Review Process), followed by a review of your code by the project’s core committers. We describe this process on the Product Review Process wiki page.
Note:
By and large, bug fixes do not require the Product Review Process.
However, if your bug fix will change user facing behavior, you should
check with the Product Working Group on the best way to land your fix
before beginning to write code.
2.2.1. Product Review Process & Product Roadmap#
New features added to the Open edX project go through a Product Review Process, lead by the Open edX Product Working Group. If you’re interested in adding new features, we ask that you undergo the product review process _before_ you begin coding your feature. This allows the project to get alignment on new features and help guide you to implement the feature in a way that works with the overall platform. Additionally, there might well be someone else already working on the same change you want to make, and it’s much better to collaborate than to submit incompatible pull requests.
If you open up your feature request with a solid description, the product owners will be able to quickly understand your change and prioritize it for review. However, they may have some questions about your intention, need, and/or approach that they will ask about.
To read more about the product review process and how to submit your idea, please visit the Product Review Process wiki page.
Features that the project wants, as well as ones being currently worked on by community members, are represented on the Product Roadmap. This kanban-style board represents units of work on individual cards. Check out the tickets on the far left for help reading the board. The tabs at the top will allow you to drill into roadmap tickets by platform area.
If you’re interested in contributing to the Open edX project but don’t know what to contribute, check out the roadmap! If you’re interested in picking up or collaborating on a ticket, join the conversation by adding a comment on the ticket.
2.2.2. Getting Preliminary Feedback#
It is sometimes useful to submit a pull request even before the code is working properly, to make it easier to collect early feedback on your implementation. To indicate to others that your pull request is not yet in a functional state, just prefix the pull request title with “(WIP)” (Work In Progress), and start the pull request as a draft on GitHub.
Please include a link to your roadmap ticket in the PR description, and add a link to a WIP pull request in any discussion threads you start.