This post is written by Helina Ariva, Open Source Engineering Team Lead
This month, both Flutter and Codemagic have an anniversary to celebrate! Flutter 1.0 was released in December 2018 at Flutter Live. At the same event, we launched Codemagic, the community’s favorite CI/CD tool for Flutter. This also marked the beginning of the ongoing partnership between the Flutter team and Nevercode, the company behind Codemagic CI/CD. Did you know that the Nevercode’s Open Source Engineering team is actively contributing to Flutter and several Google open-source repositories? In this blog post, I’ll tell you more about our Open Source Engineering team and the work we do.
How it all started
Flutter is Google’s open-source framework for developing natively compiled multiplatform applications from a single codebase. Its source code lives in a public repository on GitHub. But not only is the source code public — the issues found in Flutter are too.
By the time Flutter reached its first stable release, the project had accumulated a backlog of around 7,000 open issues, of which more than 1,800 were untriaged and unprioritized. Being a small team, the Flutter core contributors were struggling to keep up with the influx of new issues, which increased as Flutter grew in scope and popularity.
Flutter knowledge was scarce in the framework’s early days. However, Nevercode was able to provide the expertise needed as a company that built a product around Flutter. In the second half of 2019, the first engineers from Nevercode started working through the backlog of untriaged issues with the aim of closing invalid or duplicate issues and triaging valid bugs and feature requests to the respective Flutter teams. In a couple of months, the team had triaged all the issues in the backlog. Ensuring that there are no untriaged issues in the repositories we work with remains an important goal for us to this day.
Where we are now
Our work in the open-source sphere has evolved considerably over the past couple of years. In addition to triaging issues for Flutter, we now also triage issues in repositories related to two other Google products — FlutterFire and Google Ads for Flutter. Together with taking on more responsibility, we have also improved our processes to increase efficiency in our work. For example, we have built tooling that helps us to monitor untriaged issues and collect data around our triage activities for easy reporting and tracking of metrics.
In October 2021, we extended the scope of our work to submitting pull requests to fix issues in Flutter. While we had occasionally been doing that as part of our triage work, we started assigning dedicated people to work on fixing issues full time. Our engineers now work closely with others on the core Flutter team to help finish ongoing development projects and address important issues from the backlog. Internally, we now refer to these two separate teams as the triage team and issue-fixing team.
From the top left: Darshan, Taha, Bruno, Daniel, Nabeel, Huy, and Helina
As a result, our Open Source Engineering team is now bigger than when we started. Even though we’re geographically distributed (our team members reside in five different countries in Europe, Asia, and Africa), we work together as a team. Our meetings take place virtually, but we try to come together once or twice a year for a bit of fun and a good time.
Here’s a closer look at what we do.
The triage team: Maintaining issue hygiene
Right on the front line is our triage team. Their job is to assess the validity of new issues and determine the area these issues affect. All the issues the triagers label are passed on to the main contributors for prioritization and fixing. As it happens, not all issues that users report are valid. About one-third of all new issues in flutter/flutter and flutterfire get closed from primary triage every week.
If you’re into numbers and want to know how many issues the primary triage closes and why, check out the weekly issue triage reports that our team publishes.
Feedback from a Flutter team member on the flutter.dev Discord server
A major part of the primary triage team’s job is making valid issues actionable. To do that, they sometimes have to go to great lengths to get OPs to provide all the necessary information, such as the relevant log outputs or steps to reproduce. Triagers often have to come up with the minimal reproducible code sample themselves. Our triage team makes sure that when you submit a bug report in any of the repositories we triage, your issue — however peculiar — will get the due attention.
Reproduction steps for an issue in flutter/flutter
To understand the scope of the issue, team members reproduce the code across multiple devices, platforms, and Flutter channels. This is a job one simply can’t do on a single laptop.
Huy’s triage setup
Besides tackling new issues, there’s a lot more to the work the primary triage team does. We regularly test old issues against newer versions or rework issues related to areas that have undergone major changes. Such work with stale issues is valuable for keeping things up to date in the issue tracker. For example, flutter/flutter — the biggest of the repositories we triage — currently tracks over 11,000 open issues, so closing any that are no longer relevant is crucial to maintaining hygiene in the repository.
Over the years, the Nevercode Open Source team has triaged more than 27,500 issues.
The issue fixers: Landing PRs to fix open issues
Our issue-fixing team, as we call it, closes open Flutter issues by submitting PRs to fix them. During the past year, the team has addressed a wide variety of issues, from critical bug fixes that have been cherry-picked to hotfix releases to deprecations and documentation updates. One of the team members even introduced a new widget!
On average, we merge 15 PRs a month.
Our main focus has been on framework issues. Recently, the team has put a lot of effort into some of the projects on Flutter’s roadmap, such as supporting Material 3. For example, we have helped migrate Slider, TabBar, and PopupMenu to Material 3.
An LGTM review on one of the PRs
If you want to learn more about using Material 3 in your Flutter app, check out this tutorial on migrating a Flutter app to Material 3 by Taha from the issue-fixing team.
Another area we’ve been contributing to is text input, an important but complex user-facing feature. With Flutter allowing developers to target six different platforms, ensuring fidelity across all host OSes is a demanding task. Fixing text input issues often requires working with low-level code in the engine and interacting with platform-specific native code. One example of such high-effort work involving several platforms is issue #115066.
You can get a good overview of what our issue-fixing team is up to by checking out the Nevercode GitHub project.
Together, our triage and issue-fixing work has earned our team the appreciation of other contributors. “The folks from Nevercode have become some of the most regular contributors and appreciated members of the team. They bring with them the added superpower of insight gleaned from their triage work. Through looking into issues, they became experts in their own areas of the framework, and it has been wonderful to see them grow into such incredible contributors,” says Kate Lovett, a Software Engineer on the Flutter team.
Contributing to open source is rewarding
Be it code contributions or assistance with issue triage, every single person on our team takes a lot of pride in what we do. Not only do we enjoy working with Flutter and its ecosystem, we feel good giving back to the community. “I feel I can help people through the issue-triage process. Sometimes issues are solved from my suggestions/workarounds and I receive the OP’s appreciation,” says Huy from the triage team.
There’s not a single dull day in this job, and there’s always something new to learn. I’d like to conclude this post with some words from Daniel (from the triage team): “Open source is about building communities to make our collective lives better. In the time I’ve spent as an open-source engineer, I’ve interacted with some of the smartest people in our industry, and those interactions/experiences are things that I wouldn’t trade for anything.”
I hope this post inspired some of you to get started with open source yourselves. In the next post, I will share some firsthand tips from the team on how to get started with open-source contributions and become good at them.
