Contribution experience report: Mattermost

Welcome to my fifth contribution experience report. I have done others for:

This one is about contributing to Mattermost. Mattermost is a chat application for teams, often seen as a FOSS replacement for Slack as it offers a very similar user experience.

My motivation to contribute

I identified a small issue in the user interface: a checkbox not being properly associated with the text that describes its function, meaning that clicking on the text would not have any effect on the checkbox itself.

I encountered this problem when setting up a test instance of Mattermost to evaluate the feasibility of using it as a Slack replacement for Kanthaus. The problem was clearly not a blocker for me but it felt like a good opportunity to evaluate the contribution process to this project.

First contact with the project

I just went ahead and opened an issue on the mattermost/mattermost GitHub repository. As the Mattermost website makes it clear, this project is run with the “open core” model, meaning that it is controlled by a company which sells a proprietary version built on top of the open source core. So it wasn’t surprising to me that contributing required signing a Contributor License Agreement (enabling them to change the license of the open source project as they please). That’s of course not ideal - it’d be much better to have the assurance that the core project indeed remains open source and be run by an independent organization. But for the sake of evaluating the experience, I went ahead and signed it.

Development environment

The change I wanted to make to fix the problem was really simple: adding a containing <label> tag to properly link the checkbox to the text. It’s something I could test out by opening the web developer tools in my browser and manually editing the HTML structure. So for the first version of my PR I didn’t even set up any sort of development environment and just manually edited the React component where this checkbox was, so that it renders the correct DOM structure.

When more changes were requested I did follow the contributor guide to set up my development environment. That relatively simple and easy to follow. Most of the time was spent waitaing for NPM and Go packages to download. The most cumbersome part of the workflow was that their setup uses docker compose (not docker-compose), and installing it required adding a Debian repository of Docker.com to my sources.list. I always find it nicer when the development tools required aren’t so bleeding edge and are readily available in Debian.

Finding my way into the code base

The technique of searching for UI text (in this case the checkbox’s label) worked very well: it directly took me to the React component where the form was defined.

Reviewing experience

My PR got a first review from a developer the next working day, which was nice.

The checkbox in question had another problem: it was implemented as a button element, whose appearance would change after being clicked by inserting an SVG image in it to make it look checked. This bizarre set-up was probably introduced to customize the appearance of the checkbox, but it was really weird because (at least on my platform) the appearance was really close to the native one.

The reviewer noticed that and asked me to clean this up in the same go. It felt reasonable since it would contribute to cleaning up the DOM structure there and making the form more accessible, so I did this small change (which required me to actually set up a development environment, but it was a bit bold to skip that part anyway).

Another interesting aspect was that the developer who first responded added tags to my pull request, marking it as requiring a “dev review”, a “UX review” and a “QA review” - all done by different people!

The UX review person noticed a small change in alignment between the checkbox and its label and asked me to bring it back in line with the original. I was given a very precise zoomed-in screenshot with added guide lines, which felt pretty precise and helpful.

What I found very interesting is that they have a system in place to spin up a test Mattermost server from the PR branch, just by adding a label to the pull request. This is something I have considered doing for OpenRefine for some time, because I think it would massively help with getting more community members review pull requests from a user standpoint, without having to learn anything about Git or installing any sort of developer environment on their side. It encourages me to look more into it.

All in all it took 19 days from the opening of the PR to it being merged (with me prodding them only once to get another round of reviews).

Testing infrastructure

For my change, no test was requested from the reviewers, so I didn’t look into that topic at all.

Code formatting

The CI did notice some style violations, which I fixed by running make fix-style. On my machine, this command took about 120 seconds to run, which felt not ideal since that’s something you generally run often.

Governance and roadmap

Mattermost being open core, I just expect the project to be run by the company. So I wouldn’t be able to have much influence on the big picture as a contributor. But to fix some small consensual problems, it would probably work.

They do have a roadmap which shows the main features they are working on, although in the past rather than in the future as of today. They seem to do a minor release every month.

Would I contribute again?

If I were to contribute something again to Mattermost core it would probably be something similarly small. I did notice that they have a very nice plugin system (which I find inspiring for OpenRefine too) so if I do more Mattermost development in the future, it would more likely be in that area (for instance if the migration from Slack to Mattermost reveals missing integrations).