A Modest Proposal for Lilac and Beyond

Working Groups Build-Test-Release
1

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

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.

Sources

The issues listed below were gathered from the Koa Retrospective and the 2021-01-04 meeting video

Issues

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.

10 Likes
2

Hey Adolfo, thanks for this write-up, and thanks for applying! I’d like to comment on some of the points you mentioned and for which I have some level of disagreement. Otherwise, I am generally in support of your other propositions.

I think we should not try to change what is working well. Creation, assignment and resolution of Jira issues is a smooth process that is quite functional for the working group. I hate Jira just as much as anyone else (@pdpinch’s “consistently alienating” description is fitting) but there are arguments in favour of Jira and against Github issues. They were outlined by @nedbat in a previous meeting and I summarized them in writing here: **Task Management.** As a contributor, I would like to manage my Open edX tasks in a publicly visible and accessible space, in order to collaborate and innovate with others. · Issue #174 · openedx/open-edx-proposals · GitHub

IMHO, the strongest argument is that edX employees do not track Github issues, and moving to Github would create yet another barrier between edX and the rest of the community.

Concerning synchronous meetings: it was decided in September that we have more frequent synchronous meetups, not less frequent, in order to reach decisions faster. What we have observed is that it’s much easier to take decisions and assign tasks to people when we meet “face to face”. So whatever decision we end up making, we should be careful that we do not make a step backwards in terms of efficiency.

Of course I fully agree with you with the problem analysis, but I have a different opinion about the solution. I believe that in order to mobilize more people, we need better incentives to contribute. This is the “behaviorist” argument if you wish. One way to incentivize people more is to give them better rewards for their contributions, e.g: by means of publicity.

2 Likes
3

@Adolfo, there is a lot here! For effective discussion, I think we need a thread per topic…

4

Well… The reason I proposed GH issues to begin with was that it was brought up by @nimisha, an edX employee. :man_shrugging:

But one way or another, we need to be able to tag other people in comments. If that can be solved in Jira, great. If not, IMHO we need to find another solution. @nedbat, do you by any chance know if we can fix thix in our current board?

Would it be too passive-aggressive of me to suggest moving this discussion to the github issue you pointed to? :slight_smile: In all seriousness, though, I wasn’ t aware of it - thanks!

I agree it’s easier, provided all stakeholders are available to meet synchronously. In an office, that’s a piece of cake. It’s why most organizations are plagued with meetings. In a globally distributed community, where each person is part of a separate org to begin with? I think such meetings cost too much - the price being reduced community participation.

Let’s, of course, discuss this a lot more before making any changes. I’m sure there’s a middle ground that gets us at least part of the advantages of each side.

I agree - but usually, at least in the open source communities I’m familiar with, having your name (or your company’s) in the commit message is enough publicity. If the contributor wants more, they pay for it: see OpenStack’s membership hierarchy. edX themselves provide a form of the latter via Open edX Con sponsorship opportunities.

We could come up with a bounty program (which IIRC you suggested in the past), but I don’t remember seeing projects benefitting greatly. Maybe if we put a more modern twist on it, say by emulating the Kickstarter or Patreon model? I think this is worth a wiki page/dedicated topic so we can brainstorm options.

How about if we get a quick round of dissentions, following Regis’ example, and then deal with each issue separately in the board?

5

Thanks @arbrandes for putting this together! My own review/comments:

  1. For the choice of the tool, those are discussions that can always be dragged forever. Imho given the priority of the group to solve engagement, and ability to communicate is an important element of that, so the chosen tracker - whichever it ends up being - should solve the issue related to being able to ping people. In that sense, github issues does have an advantage over the other tools, where we always struggle to keep discussions going due to lack of functional/easy pings. +1 to move it to the existing discussion about this though.

  2. Less/more synchronous meetings – I agree that we need to develop asynchronous communications. Timezone and other meetings often compete in the agenda, and having the discussions mainly held in synchronous meetings means that it reduces the ability for others to be involved in them or have the full context.

    That said, I agree with @regis that we need to be careful to not break things that do work - it’s not ideal, but at least the current synchronous meetings allow to provide a regular checkpoint and pace, as well as allow people involved to see each other. So I would not go below a 2 weeks periodicity, and I would keep the video meetings rather than chat – at least until the async part has developed enough to be able to rely on it. To help with this, maybe the decision-making process could be progressively moved from the meetings to discourse, by saying things during meetings like “let’s take this on the forum, to see what everyone thinks, and try to get to a consensus there before the next meeting?” And then the next meeting can still act as a fail-safe if something blocks, to allow to adjust.

  3. Community engagement - I think one of the main things missing currently is a strong sense of responsibility assignment. When many people are responsible for something, nobody really feels responsible for it. I think beyond your role as the group chair @arbrandes, there should be other roles being developed - maybe someone in charge of triaging bugs for the upcoming release? One to act as a “release master” who will cut the branch and make the operations to publish it? etc.

    And same things on individual tasks - identifying a series of tasks and actions that people could take on to work on the group could be useful, with a clear ask to pick them up, and a way to be assigned. Having small ones for people who are new, like the byte-sized tasks but for the group activity rather than just code stuff on Open edX, could help newcomers to get started.

1 Like
6

@nimisha put up a poll as a comment on that issue. Though the BTR group doesn’t necessarily have to follow the outcome, I encourage members of the group to vote. At the very least it will inform our decision.

Fair enough. Small steps.

+100 for assigning volunteers/officers/masters to broad categories of issues, and a clearer, more frictionless way to assign individual tasks, categorized with some form of “low-hanging fruit” tag for newcomers.

7

First and foremost, thanks @arbrandes for your proposal.

I’m just getting started with my involvement in the BTR discussion. I just leave my humble opinion:

  1. Management issues tool: Already moved to @nimisha issue in Github and discussing there.

  2. Less/more synchronous meetings: I think we need to work on an asynchronous communication model that requires other elements like the enforcement of a charter. As @antoviaque suggested, new roles inside the BTR team could be created, and those roles map to smaller workgroups with a well-defined set of tasks to be committed with. This could give more independence to every role/group for decision-making processes and task management. However, I consider a video call is still required to check the current status of the BRT as a whole and the roles/groups, and also to align efforts for future objectives. This video call would be less frequent, for example, once a month.

I’m not pretty sure how the moving process to a new model would be, but this would be progressive, keeping what has been working so far and doing incremental changes, allowing us to assess the effectiveness of every taken step.

  1. I agree with @regis , rewarding people for their contributions and commitment will more effectively hook them into the community and will strengthen the sense of responsibility @antoviaque mentioned. These rewards can stick to a defined charter according to the level of commitment of the member. I remain attentive if you move this point to a dedicated space so we can continue with the brainstorming.
1 Like