| Table of Contents |
|---|
| Note |
|---|
This page of out-of-date, but the information it contains may still be useful. Contributors: If you have time, update this page! |
Introduction
Hi! If you are new to contributing to the Open edX platform, this is the place for you! This document will guide you from scratch to become an active contributor to the Open edX platform.
...
Fork the Open edX project you want to contribute from the official Open edX Github repository to your Github account
Clone (if it is the first time, pull if you already have a local copy) the project from your fork of the repo
Check out your local devstack installation to the master branch. You should only make PRs on the master release for -at least- three reasons:
Branches based on old commits may not get merged in the next release
Your change may have already been implemented
The files that you want to change may have disappeared, been moved, or modified
Run the unit tests for the app your want to change to make sure that the installation is clean. Do this before any change. Undo or discard any change to the pulled branch.
...
Create a Jira issue explaining your change. If it is a bug fix or an improvement, you can use the Community Reported Issues project.
Create a local branch with the name of the Jira issue and check it out. This way, your changes can be easily identified. Create the branch in the remote repo also.
Make your changes. Try them until you are sure they work as you want, and everything else still works.
Write or update unit and integration test procedures. There is a great guide about how testing in Open edX works here. You can also learn from the Django testing documentation.
Run again the tests for your applications. Pay special attention to your new code.
Commit your changes to your newly created branch. Be as clear as possible in the commit message
...