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
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 group chair is responsible for coordinating the group’s efforts, culminating in getting a new release out, and maintaining the current one.
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
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@Ghassan Maslamani
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: @Maga Jaimes
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.
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
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.
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.
Create an Atlassian account and check out the BTR issue board (see ‘How to work on issues’)
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.
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.
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
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.
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.
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.