I have loved watching the experimentation and creativity coming from Mastodon app creators. Native apps, web apps. Experimental concepts presented to the community to discuss. I ended up being quite the collector, trying to get my hands on every app coming out.

Some of the apps have public repositories, and that peaked my interest. Just to poke around under the hood as an outsider and see how the different apps tick.

Advice for a new contributor from a new contributor

• Look through the issues. Look through the pull requests. Find out how the community ticks.

• Look for positive and spirited discussions about features and bugs.

• Especially for your first contributions, look for a well documented repo, with clear expectations on your role and how to submit your work.

• Most repositories will have a CONTRIBUTING.md and a README.md guide - read them, study them. Ask questions if needed.

• Some groups may have Discord, Slack, etc. channels. Go say hi and see what’s being discussed.

• When you feel comfortable enough, start looking through the issues lists for items marked “good first issue” or something similar.

• Build the application locally, or read through the documentation on the tools the community is using to develop and test.

This is exactly what I did, and I found a good fit with an issue in Elk, an up and coming PWA (with desktop apps on the way as well!).

Elk has something setup that makes it EXTREMELY easy to make small changes very quickly. I had never heard of StackBlitz CodeFlow, but just by clicking a button in an Issue or Pull Request, I was able to start up a dev environment in a web browser - all set up with an extremely familiar VS Code running, the recommended extensions pre-applied, and quick and easy testing already setup. I. COULD. DO. THIS.

I made my change. And it was working! I submitted a pull request and went to bed.

The morning after

The next morning, I see a reviewer had commented and suggested moving the feature out of the options sub-menu and over to it’s own icon on the main account profile page.

This made me nervous. It was one thing to contribute a little hidden menu item, but I knew from my experience that making visible UI changes on such a utilized screen would pick up lots of attention from the community.

The change was submitted, and this is where my first mistake was made.

I had meant to just reply back with a “Like this?” with my new commit and then have a discussion about it. But I didn’t mark the pull request as a “Draft” nor did I make it clear this is a work in progress. The pull request was approved and moved into the main branch.

It worked fine, but it wasn’t my best work. For a day or two, I fretted about it. I checked in to Discord and GitHub to see if there were any discussions about it. Finally, I decided to submit a follow up issue / pull request with my recommendations for changes. I started working on the updates and soon saw a few other issues and discord discussions popping up with similar concerns (and rightly so).

Cooperation for the win

I started a conversation with someone that was looking to add accessibilty tags to the button. I was looking to add tooltips to the button so it was more apparent what it did. We decided to work together on a solution - complete strangers working civilly on an opensource project.

My partner was seasoned and well versed. I was intimidated. But still wanting to follow through! They were patient, they were kind. I fuddled through some of the technical details of submitting commits and pull requests through StackBlitz. I finally got it right.

We combined our work and had some great discussions about naming conventions. I learned some new things about accessibility. With some other discussion in discord, we decided to change the icon to be more familiar to other apps (a notification bell).

I really want to call out this individual and thank them, but from our conversations I don’t feel they were looking for that kind of attention. Still, it was ensured they knew how thankful I was for the help and kindness (I hope).

In the end, we built something we could both be proud to have completed.

I submitted my pull request. I admit that I refreshed the page more than a few times waiting for it to be approved or commented on in the next few days.

But it made it in! Approved! And yesterday - published in Elk 0.6.0

All this joy and fear for a little bell icon. And I couldn’t be prouder.

Takeaways

Here are the things I learned:

• Use the draft option on PRs to make your current status known

• New things are scary. Do it anyway. You’re going to mess up. Learn from it.

• Kindness and polite words go a long way

• Working with others isn’t always bad

• Open source contributions take a lot of time and we should respect those that give of their own to make nice things for us

• Elk’s repository and software development process should be applauded.

• Contributing is fun and a bit addictive - I’m now on the hunt for a second - perhaps EASIER second go round.