Carrying on the tradition started by Adolfo’s “A Modest Proposal for Lilac and Beyond”, this my “candidature roadmap” to take over from Adolfo as BTR chair.
From my perspective, the group now has a baseline shape and going forward it needs to refine its processes by removing the main areas of friction. The suggestions below are not all mines by any mean! I’m simply trying to articulate them in a way that made sense to me and that’s actionable going forward.
In the last six months, the group has accomplished a lot and I wouldn’t be able to do it justice in this post. In summary, Lilac was delivered on time (with the release notes!), with new shiny MFEs and tutor as an officially supported installation.
In light of the news about edX merger with 2U and the move to a new ownership of the Open edX platform, the community, and the BTR group with it, has the opportunity to step up to ensure that the Open edX platform remains the best open-source online learning solution on the market.
Can we up the cadence for Maple?
Now that the group has a more shaped-up set of processes, it needs to focus on removing the main points of friction.
The issues listed below came out of the Lilac Retrospective. They are grouped around the core functions of the group.
Issues
Build
- The work MFEs illustrated the importance of clearly defining expectations on tasks and making sure it was communicated.
- The group’s ability to take on challenging projects is limited by the number of participating members.
Test
- The testing process was done with very little coordination and communication and the outcomes of the testing were not recorded.
Release
- The process is still complex and needs refining.
Build better
1. A template for BTR tickets
To communicate clear expectations on BTR tickets, the group needs to agree on a minimum set of information that should make the body of a ticket. From there, the group can use an issue template to make it easier for anyone to follow the guidelines.
2. Assign a ticket reviewer
BTR members should not only take on tickets but also dedicate a portion of their time to review other tickets. This would be a good way for the group to spread the burden of tickets review and push each other to deliver.
3. Weekly Update
To attract more members, it’s important for the group to be transparent and present on the main channels of communication of the community. A consistent weekly update with information on what the group is currently working on and where help is needed will help in that direction.
More Testing
1. Rigid deadlines
The group has recognised that moving the deadline for tagging release candidates made it difficult to start testing. Going forward, the group will increase the bar on what requires a shift in the release timeline.
2. A more actionable testing process
Testing the deployment of the Open edX platform is not a simple task, especially given the different use cases that it supports. However, members of the community do run their own tests, the challenge is to collect the results of those tests. It is recommended that the Release Testing Coordinator takes on the task of ensuring that “testers” (individuals or organisations) share their results.
3. Open sandbox to the community
In order to help to test, It is suggested that the group facilitates the deployment of a public instance of release candidates to encourage non-technical community members.
Smoother Release
1. Identify steps that can be automated
Now that the steps required to make a release have gone through one cycle of being done by a group member that is not part of edX, it opens up the opportunity to add some automation to the process.
For example, using Github Actions to tag the release branches could be a way to fully move the ownership of that step to the group.
2. Create a checklist
By removing some of the more time-consuming steps. the item above will facilitate the creation of a clear checklist for the release process. This checklist should be materialised in the form of an issue template.