Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


The BTR working group is chartered with the ownership and direction of the Open edX® community releases.

We test, fix, document, release, and maintain new community versions of the Open edX® platform for use by the global community, ensuring a stable release to the best of our ability. If the BTR working group sounds like the right group for you, we look forward to having you join us. Scroll down to the How to join us section below to get started!

You might want to reach out to the BTR working group in the following situations:

  • You want to report what you think is a bug in the latest Open edX® release.

  • You want to help improve the current Open edX® release, but as a new contributor you need help to get your first pull request merged.

  • You want to help craft, test and fix the next Open edX® release.

Note that the BTR working group explicitly does not concern itself with the following topics:

  • Development of new features

  • Maintenance of older community releases

  • User support

  • Maintenance of the master branches

  • Maintenance of 3rd-party alternative installations: only the official community installation is supported (other installation methods are supported on a best-effort basis)


We are an open and collaborative working group so feel free to join us no matter your background or intended level of commitment. Membership is not binary – we are not a political party. Instead, we value concrete contributions, such as bug reporting, fixing, release testing, documentation efforts, communication, et cetera.

We have a Group Chair (a leader) but the method by which we select and/or replace the leader is still to be formally decided. For now, election of the Group Chair is made by lazy consensus (see below, under How We Make Decisions). The current working group roles are as follows:

1. Group Chair: Jorge Londoño (edunext)


The release manager is responsible for the actual cutting of a release, which, in essence, includes following the steps in the Process to Create an Open edX Release.

3. Release Testing Coordinator: Vacant Peter Pinch

The release testing coordinator is responsible for making sure release candidates are tested before a tag is made (i.e. before a new release is published for community consumption). The coordinator does not necessarily have to run tests themselves, but they will coordinate testing in general.

4. Quality Assurance Manager: Vacant

The QA Manager helps to, amongst other things, ensure that the Software Testing Life Cycle (STLC) is of high quality and meets the community general standards for a new release.

5. Release Documentation Expert: Chris Patti (MIT Open Learning)


  1. Create an account in the Open edX forums and write a good summary about yourself. Feel free to indicate the organization you work for (if any). We are welcoming and supportive of newcomers.

  2. Enable notifications for the Build-Test-Release subcategory. You should select at least the “Watching first post” notification level.

  3. You may want to join the weekly synchronous online meetups, though it is not mandatory to participate in all or any. If you are interested, you should set the notification level of this specific topic to “Watching”. Feel free to watch the recordings of the previous meetups to get a feel of the working group.

  4. Create an Atlassian account and check out the BTR issue board (see ‘How to work on issues’)


GitHub Issues/Projects

  • Issue tracking

  • Technical discussion


  • Announcements

  • General discussion


  • Status updates

  • Questions

Joining via



  • Open discussion