Release 0.3 — Part 2

Margaryta Chepiga
Open Source Adventure
4 min readMar 12, 2018

This blog post is a bit different than the others, as well as this part of my third release.

Type of the Release

This time I wanted to share my experience of doing a triage of issues for the Brave browser.

How it was chosen

We have discussed triage in class, as a very important part of contributions in the Open Source projects. I have been doing some from time to time ( every time I am picking a new bug to fix ), so I decided to share my experience. My goal here is to show people that everyone can contribute to an open source project. I have been talking with different people, including my friends, about my contributions to Brave, and I keep hearing that they really want to contribute, but for one reason or another, they can’t. Since my first class at David’s Humphrey class, I realized how awesome Open Source Community is. Unfortunately, not everyone got a chance to have such an amazing professor who would guide and teach them. That is why I want to share what have I learned, my own experience & show that every person can do it, everyone is capable.

Process & Solution

I am not a person who has a lot of experience contributing to the Open Source projects, but for those that I have seen, Brave is the first project where I saw the documentation for Triage Issues. I truly admire that, and I think it’s amazing.

All the documentation & information on how you can contribute to Brave can be found on the Contributing page.

CONTRIBUTING.md

The above basically describes the whole triage process. But there is more at Triage of issues page.

So how can I actually help triage issues?

I went to the issues tab where I was opening almost every issue and checking if the issue:

  • Is still reproducible
  • Steps to reproduce are clear
  • Is a duplicate

Note: According to the Triage of issues page, you could also help with labels, assigning milestones and etc. As it turns out, I don’t have a right permissions to do so, so this blog post won’t have those examples.

And that’s pretty much it. Let’s see some examples:

Example #1:
The following is one of the issues I found the other day:

Issue Page

Descriptions of the issue

So far the issue seems to be okay, why do we need to triage it then? It is 100% reproducible, steps are very clear as well as the problem description. True. However, there is a comment which says that issue is not reproducible on MacOS. I don’t have a MacOS, but this can also be considered as a sign that the issue might not exist anymore.

So let’s take a look at the steps again and try to reproduce:

The issue is still reproducible on Win10. Let’s comment it:

Example #2:

Issue Page

Description:

Actual Result:

Expected Result:

The process of reproducing:

As you can see from the above the issue was not reproducible. I made a comment, and I actually was considering to work on this issue, so I decided to read the description again. When I noticed:

As a result, I edited my comment and made a note to self to pay more attention next time:

Result

As you can see helping with triage of issues doesn’t require a programming knowledge from you. It is one of those things that you can do, to help open source projects without writing a single line of code. Sometimes it is pretty straightforward, sometimes you won’t understand what are you actually suppose to do. It’s all fine. Start with easy things, then with time you will notice that you are making more and more progress.

--

--

Margaryta Chepiga
Open Source Adventure

Software Developer, known as overexcited girl who is passionate about technology