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

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: @Maksim Sokolskiy (Raccoongang)

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: @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)

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):
@Maria Grimaldi @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!

7. Security Patcher: @Mariagabriela Giorgianni

The security patcher ensures the security of each Open edX community named release by:

• 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.

   Open

   

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

How we make decisions

By default, decisions are made by lazy consensus:

Lazy consensus means that when you are convinced that you know what the community would like to see happen, you can assume that you have consensus in favor of the proposed work and and get on with it. You don’t have to insist people discuss and/or approve your plan, and you certainly don’t need to call a vote to get approval. You just assume you have the community’s support unless someone says otherwise.

Lazy consensus works only if you communicate with enough advance notice, and with enough details that people who would object have the time and the necessary information to do so. Generally speaking, it’s better to over-communicate.

How to work on issues

1. To start contributing fixes, we suggest you pick items from the “TODO” column with the “easy” label. Assign the issue to yourself and move it to “In Progress” column.

2. Update the ‘Due Date’ field with a date at which you commit to providing an update. Please don’t assign the issue to yourself if you cannot start working on it immediately. The due date is not about estimating how long you think the task will take, it’s more about you communicating when you will report on progress.

3. Experienced Open edX contributors can help you get your first pull requests over the line. To ask for help on an existing issue, just add a comment to the ticket.