Quick Start: So You Want to Contribute to Open edX#
So you have gone through Quick Start: First Open edX Pull Request, and you are ready to make a substantive contribution to Open edX. What is next?
Start Here!#
Before we can merge your contribution you will need to sign a Contributor License Agreement (CLA). We suggest starting that process sooner rather than later.
If you are contributing as an individual go ahead and sign the Individual Contributor Agreement.
If your work will be contributed as part of a company or institution, have your team or company lead email
legal@axim.orgwith your information.
Process Overview#
Open edX follows a standard pull request review process, entirely using GitHub. Here is a simplified version of the PR process:
See the Process for Contributing Code document for more details.
See the Pull Request Status Guide if you’re looking for more information about what the various statuses and labels of your pull request (PR) mean.
Finding Something To Work On#
One source of candidates is this list of issues labeled “help wanted”. Some maintainers also label issues with the “good first issue” label. We also encourage you to check out our Working groups! There are a few working groups that may have some work they can help guide you through as a new contributor to the project. Particularly:
The Build-Test-Release (BTR) Working Group: they manage our named releases, which come out each June and December. They particularly need help from mid-February through June and again from mid-August through December.
The Frontend Working Group: they manage the state of our frontend, including both new features and upgrades. They would love more people to join them!
The Deprecation (DEPR) Working Group: they work on deprecating various aspects of the Open edX platform. Some deprecations are pretty approachable, others are rather complex. Reach out to them to see if they have anything you might be able to work on.
The Documentation Working Group is developing, migrating, and improving documentation for the Open edX Platform. This is a good first task that is non-technical, and open to anyone who builds on the platform. To learn more about helping with this, reach out in the #wg-documentation Slack channel and let the group know you are interested.
The Product Working Group reviews and approves new feature proposals. On their Github project board there is a column titled “Backlog - Not resourced, can be picked up” which contains larger projects you or your team may be able to tackle. Reach out in #wg-product-core if you’re interested in tackling one of these issues, to ensure no one else is working on it.
The other working groups are very interesting (and worth attending!) but don’t have a backlog of work.
Do you have an idea of what to work on? That’s awesome! We encourage you to post your ideas on the Open edX forums to get feedback on your idea and get connected to others that can help you out. Please clearly state your idea, what you plan to do, link to any relevant code/screenshots, and ask specifically for what type of feedback or help you are looking for.
Development Environment#
Tutor is the official Docker-based Open edX distribution, both for production and local development. There is a Tutor Topic on the discussion forums to get help specifically on Tutor or you can post in the Development category on the Open edX forum if you have questions about set-up or development.
Getting Support#
Please use the Open edX forums to ask for help. First, search for your question/issue/stack trace before asking a question, as it may already be answered! We recommend first posting in the forums, then cross-posting the link to your forums post in Slack if you want to draw more attention to your post.
Why? The Slack history is deleted after 6 months but the forums history is never deleted, so your questions there will be displayed to people searching for similar questions in the future.
Making Your First Pull Request#
Follow the Open edX Git Workflows, and the instructions for Landing Your Work.
Don’t forget about signing your CLA!
When you are ready to submit changes, create a Pull Request.
Be sure to reference which ticket your code is resolving.
Please read the bot’s comment on your PR carefully, and ensure you have done everything that is asked for.
If you did work for a working group, post your pull request in the appropriate WG Slack channel.
Once your code has begun to be reviewed, communicate with the reviewer about the code and respond to feedback promptly. Note that it may take a week or two for a review to begin on your PR. If after that time your PR still doesn’t have any attention, feel free to ping the maintainer mentioned in the bot’s message for attention.
Once your PR is approved it will be merged by the reviewer.
Celebrate 🎉!!!
How To Streamline Getting Your Contribution Merged#
When pull requests come in they need to be reviewed by team that maintains the repository. Depending upon that team’s priorities, it may take some time to get your review scheduled. We aim at having predicable lead times and transparency about what is happening and when. There are things that you can do as a contributor to help.
If your change in still in progress or experimental, please open the pull request as a draft. We won’t focus on reviews until the code is ready and this will reduce wasted attention on both sides.
Make sure that you describe the purpose of the change that you are proposing clearly in the description of the pull request and why the change is valuable.
Read the bot messages on your PR carefully.
Follow the Landing Your Work instructions carefully, including using Conventional Commits, considering internationalization/performance/security, and more.
Allow admins to push commits onto your branch. GitHub has settings that allow reviewers to push commits onto your branch. This feature is valuable when the branch is out of date with the base. Reviewers can update your branch from the base with a merge commit that will isolate those changes. This decreases the back-and-forth, which can add days to review times.
Mention related pull requests in the PR description so reviewers can review them as a single body of work and avoid context shifts.
Check the checks. GitHub requires that the Open edX team run checks manually for new contributors. When there are failures, please review them and address them quickly to ensure a timely completion of your review. Failures you may see include linting errors, test failures, failures related to decreased test coverage, etc. On occasion failures may not be related to your change, but can be fixed by merging in updates on the base branch. If you believe this is the case, please update your branch.
Working with GitHub Issues#
Work on Open edX is often tracked on GitHub issues, which are organized on GitHub project boards.
Anyone with a GitHub account can interact with our GitHub issues in some basic
ways using issue commands.
For example, if you would like to work on an issue, let everyone know by simply
commenting assign me!
Once you have established yourself as involved in a working group or some other
project, feel free to request “Triage” access to our repositories. Open an Axim
Request using the “Onboarding” template, and specify that you would like
Triage access in order to be more involved in the project. Provide a link to
what you are working on, and @-mention another GitHub user who you have been
working with who can vouch for you. If Axim grants the request, then you will
find that you are now able to manage assignees, labels, and handful of other
aspects of Open edX GitHub issues.
Once you have Triage access, you can also ask project leaders to give you access to individual project boards that you want to help manage, which will let you change status and other metadata on project issues.
Giving Feedback#
We are always looking to improve this process and make it easier for people to contribute to the platform. Your feedback is a very important part of that process.
If you have specific praise, or constructive criticism you think the community could benefit from, please post on the Open edX forums.
Maintenance chart
Review Date |
Working Group Reviewer |
Release |
Test situation |