How to Find the Right Issues as a First-Time Open Source Contributor

Sahil SarawagiSahil Sarawagi
7 min read

When you're just getting started with open source, one of the biggest challenges is figuring out how to find your first issue — and later, how to gradually take on more complex ones with confidence.

In this blog, I want to share some tips and techniques that helped me level up — starting from small beginner-friendly issues to contributing to larger parts of the codebase.

Some of these tips are based on my experience with GitLab, but you can apply most of them to other organizations as well. If you follow even a few of these approaches, I’m confident you’ll be able to make some really solid first contributions — just like I did.

But before we jump into how to find issues, here are a few things you should have in place:

  • ✅ Decide what you want to work on — frontend, backend, docs, or something else. Narrowing this down helps a lot.

  • 🧠 Brush up on basic Git — commands like add, commit, branch, merge, fetch, rebase, and amend are ones you'll use often.

  • ⚙️ Set up the dev environment — for GitLab, that’s GDK, and it’s important to have it ready so you can actually test your changes.

If you're curious about how I got started with GitLab and eventually got selected for GSoC, I’ve shared that story in my blog:
👉 My GSoC Journey: From First Contribution to Selection
You might find it helpful before diving into this one.

Ways to Filter Out Issues You Can Actually Work On

One of the things I love about contributing to GitLab is how well-organized their issues are. With the right filters, you can find beginner-friendly issues that match your skillset and are perfect for making your first contribution.

Here are some of the ways I use to find those issues:

🔍 1. Filter by Labels

GitLab uses a powerful labeling system — and it’s your best friend when searching for issues.

Here are some useful labels to look out for:

  • frontend / backend – Filter issues based on the type of work. Choose what matches your interest or skillset.

  • Seeking community contributions – These issues are created specifically for community contributors. A great place to start!

  • quick win – Usually comes with a clear implementation guide. If you're new, this is gold — easy to solve and well-scoped.

  • weight::1 – GitLab uses a weight system to show effort required. Weight 1 = very manageable, ideal for beginners.

  • community-bonus – These issues come with extra bonus points for GitLab Hackathons or contribution programs.

👉 You can filter issues using the label dropdown or directly visit this example:
GitLab Issues Filter Example

⚙️ 2. Resolve Auto-Correctable RuboCop Offenses

If you're contributing to GitLab for the first time, this is a fantastic way to get started!

There’s an issue dedicated to fixing auto-correctable RuboCop offenses. These are minor style or formatting issues in the Ruby codebase, and you can fix them just by running a few commands.

🔗 Issue Link: RuboCop Offenses

Before solving one, I’d recommend reading through the issue and trying to understand:

  • What’s a Merge Request (MR)?

  • What do you need to include in the MR description?

  • What is a GitLab community fork and how does it work?

You'll learn a lot about the contribution workflow — and you’ll end up making your first successful contribution!

⚠️ Note:
Please only pick up one cop violation from the issue so other new contributors also get a chance to learn from it.

🔍 3. Search for the Keyword remove in Issues

This is one of my personal tricks.

In many cases, removing code is simpler than writing new code — less risk, and easier to test. I started searching for issues that had the word "remove" in the title or description, and surprisingly, I found a few easy wins.

These types of issues might ask you to:

  • Remove unused feature flags

  • Remove deprecated method calls

  • Remove a helper no longer in use

It’s a neat way to find low-effort but valuable contributions.

Another helpful area to contribute is around tests — especially RSpec specs.

Here’s why:

  • You’re not changing core functionality, just making tests cleaner or more efficient.

  • You won’t fall into the loop of updating 10 different things just to make one test pass.

So if you see an issue related to simplifying, refactoring, or organizing test files — it’s a great opportunity for beginners to learn and contribute without the stress of breaking core features.

📦 5. Explore Issues in Other GitLab Repositories

Did you know GitLab has more than one repo?

Yes, the main GitLab repo (gitlab-org/gitlab) is huge, but there are many smaller repos that are more approachable for new contributors — like gitlab-com/www-gitlab-com/, gitlab-ui and more.

You can find a list of GitLab repos here and search for open issues using the filters we talked about above.

Smaller repos often mean:

  • Simpler setup

  • Narrower scope

  • Easier issues

🛠️ 6. Open Issues Yourself

This is something most beginners don’t realize:
You don’t always have to wait for someone to create an issue — you can open one too!

If you notice:

  • A typo in the UI

  • A confusing error message

  • A piece of dead code

  • A design/layout glitch

  • Or even a better idea for UX...

Just open a well-written issue explaining the problem. Bonus points if you also propose a fix — or submit an MR for it! 🎯

✅ 7. Look for “Non-blocker” Issues

These are some of the easiest issues to pick up, because they’re not critical and don’t affect functionality.

A non-blocker issue usually refers to:

  • Something that doesn’t break the app

  • Minor improvement that’s nice-to-have

  • Feedback that can be addressed in a future change

These often come up during Merge Request (MR) reviews. For example, a reviewer might comment:

“This is a non-blocker, can be fixed in a follow-up.”

👉 That follow-up is usually tracked as a new issue — and that’s your opportunity!

Here’s an example of such an issue created from MR feedback:

These types of issues are great entry points — so keep an eye out for them in MRs or issue trackers.

📝 8. Improve Documentation (Yes, It Counts!)

A classic — and still a fantastic starting point.

Even fixing a small typo, updating a command, or rewording a confusing sentence in the documentation is a valid and valuable contribution.

  • It helps future developers.

  • It shows your attention to detail.

  • And it teaches you how to create MRs, work with reviews, and go through the GitLab flow.Fix Bug

🐛 9. Try Fixing a Simple Bug

Yes, bugs can sound scary — but not all bugs are complex.

If you can:

  • Reproduce the bug consistently

  • Understand the root cause

  • Suggest or test a fix...

… then you're already halfway there.

Look for issues labeled like:

  • bug

  • type::bug

  • or even just search with the keyword "fix" or "broken"

You might find a small but impactful bug that needs just one or two lines of change — and that’s a perfect beginner MR.

🔚 Conclusion

Starting your open source journey can feel overwhelming, especially when it comes to choosing the right issue. But with the right approach — filtering by labels, focusing on documentation, picking non-blockers, and learning from small wins — you’ll build both confidence and skill.

Remember, the goal isn’t to solve the hardest issue right away. It’s to start, learn the flow, and grow from there.

I hope these tips help you make your first few contributions smoother and more enjoyable. If I could do it, you absolutely can too. Happy contributing! 🚀

P.S. If you’re also applying for GSoC or just getting started with GitLab, my blog on how I got selected might help:
👉 My GSoC Journey: From First Contribution to Selection

Let’s Connect!

If you found this blog helpful or have any questions about GSoC, GitLab, Ruby on Rails, or open source in general — feel free to reach out. I’d love to chat or help however I can!

0
Subscribe to my newsletter

Read articles from Sahil Sarawagi directly inside your inbox. Subscribe to the newsletter, and don't miss out.

GitLabOpen Sourcegsoc#gsoc2025

Written by

Sahil Sarawagi
Sahil Sarawagi