Tech Leading in Open Source

As part of the Women Who Code Days of Code challenge, the Women Who Code Mobile group developed an ambitious open source project. They wanted to create a task tracking app asa minimal viable product in about a month.

I started seeing some of the first PRs coming through, and I decided that it was an opportunity to develop my PR review skills and to teach myself about Compose Navigation.

The iOS project was already up and running, and the existing leaders thought that it would be useful for Android to have similar beginner tasks to help everyone get familiar with github. I created issues on Android that were similar to the existing iOS ones.

The beginner tasks created a settings screen using Jetpack Compose. To make it accessible to beginners, I added a small gear to the main screen next to the contextual actions that the team had begun to create, I added the Compose Navigation, and I added a single line of text that said “This is the settings screen” so that beginners would know where they were. Then I added TODOs for every element on the screen referencing the issue numbers.

Working with forked repositories

We were working with a forked repo, and I had only worked with a forked repo once or twice before so it took me a little while to figure out how things would work. The github documentation on working with forks is very good.

As I was reviewing everyone’s PRs from their branch to the main repository, I had to add many remote branches to my project.

I did a git remote add local-user-name [email protected]:remote-branch for some of the users adding the most code. Then I did a git fetch local-user-name to fetch their code. Finally, I did a git checkout local-user-name/branch-name to switch to their branches and confirm that they were working.

Now that we are done, I can do a git remote rm local-user-name to remove all the remote branches.

Working together

One of the most important aspects of working on an open source project is learning how to work together. In my past experience with open source, I knew there were a lot of rules, but I didn’t really appreciate why they existed.

Early on, I asked one of the leads on the project if we could have a github template to help people name their PRs after the issues they were working on and give us the information we needed to review them. This helped a lot.

At first, there were a lot of large PRs that overlapped with other PRs. This made reviewing more difficult, and it also made merging more difficult. These best practices for pull requests summarize a lot of great points that have been made elsewhere. It is common to see new or even experienced engineers enter a project and write large pull requests because they do not know how to divide their work into subtasks. Understanding how to break down large tasks into smaller ones is an important engineering skill.

Sometimes, with commenting, I was asking people to do things without them quite understanding what I wanted them to do. Usually, this involved me trying to get people to adopt architectural decisions without me really explaining them well. As we moved on, I tried to include links in my comments to help provide people with context.

Recently, I was introduced to conventional comments that really helps categorize the types of comments on a PR.

Conclusion

Over a month and a half, I worked on an Android project with a number of talented women who were looking to improve their modern Android development skills. As a Women Who Code volunteer, I learned more than I expected, and met some great people from around the world.