Before you make a pull request, it’s a good idea to reach out to the edX developers and the rest of the Open edX community to discuss your ideas. 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. The Community Discussions page on the open.edx.org website lists different ways you can ask, and answer, questions. The earlier you start the conversation, the easier it will be to make sure that everyone’s on the right track – before you spend a lot of time and effort making a pull request.
If you’ve got an idea for a new feature or new functionality for an existing feature, and wish to contribute your code upstream, please start a discussion on JIRA (you may first need to create a free JIRA account). Do this by visiting the JIRA website and clicking the “Create” button at the top. Choose the project “Open Source Pull Requests” and the issue type “Feature Proposal”; in the description give us as much detail as you can for the feature or functionality you are thinking about implementing. We encourage you to do this before you begin implementing your feature, in order to get valuable feedback from the edX product team early on in your journey and increase the likelihood of a successful pull request.
It’s also sometimes useful to submit a pull request even before the code is working properly, to make it easier to collect early feedback. To indicate to others that your pull request is not yet in a functional state, just prefix the pull request title with “(WIP)” (which stands for Work In Progress). Please do include a link to a WIP pull request in your JIRA ticket, if you have one.
Once you’re ready to submit your changes in a pull request, check the following list of requirements to be sure that your pull request is ready to be reviewed:
It’s also important to realize that you and the core committers may have different ideas of what is important in the codebase. The power and freedom of open source software comes from the fact that you can fork our software and make any modifications that you like, without permission from us; however, the core committers are similarly empowered and free to decide what modifications to pull in from other contributors, and what not to pull in. While your code might work great for you on a small installation, it might not work as well on a large installation, have problems with performance or security, not be compatible with internationalization or accessibility guidelines, and so on. There are many, many reasons why the core committers may decide not to accept your pull request, even for reasons that are unrelated to the quality of your code change. However, if we do reject your pull request, we will explain why we aren’t taking it, and try to suggest other ways that you can accomplish the same result in a way that we will accept.
Once a pull request is open, our faithful robot “Botbro” will open up a JIRA ticket in our system to track review of your pull request. The JIRA ticket is a way for non-engineers (particularly, product owners) to understand your change and prioritize your pull request for team review.
If you open up your pull request with a solid description, following the pull request cover letter guidelines, 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 on the JIRA ticket. A community manager will ping you on GitHub to clarify these questions if they arise; you are not required to monitor the JIRA discussion.
Once the product team has sent your pull request to the engineering teams for review, all technical discussion regarding your change will occur on GitHub, inline with your code.