This is the proposal I presented during the 2021-01-18 meetup, as my “candidature roadmap” to take over from Regis as BTR working group chair for the next release. These are just suggestions: feel free to shoot any of them down. (It’s why I started a separate topic. )
A Modest Proposal for Lilac and Beyond
This is a presentation of known hurdles the Build-Test-Release working group is facing in the beginning of 2021, and a reasonably straight-forward proposition on how to address them.
The issues listed below were gathered from the Koa Retrospective and the 2021-01-04 meeting video
The following are the main points this proposal will address:
I. Improvement of group organization
II. Tweaks to the release process
III. Specific technical issues
IV. Increasing community engagement
I. Group organization
A. A stronger charter
Before the group can start pushing for more community engagement, it would be wise to flesh out the charter, currently hosted at the group’s Confluenge page. It is suggested that the group take inspiration from OpenStack’s Technical Committee charter, if nothing else for a list of criteria such a document must address, such as membership guidelines and election process. The specifics are left to a future proposal.
B. Move to Github Projects
It is also suggested that the group move to GitHub Projects so as to streamline the management of issues, given the limitations of the current Jira board (such as the inability of regular members to tag other project members).
As a first step, the group could host a subset of issues on GitHub Projects (such as the Community Installation project) to begin with, and if there is clear improvement, then proceed with the remaining ones.
edX have already agreed to have the project hosted on their GitHub Projects page.
C. Streamline communication
By the very nature of the working group, it should be able to accomodate members in all timezones and cultures. This means minimizing synchronous meetings and lowering the language barrier as much as feasible. There are several ways to achieve this, but many successful open source communities solve the issue by sticking to textual communication. The main change as it pertains to this group would be:
i. Reduction of synchronous meetings to a minimum: once every two weeks, or even once a month.
ii. A move from video meetings to Slack, or some other form of realtime text chat.
The brunt of the group’s communication, however, would be held via the official forums or via individual issues.
II. Release process
Open edX releases should be modelled on the Ubuntu Release Process. They already are, to some extent, but the primary motivation in doing so is an argument for doubling the “feature freeze” time. Currently at four weeks, it is recommended that the release branch be branched out a full eight weeks prior to release, so as to give the group more time to iron out bugs, write the release notes, etc.
Ubuntu post their schedule on their forums, a practice which the group should emulate.
The Ubuntu Release Project was heavily influenced by the Gnome Release Process. Reading the original proposal is recommended.
III. Specific technical issues
A. MFE deployment and documentation
There are several issues around MFE deployment. The author of this proposal has direct experience in developing an MFE, and volunteers time to address them.
As for documentation, the MFE development process, and in particular its settings, are not well documented. The author suggests taking advantage of the 2021-01-25 “docathon” to address some of the omissions.
B. Release notes
It is suggested that the group try to get edX to adopt Conventional Commits as a first step in addressing the difficulty in generating release notes. That way, it would be far easier to automatically generate a ChangeLog to use as a basis for them.
Independently, however, at the beginning of each release a “Release Notes Officer” must be appointed, with the responsibility of producing such notes concomittantly with the release itself.
C. The community installation sub-project
As discussed elsewhere, the author reiterates the suggestion that Lilac support both the Community Installation ADR that puts forward Tutor and
edx/configuration, with the latter being explicitly deprecated for removal in the following release, and the former being put forward as “alpha-quality”. This means that the group will have to work on both.
IV. Community engagement
This is by far the hardest issue that the BTR group currently faces: how to get more people involved so that there is a larger pool of resources to tap into, and consequently, a better release produced.
Some of the above items in this proposal can help this along, such as a stronger charter, less synchronous meetings, clearer communication around release schedules,
better more timely release notes, and more time to test releases. All of them together will likely raise the quality and profile of the work the group produces, as well as making it easier to participate in.