Charter

This working group is chartered with the direction and ownership of the Open edX community releases. Its goals are to create and maintain Open edX releases for use by the global community.

For instance, you might want to reach out to the Build - Test - Release working group (BTR) in the following situations:

• You want to report what you think is a bug in the existing 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 explicitly does not concern itself with the following topics:

• Development of new features

• Maintenance of older 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.

Members

Working group membership is not binary – we are not a political party. Instead, we value concrete contributions, such as bug reporting, fixing, release testing, documentation efforts, etc.

The process of selecting and replacing working group leaders is still to be formally decided. For now, election of new leaders is made by lazy consensus (see below, under How we make decisions). The current working group roles and their assignments are listed in the build-test-release-wg repository on GitHub.

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

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.

• Short synchronous chats happen in the #wg-build-test-release Slack channel.

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

• News are posted every two weeks, alternating with the video meetings, on this thread at discuss.openedx.org.

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.