...

In Open edX we use a fork and pull model for code delivery. This means that contributors cannot commit changes directly to the edx repositories. As a contributor, you can fork the source repositories into your own github account, commit changes in it, and submit pull requests automatically from there. When you do this, both branches at the source and the fork repositories remain linked, therefore when you make additional commits in your fork’s branch, it will update the original pull request until it is completed.

Release lifecycle

In Open edX, code base development is organized in two main branches:

• master branch

• named branches

Master branch is where all the new developments occur. Every six months, a new named release master branch is created from the master branch.

Named releases are explained in detail in the developer documentation. All production deployments must be done from the master branch of the named releases, and never from the master branch. Names of the named releases is inspired from tree names, and are ordered alphabetically (e.g. ficus, ginkgo, hawthorn, ironwood, juniper, koa, etc.).

One month after a new named release is created, the previous named release master branch ends its support life. If you need to fix a bug after that date, you’d better migrate to the new named release.

The following diagram depicts more or less the life cycle of a named release branch:

...

Depending on what kind of change you want to make into the platform, you may need to commit to a named release branch or to the master branch:

• Bug fixes:

  • Of a feature that is not likely to be deprecated before the release of the next named release:

    • First make the change in the master branch. This will ensure that the change is propagated to the next named release.

    • Then backport the change to the current named release master branch

  • Of a feature that is needed in the current named release, is worth the effort without waiting for the new release, but will be deprecated in the next named release or the feature will change so significantly that the bug would have no effect in the future:

    • Make the change in the master branch of the named release only.

  • Hot fixes, including critical security patches:

    • Make the change first in the named release master branch, so that it can be deployed in production as soon as possible

    • Backport it to the master branch so it persists in the next releases.

• Other changes to the core code must be made only in the master branch, and never in the named release master branch.

  • New features

  • Deprecations

  • Improvement to existing features

• Documentation changes

  • Documentation follows the same guidelines as code changes, with the exception that unit or integration tests are not needed. Instead, the community experts should review documentation contributions for accuracy, relevance and style.

Bug fixes and feature improvement opportunities can be reported in the Community Reported Issues project. However, if it is something simple and you think you have a fix, you can directly create a pull request and follow the discussion there. Once you crate a pull request, a new issue in the Open Source Pull Requests project.

New features normally are complex endeavors. You can submit your proposals to the Open edX roadmap. Submissions are reviewed and prioritized periodically. If you feel you can help here, don’t hesitate to participate.

Many features often get obsolete. We often review unneeded code and start new issues in the Deprecation and Removal project. This is another place you can work on. Ask one of the project managers to assign you a task from here to start working on it.

Documentation is an important part of any project. Your help in keeping accurate, clear and updated is very valuable.

How to start

There are three main start points for your contributions:

...