Charter

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)

Membership

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 (eduNEXTedunext)

The group chair is responsible for coordinating the group’s efforts, culminating in getting a new release out, and maintaining the current one.

2. Release Manager: @mtyaka Maksim Sokolskiy (OpenCraftRaccoongang)

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: @DeanJayMathew (ABC Online Courses) 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: Pierre Mailhot 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: @pdpinch Chris Patti (MIT Open Learning)

The Release Documentation Expert is tasked with gathering important information about changes and issues with the latest release, and then building the Release Notes document prior to a major release.

6. Bug Triagers (this is a non-comprehensive list of the people who help fix bugs for the new Open edX® releases. If you notice someone is missing from this list, feel free to add them):
Ghassan Maslamani Maria Grimaldi Maksim Sokolskiy Donato Bracuto

The group's Bug Triagers are, in a nutshell, responsible for the proper use of the group's issue board and for helping to fix bugs in the system!

...

• Collaborating with the Security Working Group to prioritize and address identified security issues.

• Identifying and prioritizing patches to fix security vulnerabilities.

• Leading the testing of security patches before release.

• Documenting security vulnerabilities, patches, and fixes.

• Documenting and prioritizing Open edX software dependencies and libraries to their latest secure versions.
  

8. Product Liaison
   New position!
   The Product Liaison coordinates between the Product Working Group and BTR, ensuring clear communication around new features and their default configurations. This role also ensures that all new features in a release have tests written, in collaboration with product delivery teams, and may assist with improving regression tests. They will work closely with the Testing Coordinator to ensure core platform areas are fully covered.
   

More information about roles, including the specific assignments of each role (and a list of historical role assignments) can be found in our BTR GitHub repository here.

How to join us

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’)

Communication

...

Online discussion happens in the “Build - Test - Release” category at discuss.openedx.org. This is a good place to have in-depth discussions allowing people from all time-zones to participate.

...

...

• The channel is shared into the edX workspace as well. If you are in the edX workspace, ask for an invite.

...

Issues related to Open edX releases are tracked in Github in the BTR project (they used to be tracked in Jira on the BTR board.)

...

Working group meetings are announced in this forum topic. They happen every two weeks to review commitments, discuss and resolve issues related to Open edX community releases. Currently, they happen every other Monday at 15:00 UTC, starting on February 1st, 2021.

...

...