I love the energy, but here’s the candid truth: being a maintainer isn't just about finishing a few impressive tasks. It’s a marathon, not a sprint. If you want to move into a role with more responsibility in open source, you have to do more than drop a few contributions and leave. You have to be the person who sticks around, shows your commitment, and makes a real difference.

The "Sprint" Mentality

Most people start contributing because they want to practice their skills in a real-world environment. They want to strengthen their resumes, hit personal milestones, and have a concrete way to showcase their skills.

That is a great way to start. It feels good to say, "I created a PR to add a new feature!" or "I found a bug that was crucial for the UX (user experience)!" These are fantastic milestones and should be celebrated because they are moving the project forward. But a project doesn't survive on new features alone. It survives because someone is there to keep the lights on. When a contributor drops a massive piece of code and then disappears, they’ve actually just given the maintainers more work to do in the long run.

Maintenance is not about adding more; it’s about how much of the hard work you're willing to share. It's awesome to achieve personal goals, but a project really lives on because of the people who keep helping long after their first contributions.

The "Invisible" Work That Really Matters

The tasks that lead to maintainer or leadership roles are often the ones that don't get you a public mention or another green square on your GitHub profile. I call this the "invisible" work:

• Answering questions: Helping someone on Slack, Discord, or GitHub who’s stuck.

• Onboarding: Being a welcoming presence for a new person making their first contribution.

• Triaging: Sorting through messy bug reports and figuring out which ones are real.

• Reviewing PRs: Checking others' work to make sure it aligns with the project's goals.

This work is what keeps a community alive. If folks feel welcome when contributing and they get help if it's their first time, they are much more likely to stay longer. These are the fruits of those "invisible" contributions.

Not many folks want to do this stuff because it can feel lonely and unrecognized. It feels like you're doing the work, but it doesn't always come with a "good job" or kudos. But this is exactly what the core team looks for when recruiting new maintainers.

My Story: I Just Lingered Longer Than Anyone Else

I didn't reach leadership roles because I created hundreds of issues and PRs. I got there by hanging around long enough to understand the project’s vision, architecture, and problems.

The Virtual Coffee Handbook

I became the Documentation Team Lead at Virtual Coffee because I listened to the community. I noticed people kept asking the same questions. So, I took the initiative to write down the pain points folks encountered and created a community handbook. It answered the common questions for new and existing members. I saw a gap, and I filled it.

The OpenSauced Connection

Because of my work at Virtual Coffee, the founder, Bekah — who was the team lead at OpenSauced at the time — asked me to be a Docs Maintainer there. It wasn't just a random offer. She saw what I was capable of as a lead at Virtual Coffee and knew I could bring that same value to the OpenSauced docs.

The Mautic Path

In 2024, I contributed to Mautic during Hacktoberfest. That whole month, I only made one PR. But I didn't leave when the event ended. I stayed. I took on more issues, but I also started reviewing other people’s PRs and sharing ideas to improve the documentation. I remember spending much more time reviewing others' work and brainstorming than writing my own. Doing this actually helped me see the "big picture." I began to understand how the project was built and where it was headed, which gave me the confidence to suggest better ways to shape the documentation.

Because I kept showing up frequently and didn't contribute sporadically, the team asked me to become the Assistant Team Lead of Education Team in June 2025. Fast forward to January 2026, and I stepped into the role of Education Team Lead.

How You Can Move Toward Maintenance and Leadership

If you want to take on a bigger role in a project, stop jumping from one repo to another. Don't just create a couple of great PRs and expect to be a maintainer. Here’s my advice on how to get noticed:

• Pick one project and stick to it: It’s better to be a "regular" in one community than a stranger in ten.

• Review more, create less: Try to review two PRs for every one you write. It shows you care about the whole project, not just your own stats.

• Be the "friendly face": If you see someone struggling with a setup error, jump in and help. The core team loves people who make the community feel welcoming and help new folks get started.

• Fix the "low-glamor" stuff: Is the README confusing? Is a link directing to an incorrect website? Fixing these small, annoying things is often more helpful than adding a fancy new button.

• Understand the "why": Don't just look at the code. Learn the architecture and where the project is headed. When you understand the vision, your contributions become much more valuable.

• Take the initiative: Don't wait for someone to assign you a task. If you see a pain point — as I did with the handbook — write it down and propose a solution.

• Listen and learn: Every open source community is different. Instead of assuming that all projects have the same workflow and culture, take the time to learn how this one works. It’s the best way to grow from a contributor into a trusted partner.

Final Words

Whether you want to be a maintainer or move into a leadership role, it's all about trust. You build that trust by being there when things aren't "exciting." It’s about being the person who is still around months and years after the big launch.

If you want to take on more ownership, stop looking for the next big milestone to hit and start looking for the next person who needs a hand. That’s how you truly become part of the heart of the project.

Since then, the project has grown so much. I still use AI to build and refine the code, just as I did when I first started. I’ve added more features that capture the "invisible" work of open source. But as I kept building, I realized that to truly help other folks track their journeys, I needed to make a clear distinction between my personal needs and the core features that everyone can use.

This is the story of how the portfolio evolved, the new features I’ve added, and how I finally turned it into a template for everyone.

Moving Beyond the Basics

In my first post, I shared how I automated the tracking of my daily tasks — merged PRs, issues, and PR reviews. That system was a great "log," but a list of links only tells part of the story. Since then, I’ve shifted my focus from simply recording work to visualizing impact. I wanted to turn a list of links into a clearer picture of my work and make the tool adaptable for anyone's journey.

The Value of Helping Others: Co-authored PRs

One of the biggest updates was the addition of Co-authored PRs. Collaboration often happens through the tools we use every day, but it also happens in different ways depending on the situation.

As a maintainer, I frequently leave "code suggestions" on a contributor's PR. When they accept and commit those suggestions, GitHub credits both of us for that code. Sometimes, if a PR is nearly ready but needs a final push, I assist by committing locally to help them reach the finish line.

Before, my portfolio wouldn't show this specific kind of help. Now, the script is smart enough to find these co-authored commits. To ensure the most accurate report possible, I implemented a critical refactoring so that a single PR can now exist in multiple categories simultaneously — like being both reviewed and co-authored — without any data conflict. Giving direct, usable code feedback is a major part of being a maintainer, and now it’s finally visible.

Making Data Scannable with Charts

While a list of links is useful, it’s hard to see the "big picture" quickly. To solve this, I added bar charts. Now, you can see exactly what percentage of your work goes into code, how much is spent reviewing, and how much is dedicated to general collaboration. It turns a wall of text into a clear picture of your impact.

Finding Your "Persona"

I wanted to add personality to the data, so I built the Collaboration Profile. The script analyzes your contribution data and gives you a "Persona Title." For example, if you do a lot of reviews and give code suggestions, the system might call you a Community Mentor. If you focus on finding bugs and planning features, you might be called a Project Architect. It’s a simple way to show your unique style as a contributor.

A Professional Website with Your Own Branding

I also built an HTML version that you can host as a static website. To give you the freedom to make the portfolio truly yours, I made it easy to customize. By changing a few simple color codes in the settings, you can align the website — including the backgrounds, buttons, and even the browser icon — with your own personal brand.

The Realization: Personal vs. Universal

As I built these features, I started adding features specific to my own journey, like my leadership roles in the Mautic and Virtual Coffee communities and my articles on dev.to and freeCodeCamp.

I soon realized that not everyone has the same path. Someone who's starting their first contributions doesn't need a "Leadership" page, and a developer who only wants to code might find an "Articles" section distracting. If I kept my own personal needs in the main project, it would become too complicated for others to use.

I knew from the start that I wanted this tool to be for everyone. To stay true to that goal, I decided to split the project.

Splitting the Path: The Template and the Workshop

1. The Core Template

I created a template of the project for the community. This is the standard 'core' version, featuring all the essential features like automatic tracking, charts, and the persona profile, ready for anyone to use.

I also kept the Markdown version. Not everyone wants to host a static website or manage a deployment. For those users, they can simply point others to the generated Markdown files directly on GitHub.

2. My Personal Workshop

I kept my original open source portfolio repository as my personal workshop. This is where I experiment with features that fit my personal open source journey.

• Articles Page: I built a custom fetcher script that uses an API to automatically pull my latest posts from dev.to. I even added a smart filter to make sure it only displays articles tagged with "open-source" or "github." For platforms like freeCodeCamp, I manually list the articles to ensure everything is sorted perfectly by date.

• Community & Activity: This page shows my leadership roles and community awards. I'm also working on a live Workbench section. Though it's still a work in progress, the goal is to show what I'm working on right now as a maintainer, such as open PRs that still need my review. It helps me stay organized and shows others my current focus.

You can see the final result of the project on my automated portfolio site.

Final Words

I’m really excited to see where the template goes from here. I feel like splitting the project was the right move. It keeps the core tool simple for everyone to use, while giving me a "sandbox" to play with more complex features like my leadership and activity pages.

Ultimately, my goal for both versions is the same: to make the invisible work of open source visible. Whether you decide to try the template or fork my personal version, I hope these tools help you showcase the amazing work you’re doing.

What’s one part of your workflow that you wish were automated? Let’s chat in the comments!

I work closely with several open source projects, and I’ve noticed a clear drop in regular engagement. Not long ago, online communities were very active. Folks had the bandwidth for constant virtual chats, discussions, and jumping into tasks. Now that most of them are busier offline, many regular contributors aren’t around as much. With fewer long-term contributors, it’s become harder to maintain projects.

So, I’ve been wondering, why are contributors fading away, and what strategies can we use to keep contributors coming back for the long run?

I’d like to hear from both contributors and maintainers. Please join the discussion and share your thoughts. Together, we can learn from each other, gather ideas, and make open source projects more welcoming for everyone.

For Contributors

What Makes You Stay (or Leave)?

Contributing to an open source project takes time and effort. As a maintainer, I’m always curious about what motivates people to join a project. As a fellow contributor, I understand there must be a good reason!

If you contribute regularly, what motivates you the most?

• Is it because you love the product and use it daily?

• Is it the community itself—the friendly atmosphere and the supportive people?

• Is it a purely technical challenge you enjoy solving?

• Or perhaps it's about career growth and building a recognized portfolio?

On the other hand, many people contribute once or twice and then stop. If you wanted to keep contributing but didn't, what made you stop?

How's Your Onboarding Experience?

Think back to the first time you contributed to a project. It might feel intimidating, right? The "Good First Issue" label helps, but a great onboarding experience can help newcomers feel less intimidated and more confident.

I’d like to hear about your experiences. If you’re comfortable, feel free to mention the projects too:

• Can you share a story about a great onboarding process? Maybe someone quickly helped you set up your environment, or the documentation was so clear you didn’t need to ask any questions.

• What about a poor experience? Did you spend hours struggling, only to give up? Did you feel maintainers ignored your questions?

• In your opinion, what is one thing projects could change to make onboarding easier for newcomers?

For Maintainers

Efforts in Retention and Recognition

If you’re a project maintainer, you’re the backbone of the community, and I know you have a lot to handle. As a maintainer myself, I’m interested in how you keep contributors engaged.

• What practical efforts do you find most successful in retaining contributors?

• I believe recognition matters. How do you show appreciation or give rewards? Do you post a public note on social media, send a sticker, feature someone on your project website, or host a virtual celebration?

• What approaches have you found most effective for building an onboarding process that not only helps people get started but also encourages them to return?

Final Words

Open source is built on sharing and collaboration. By talking about both our successes and frustrations, we can all get better at working together.

Please share your thoughts in the comments. Let’s help each other build stronger, friendlier, and more engaged open source communities!

I’m looking forward to reading your stories and ideas!

I know the feeling because I was once a new contributor too. When I first started exploring open source, I didn't understand how to find issues, especially the beginner-friendly ones that aligned with my skills. The open source and Git workflows, the jargon like branch, push, pull, etc., and even creating Pull Requests (PRs) felt incredibly intimidating. I also remember it often took me a long time to click the "Create pull request" button because I was so afraid of breaking the whole project.

For a long time, I believed that grabbing an issue, working on it, and creating a PR was the only way to contribute — and the only thing that would be acknowledged. But I’m here to let you know that that's absolutely not the case. What if I told you the key to a meaningful open source journey is not searching for opportunities but creating them?

This post is based on my personal journey, and I want to share insights that can help you find and create your own unique path in open source.

The Excitement of Hacktoberfest (and What Comes After)

As a project maintainer, I’ve seen a clear trend, especially around events like Hacktoberfest. Everyone gets excited and ready to make their first open source contributions. It's always nice to see so many new faces! However, this excitement can sometimes make it harder for true beginners. "Good first issues"—those smaller, easier tasks perfect for new contributors—get picked up very quickly.

It’s important to remember what Hacktoberfest is about: it’s an event to appreciate, give back to, and support open source projects. It's not a competition to grab and work on as many issues as possible to get to the finish line.

I noticed some people submitted PRs for issues that already had an assigned person, as if they were racing to be the first to submit a PR that would get accepted. But honestly, creating a PR for an issue someone else is already working on wastes your valuable time because maintainers will likely reject it to respect contribution ethics and fairness.

The worst part is seeing that big energy fade away immediately after the event ends. I had this experience where I assigned someone an issue. When I checked in, they replied just as the event finished, "You can unassign me. I’ve already completed enough PRs for Hacktoberfest, so you can give this to someone who wants to work on it." This broke my heart. If they had let go of the issue sooner, someone else could have taken it on, and we could have made progress on our project. This behavior ignores the spirit of collaboration and giving back that open source values.

This experience highlights the difference between participating to gain a reward and making a genuine contribution. It shows that intention matters.

Several years ago, I chose to prioritize meaningful contribution. I focused on helping other contributors rather than hitting the challenge's PR count. In that year, I created a handful of beginner's issues and wrote more blog posts around open source. That's why I didn't complete the Hacktoberfest. But the funny thing is, I wasn't disappointed. Instead, I felt great that I could support many new contributors as they navigated open source.

Now, the question for you is this: are you participating just to complete a challenge, or are you looking to really give back and explore open source more? If you choose the latter, you'll discover that the real journey—the valuable experience and growth—happens when you stay around long after the event is over.

No-Code Contributions are Invaluable

If you love to write, design, test, translate, or even enjoy being part of a community, your skills are incredibly important! These "no-code" contributions are just as important as code. They can get you to the door of open source, help you engage with the project, and get you noticed by maintainers and potential employers. They are highly appreciated and show your commitment and engagement to the project.

You can read my previous blog post, "My First Video Tutorials Contribution for Hacktoberfest," if you want to contribute and know more about no-code contributions to open source.

Create Your Own Path by Spotting and Making Opportunities

You might be wondering how you can create your own opportunities in open source. The path may require patience and determination, but it doesn't always have to involve writing complex code.

1. Pick a Project You Like: Start by finding an open source project that genuinely interests you.

2. Explore the Project and Documentation: Spend time exploring the project, its documentation, and contributing guidelines.

3. Spot the Gaps, Create an Issue:

   • Missing Information? As a beginner or a newcomer to the project, you have the advantage of a fresh pair of eyes! If you find any instructions that are unclear or missing from the documentation, that’s a perfect opportunity. Create an issue explaining how it could be improved. You can even ask to be assigned to fix it!

   • Found a Bug or UI Error? Did you notice any issues with the project's functionality or UI? Create an issue describing the error. Be as clear as possible about how to reproduce it. Again, if you think you can fix it, ask to be assigned to it.

   • Have a Feature or Enhancement Idea? Do you have a brilliant idea that could make the project even better? Don’t keep it to yourself! Propose it through an issue. Explain your idea and why you think it would be valuable. If you're confident you can build it, offer to take it on!

The Power of Monitoring

If you spot a problem but don't know how to solve it, that's totally fine—no one expects you to create an issue and solve it yourself. Create the issue anyway! Keeping track of it is a powerful learning experience that contributes to your growth. When a PR is opened to fix the issue you created, study it. Learn from the contributor's approach, code changes, and the conversations.

The biggest payoff often lies in defining the problem, not just writing the solution. Throughout my open source journey, I created more issues than PRs, and now, as a maintainer, I often review far more PRs than I make. Through this, I gained deep insight into the thought process and solutions that contributors used to fix the issues I reported, and more importantly, it showed that my most significant contribution wasn't in the code itself. It's gratifying to focus on contributions like problem definition and review. This approach perfectly aligns with the spirit of open source: collaboration and support.

Stay and Grow in Open Source

Open source is a marathon, not a sprint. The more you stick with a project, the more you’ll learn how it works.

Why Focus is Key

It's tempting to jump from project to project, but sticking to 1 or 2 projects and contributing regularly to them is better than contributing sporadically to many.

Here’s why:

• Deepen Your Expertise and Impact: By focusing on one project, you quickly learn its architecture, codebase, and community standards. This foundational knowledge allows you to move beyond simple beginner fixes and make more meaningful, impactful contributions. You become less likely to introduce bugs and are equipped to tackle important features, transitioning from a simple task-doer to a core part of the project's future.

• Trust and Recognition: Regular, consistent contributions build trust with maintainers and the community. They see you as a reliable, committed member, which opens the door to taking on greater responsibilities within the project.

Finding Long-Term Opportunities

Here are some tips on how to find existing opportunities and build that long-term connection:

• Search for Labeled Issues: You can find existing beginner-friendly issues tagged with labels like good first issue, help wanted, or beginner-friendly. You can also use the GitHub search bar like this: is:issue is:open label:"good first issue" language:javascript (replace javascript with your preferred language).

• Move Beyond "Good First Issues": If you already take a "good first issue" on a project, consider challenging yourself with a more advanced issue the next time. This not only gives beginners opportunities to take on simple tasks, but also lets you improve your skills.

• Connect with the Wider Tech Community: Tech communities are valuable resources. Maintainers and active members often share issues that need attention or information about other open source projects actively seeking new contributors.

• Observe Pain Points in Project Chats: When you join a project's dedicated community chat (Discord, Slack, etc.), observe the recurring questions and pain points that most folks encounter. For example, if multiple people ask the same question about project setup, it's a clear indication to update the documentation—a great chance to contribute!

Sticking with projects I cared about is how I eventually became an open source maintainer myself. The key lesson was that the path forward isn't defined by how quickly you grab issues or how many PRs you create, but by how consistent and engaged you are.

Go deep into the project and build a strong relationship with its community. You might be surprised at the bigger opportunities that come your way, such as:

• Becoming a maintainer yourself, guiding the project's future.

• Landing a job because your contributions and expertise stood out.

• Gaining experience that opens doors to other tech roles.

Final Words

Forget about hunting for the perfect “good first issue” and start where you are! Let your interest guide your early steps, and focus on consistent contributions. Whether you're coding, fixing docs, reporting bugs, offering some feature ideas, or helping out with no-code contributions, your path is yours to build. Every contribution you make—no matter how small—creates a lasting impact.

Happy collaborating, and enjoy the ride ahead! 🚀

Recently, I made no-code contributions to the Mautic project, and in this blog post, I want to share this experience with you.

The Big Picture of Open Source Contributions

Open source projects need all kinds of support. Sure, developers are super important, but there are also plenty of people who pitch in without ever touching any code, and they make a big difference, too.

Think of these roles and their contributions:

• Designers: Creating mockups for website designs, improving user experience (UX) flows, and designing promotional graphics.

• Testers: Running manual tests of the software and providing feedback on functionality.

• Marketers & Communicators: Promoting the project, managing social media accounts, and writing informative blog posts.

• Translators: Providing localized language using dedicated translation platforms.

• Event Organizers: Planning meetups and contributor sprints.

• PR Reviewers & Content Editors: Reviewing incoming PRs, checking grammar, and improving clarity on documentation or blog posts before they are published.

Can you imagine a project without those amazing no-code contributors? They tremendously help a project get recognized, keep things running smoothly, and make everything user-friendly for everyone. Plus, they help bring the whole community together, and that’s what open source is all about—awesome projects with solid community and collaborators!

The good news is that since last year, Hacktoberfest has started to encourage no-code contributions. But there’s still a bit of a problem. The official Hacktoberfest count is based on the total number of merged Pull Requests (PRs). This makes it tough for organizations to give credit for the amazing contributions that happen outside of coding and make sure they count for Hacktoberfest. That's why, although many people have the willingness and skills to contribute in various ways, they tend to focus on finding issues that allow them to create PRs just to get counted for Hacktoberfest.

My First Video Tutorial

I've done some no-code contributions before, but this year I tried something totally new. I created my very first video tutorials for Mautic documentation projects.

These were no-code contributions, and they quickly filled an important gap for our community.

It started during a Hacktoberfest contributor onboarding call at Mautic Community. We didn't have enough time to fully explain one of the essential steps for new contributors, which is to set up a local environment to work with our documentation projects. A few folks were also confused about what a PR actually is and how to create one.

Because of this, we planned to host another live session for these new contributors. The problem was that finding a time that works for everyone has been tough since we're all volunteers juggling different schedules and time zones. Also, if people missed the session or the recording failed, we would have to hold a new session, which would use up more of everyone's time.

That’s when my project manager suggested a great alternative: creating a video tutorial for the local environment setup instead! This way, contributors can check out the video whenever they want. I jumped right in and said I’d make the video.

What people didn't know was that this was a huge challenge for me. 😅

I'm a non-native English speaker and an introvert. Talking in public or in front of a camera is my kryptonite. I'm always anxious about recording my voice and screen. But, as people say, you can only grow when you get out of your comfort zone. Most of all, my top priority is to ensure that the onboarding process is smooth for new contributors. So, I pushed myself.

The Video Making Process

To prepare for Hacktoberfest, I created new contributing guidelines for the repository.

My initial plan was to create a single video: a walkthrough of the contributing guidelines for setting up the local environment. I figured this would be a great way to ensure the guidelines were clear and easy to navigate. If anything seemed unclear during my presentation in the video, I could update the written instructions later. It's also a good reminder for new contributors to read these guidelines before working with the repository, since they have all the info they need. That’s why I didn’t write out a script and just went with the flow.

After about five hours of retakes, editing, and re-recording, I finally finished a complete and clear 11-minute tutorial! It was rewarding to put together a solid, lasting resource for Mautic.

However, since I knew there was also ongoing confusion about creating PRs, I took the initiative to make a second video after finishing the first one. I made another video that walks through the entire process of creating a PR for no-code contributions at Mautic, using my own video tutorial contribution as an example.

The best part of all? These efforts are counted towards Hacktoberfest! 🎉

Mautic's Commitment to Full Inclusion

Since last year, Mautic has taken the initiative to bridge the gap for low- and no-code contributions so they can be recognized alongside code contributions. Mautic believes that all types of contributions should be celebrated and actively supported.

If you're curious about how Mautic recognizes high-value no-code contributions, check out this blog post, "Giving non-code contributions the recognition they deserve".

It explains how Mautic acknowledges these contributions and makes sure they’re counted for Hacktoberfest. It's definitely worth a read if you want to see how your no-code efforts can really make a difference!

Also, feel free to look at Mautic’s low- and no-code project board to find low- and no-code tasks if you’re interested in contributing.

Final Words

My experience proved the value of non-code contributions (again); now it's your turn to experience it too. Every single skill you have is valuable in open source. Now, let’s act on that knowledge.

If you’re a beginner or a non-programmer looking to contribute to open source but lack the confidence, you need to hear this: Open source isn’t just welcoming, it’s actively waiting for you! Find a project you love and ask, "How can my skills in writing, design, testing, or marketing help right now?"

If a project lacks a clear process for accepting no-code contributions, suggest one! Talk to the maintainers. Explain politely that incorporating non-code contributions not only feels nice but also builds a healthier and more diverse community. Feel free to share this post and suggest they check out the Mautic approach as a simple starting point.

Your next contribution is waiting. Together, let's elevate open source in a way code never could.

But I'm here to tell you something that should shift your perspective: Open source is more than just code. It's a vast, vibrant ecosystem built on collaboration, where every skill set has a vital role to play. We need to stop correlating contributions solely with writing programming code.

I'm Ayu, and I currently serve as the Assistant Team Lead for the Education Team at Mautic. I can speak to this from experience: my first contribution to Mautic was a no-code submission in 2024. It's precisely this kind of contribution that drives Mautic’s core belief: bridging the gap for low- and no-code contributors. We want to actively support and encourage all types of contributions that help our projects and our entire community to thrive.

The scope of contribution

When we look at the different ways people can contribute to a project, we can organize them into a comprehensive scope.

At one end is traditional programming, which involves writing complex application logic, fixing bugs, or developing new features. This is the conventional open source contribution most people think of.

The low-code contributions

Documentation may look like a simple task, but it's one of the most critical parts of any project. Good documentation is what makes a project usable, welcoming, and successful.

Fact is, even writing documentation often requires a bit of code. Whether you're writing in Markdown, ReStructured Text, or another markup language, you're using structured syntax. You typically use a code editor to write and format it, and you engage with the project's codebase to submit your changes, usually through a Pull Request (PR). Because of this, we can safely categorize documentation as a low-code contribution. It still utilizes technical tools and syntax, but the focus isn't on application logic.

The crucial no-code contributions

Now let's move to the other end of the scope—the pure no-code contributions. These efforts are crucial for a project's survival and growth, yet they often involve zero lines of programming code.

Contributors can add massive value to our projects in areas like:

• Testing & feedback (PR reviews): Checking for clarity and grammar in documentation, or testing bug fixes and new features, confirming the logic, and providing detailed feedback.

• Design & user experience (UX): Creating mockups, designing social media flyers, or crafting a new website layout in tools like Figma or Canva.

• Education & training materials: Writing blog posts, tutorials, and success stories on our blog and knowledgebase, or making tutorial videos, streaming demos, or recording project updates on a platform like YouTube.

• Community engagement, marketing & translations: Running social media campaigns, managing the project's presence, translating project materials, helping with logistics for community events, or triaging issues.

These are massive, valuable contributions. They keep the project healthy, make it more accessible, grow the user base, and ultimately allow developers to focus on writing code. The open source community, at its best, sees all of these as valid and important contributions to their project or organization.

The challenge of recognition: counting no-code in Hacktoberfest

The challenge arises when organizations, especially during events like Hacktoberfest, try to recognize and quantify these diverse contributions.

Hacktoberfest requires a set number of merged PRs to count toward challenge completion, which works perfectly for traditional programming and low-code contributions. But how do we count those invaluable, vital no-code contributions? How can we ensure that these contributors are recognized and celebrated alongside the coders?

It's a problem we, like many others, set out to solve in Mautic. We wanted a clear, fair, and open way to count contributions that don't result in a traditional code PR.

Mautic's approach to no-code recognition

We established a system using a dedicated low-no-code repository. It's a simple yet effective mechanism for tracking non-code work.

Here’s how it works:

• Work on a deliverable: The contributor does their work using their preferred public tools. It might be a Google Doc for an article, a YouTube channel for a tutorial video, a Figma or Canva link for a design, or a link to the specific feature PR they reviewed or tested. The key is that they must have a publicly accessible "media" of their work that they can link to and share.

• Document and submit: They create a new entry in a dedicated Markdown file within our special repository. In this entry, they must list:

  • Their name and GitHub handle

  • Links to their specific contribution (the Google Doc, the YouTube video, the Figma or Canva board, etc.)

  • A brief description of the contribution

• The PR is the count: They then create a PR to be merged. This PR counts towards their Hacktoberfest contribution. It serves as a verifiable acknowledgment of the valuable work completed outside the codebase.

A call for greater appreciation

More open source projects need to find ways to appreciate and formally recognize their no-code contributors. They are the unrecognized champions of the community. Without the writers, designers, testers, marketers, and community organizers, our projects would stagnate, become unusable, or be forgotten.

This system is just one way to do it—and it works for us. It establishes a clear record, gives contributors a measurable result for their efforts, and fits perfectly with the PR-based structure of events like Hacktoberfest.

If you’ve been hesitant to contribute to open source because you don't feel like a "coder," please let go of that idea. Your skills are not only needed but also valuable, and they deserve recognition. Look for projects that actively welcome contributions across the entire scope. Ask how you can help test, write, or design. You might find that your biggest contribution doesn't involve a single line of application code.

The future of open source is inclusive. Let's build it together, with every skill and every contribution appreciated and counted.

Can you believe we’re already almost two weeks into Hacktoberfest? It feels like just yesterday we were preparing for the biggest open source celebration of the year. Hosted by DigitalOcean and Major League Hacking this year, it's a fantastic opportunity for developers of all skill levels—from seasoned pros to complete beginners—to contribute to open source projects. And guess what? This year, the legendary swag (yes, the t-shirt is back!) and the tree-planting initiative are both making a return. How awesome is that?

This year, I’ve been involved as both a maintainer and a contributor. What a ride! I'm currently maintaining 12 repositories across three different organizations. Preparing these repositories for Hacktoberfest is a massive effort, and managing them during the event is a complex task. It’s a fun kind of chaos that really shows the excitement driving the open source community.

Hacktoberfest Eligibility: Navigating Rules and Labels

Before we go further, let's quickly revisit some crucial rules for Hacktoberfest 2025. Think of these as your keys to a smooth and successful experience:

Core Qualification Rules

• Six Quality PRs: You need to submit a minimum of six quality pull requests (PRs) to participating public repositories on GitHub, between October 1 and 30.

• PRs Must Be Merged, Approved, or Labeled: Your PRs must be merged, approved by a maintainer, or have the "hacktoberfest-accepted" label applied to count.

Understanding these guidelines is key to making your contributions count.

The Role of Hacktoberfest Tags and Labels

When you see a repository with the "hacktoberfest" topic tag on its GitHub profile, that means the repo is officially participating! You can find this tag on the repository main page, in the "About" section.

All valid PRs merged into these repositories will automatically count towards your Hacktoberfest goal. So, if a maintainer doesn't add a "hacktoberfest-accepted" label to your merged PR, no need to worry. It's still counted.

The "hacktoberfest-accepted" label becomes particularly important if your approved PR might get merged after October. Alternatively, if a repository you contribute to isn't officially participating, you can politely ask the maintainers to add the label to your accepted PR so it counts toward the event. By applying this label, your contribution remains recognized and counted towards your Hacktoberfest completion, even if the merge occurs later.

A quick note on rewards: Don't forget to sign up on the official Hacktoberfest website to have your PRs counted and track your progress. The swag is only valid for the first 10,000 contributors who successfully complete the challenge.

A Gentle Reminder: Maintainers Are Volunteers Too!

Just like many of you, most open source maintainers are volunteers. We dedicate our free time—often outside of our full-time jobs—to nurturing and improving these projects. This means that sometimes, we might not be as responsive on weekends, or our availability might be limited.

In fact, the situation is often more complex. Some of us, just like me, maintain multiple repositories across several organizations. Moreover, some projects operate with very small maintainer teams. For instance, the teams I work with typically consist of just 2-3 people who are collectively handling a steady stream of PRs across all those repositories.

This complexity is precisely why we need to be wise in creating boundaries. When boundaries are respected, we prevent maintainer burnout and create a healthier environment for everyone to thrive.

Here's a friendly plea from one maintainer to all contributors: please don't continuously ping us to review your PRs, and please don't message us directly (DM) to review your PR or ask questions related to it.

Open source thrives on transparency and community. If you have questions or need to communicate with maintainers, the best place is to leave a comment on your PR or issue. If the project has a dedicated channel on their chat service (like Discord or Slack), you can ask for help and post your questions there. This way, not only can the maintainers track your progress, but the wider community can also follow along and even jump in to help if you get stuck.

However, it's entirely fair to ask for an estimated review time if your PR hasn't been looked at for a while (say, after about four or five days). We usually get notifications when new PRs come in, and we'll review them at our earliest convenience. Rest assured, your hard work won't go unnoticed.

Beyond the Code: Contribution Etiquette and Long-Term Success

1. Focus on Quality, Not Just Quantity (Avoiding Spam)

The biggest challenge maintainers face is a flood of low-effort, non-meaningful contributions, commonly known as spam PRs. These PRs consume maintainers' valuable time to review, tag, and close them, which takes away the event's spirit.

A spam PR often includes:

• Making whitespace edits or adding one non-functional line of code

• Unsolicited submissions that are not aligned with a project's goals

• Low-effort, unreviewed AI-generated contributions

Important rule reminder:

Pull/merge requests that have a label containing the word spam won’t be counted toward Hacktoberfest, and participants with two or more PR/MRs identified as spam will be disqualified. — Hacktoberfest official website.

If you, as a contributor, see a PR that is clearly spam, you can help the maintainers by leaving a comment on the PR indicating that it should be flagged. This community effort makes a huge difference!

2. Keep Your PR Fresh and Dynamic

To make the review and merge process as fast and smooth as possible, follow these steps:

• Regularly Sync: Check your PR every few days. If the default branch of the repository has been updated since you started working, your PR might have conflicts. You need to update your local branch to sync with the latest default branch (often called main) and push those changes. This keeps your contribution easy to merge.

• Respond Promptly: If a maintainer leaves suggestions or requests changes on your PR, address them as soon as you can. Quick responses prevent the PR from stagnating and increase the chance for it to be merged fast.

• Know When to Step Back: If you find the issue that you’re working on is too complex or you don't have time to finish it, that's absolutely fine! Just leave a comment on the PR or issue informing the maintainers that you cannot continue. This allows them to unassign the issue so someone else can pick it up, ensuring the project keeps progressing.

3. Think Long-Term: Contribution is Year-Round

Hacktoberfest is a great starting point, but the open source community needs your support throughout the entire year. The best way to show appreciation to a project and its maintainers is to stick around after October.

Consider this month your training wheels. Once you understand a project, your contributions become even more valuable. Embrace the chance to become a regular, familiar face in the project community. You might even have the opportunity to be one of the project's maintainers!

Making Hacktoberfest Enjoyable for Everyone!

So, how can we make Hacktoberfest a genuinely fun and rewarding experience for both contributors and maintainers?

For Contributors

• Read the Docs: Begin by reviewing the project's README.md and CONTRIBUTING.md files. Every project has different contribution methods. So, understand the project before contributing and follow its specific rules.

• Choose Wisely: Look for issues that match your skills and availability. You can look for tags like "hacktoberfest," "good first issue," or "help wanted" to guide your search.

• Communicate Clearly: Ask questions on the issue thread or PR comments. Describe your changes thoroughly in your PR description.

• Be Patient and Polite: Remember the volunteer nature of maintainers.

• Respect Assignments: Always check if an issue is already assigned to someone else. If a contributor is assigned to an issue, don't create a PR for it. Regardless of how good your code is or how fast your submission is, the maintainer won’t be able to accept it, as this violates community etiquette. Opening a PR for an assigned issue is a waste of your valuable time.

• Keep Your PR Updated: Regularly sync your PR with the default branch and respond to feedback quickly.

For Maintainers

• Clear Guidelines: Ensure your CONTRIBUTING.md is clear and up-to-date. Clear and current guidelines are the most effective way to set up contributors for success and smooth the contribution process. For us, the maintainers, this means significantly less time wasted on reviewing invalid, irrelevant, or non-compliant PRs, allowing us to focus our efforts on merging high-quality contributions.

• Tagging is Key: Use the "hacktoberfest" topic tag for your repository and specific issue labels like "good first issue" or "help wanted". Don't forget to add the "hacktoberfest-accepted" label for approved PRs that might be merged after October.

• Be Welcoming: A friendly tone in comments and reviews makes a huge difference.

• Provide Constructive Feedback: Offer guidance and suggestions rather than just rejecting a PR.

• Set Expectations: If you anticipate delays in reviews, communicate that openly.

• Set Boundaries to Avoid Burnout: It's okay to limit the hours you spend on reviews and stick to your communicated availability. Protecting your time ensures you can sustain your maintenance efforts long after October ends.

• Appreciate Efforts: A simple 'thank you' for any contribution—no matter how small—is a huge motivator.

• Automate Where Possible: Tools like issue and PR templates or saved replies can streamline the process for everyone.

Final Words

Let's keep the spirit of open source alive and make this Hacktoberfest the most enjoyable and productive one yet, for every single person involved. Happy hacking, everyone! ✨

I've always wanted a way to track my progress and showcase my contributions in a portfolio. It's not just about highlighting achievements; it's about monitoring growth, celebrating milestones, and having a resource to share with potential collaborators or employers.

For a long time, this was a manual, frustrating task.

The Spreadsheet Struggle

My first attempts at tracking were old-school. I tried maintaining a Google Sheet, logging every merged Pull Request (PR), every issue I opened, and every valuable code review. Then I tried creating a dedicated GitHub repository, where I'd manually add Markdown files for each contribution.

You can probably guess how this story goes.

Yes, life got in the way, and I became busy with other tasks. Suddenly, a few days turned into a few weeks, and before I knew it, my tracker was totally outdated. It just became stale and useless.

Once, Polywork was a great platform for showcasing my achievements. I highlighted everything, from open source contributions to recognition from notable individuals. However, it eventually came to an end.

Then, I learned about OpenSauced, and long story short, I became one of the documentation maintainers and learned much more about the project. It was an awesome tool that had a cool feature for highlighting open source contributions, making it super easy to link my highlights page on my resume. It was the perfect solution... until it wasn't. When it was deprecated, I was back to square one.

Well, sometimes, inspiration strikes in the least expected places.

Inspiration on the Couch

Yes, that's correct. The moment of inspiration struck me during a family summer vacation, while I was relaxing on the couch.

A few months ago, I took a long summer vacation with my family. I was intentionally tech-free, laptop-less, and simply enjoying the time together.

One day, while I was lounging on the couch and watching a series, the idea of having an open source portfolio suddenly came to mind. I thought, "There must be a way to automate this process." I decided to explore using the GitHub API to build the portfolio.

But here's the thing. I didn't have the deep API knowledge, and I certainly didn't want to ruin my family time by reading documentation for hours. 😅

So, with no laptop and stuck on this idea, I figured I’d try vibe coding a shot—something I’ve never tried before. Honestly, I’m a bit of a skeptic when it comes to AI, and I really struggle with creating effective prompts. I'm aware that if my prompts aren't optimal, I could quickly use up my free credits, and I don't want to wait a long time to get new ones.

But there will always be a first time for everything, and you don't know how it goes unless you try, right?

The Four Filters of Meaningful Open Source Contribution

I want my portfolio to not only track and record all progress, but also reflect personal truths about my contributions. So, I had some ideas about what to include and exclude in the project.

1. The Collaborative Work: Why Only Tracking "Outside" Repos?

I primarily contribute to and maintain projects owned by organizations or other individuals. I don’t currently have my own dedicated open source repository. This means if the tool tracks all my activity, it would include things like personal configuration changes or quick sandbox tests in my own repos, which aren't open source contributions.

My portfolio must be a log of pure collaboration work. Therefore, the script had to be designed from the ground up to only capture activity (PRs, issues) outside of my personal GitHub repositories.

2. The Ethical Line: Why Exclude Private Repositories?

As a contributor or maintainer, I sometimes interact with private repositories belonging to the organizations I work with. Including these activities in a public portfolio feels ethically wrong—I don't own the data, and the work is not (yet) open source.

To keep the portfolio clean, public, and ethically sound, the script needed a strict filter to exclude all contributions made in any organization's private repositories.

3. The Quality Filter: Why Ignore Bots and Routine Merges?

As a maintainer, a significant chunk of my workflow is routine: reviewing and merging PRs from bots like Dependabot. While this is important hygiene work, it doesn't showcase my technical expertise or human interaction.

Therefore, the log needed to reflect genuine human collaboration. The solution had to actively exclude any PRs that were reviewed, merged, or closed if they were authored by a bot account.

4. Capturing the Quiet Value: Why Track "Collaborations"?

Maintainer tasks aren't just about merging PRs. So much value is created by answering questions, providing technical advice, helping a new contributor debug an issue in a comment thread, or explaining why an issue/PR is closed or reopened, without ever needing to hit the "Submit review" button. This is crucial work, but it's often invisible and unrecognized.

My portfolio must capture these kinds of contributions. The script needed a dedicated category to track "Collaborations"—any issue or PR where I commented to discuss or assist, but didn't submit a formal review.

I needed to filter information, set ethical boundaries, and consider efforts as a whole. So, I decided to create a smart, opinionated tracker.

Building an Automation from My Phone

This project, the Curated Open Source Portfolio, was built using my phone.

I pieced together the project using my smartphone, the GitHub mobile app, a mobile browser, and Gemini 2.5 Flash as my AI coding assistant (because it's free!).

It was a tough way to work. The small screen made navigation and testing a nightmare. The only way to test my changes was to push them directly to my main branch and let the GitHub Action workflow run. It was an intense, time-consuming debugging process.

I was relying heavily on the AI to help me structure the Node.js script and compose the necessary GitHub API queries.

Automation Achieved

My Curated Open Source Portfolio is a system that finally puts my contribution tracking on autopilot. What used to take me hours of manual logging and formatting now happens automatically in minutes. It’s built around a Node.js script and a GitHub Actions workflow, adhering strictly to my definition of a valuable, ethical contribution.

Here’s how the project works:

1. A Node.js Script (The Brain)

This script uses the GitHub API to find my activity. The core here is the "Smart Syncing" logic, which dictates how and what data is fetched. To balance efficiency and data integrity, the script is designed to run in two modes:

• A fast incremental update, which fetches only new activity to minimize API calls and keep the system running efficiently.

• A full synchronization, which rebuilds the portfolio from scratch to clear the cache and verify all data since the tracking began.

The script then applies the “Four Filters” and looks for four key contribution types outside of my own repositories:

• Merged PRs: Tracking my PRs that are merged

• Issues: Tracking bug reports or feature requests that I submitted

• Reviewed PRs: Tracking PRs that I formally review

• Collaborations: Tracking my first comments and discussions on someone else's issues/PRs

Achieving all four ethical filters required careful query construction. For instance, to ensure quality and collaboration, the search query for finding reviewed PRs had to use specific exclusion filters. This is one part of the complex query string the script generates:

// Snippet of the search query logic:
`is:pr -author:${GITHUB_USERNAME} ... -user:dependabot -user:github-actions[bot] updated:>=${yearStart}`

The complete solution uses a combination of these search operators and additional JavaScript logic in the script to ensure that no PRs from known bots or contributions within my personal repositories are included in the final report.

2. A GitHub Actions Workflow (The Automation)

This is what makes it hands-free. It has two schedules, effectively minimizing API requests while ensuring total data history:

1. A light daily update ('0 1 * * *') that triggers the script's incremental sync to keep things fresh.

2. A thorough monthly full sync ('1 0 1 * *') that initiates a complete data refresh. It deletes the local cache and data files to rebuild the entire contribution history from the year I started tracking, ensuring accuracy.

The Action runs the script, and then automatically commits the newly generated Markdown reports back to the repository.

The final output is a collection of detailed, quarterly Markdown reports that summarize my work, including statistics and top contributed projects. It's a clean, verifiable, and constantly updated portfolio that I can be proud of.

What I Learned from Vibe Coding My Open Source Portfolio

This "vibe coding" experience taught me some invaluable lessons about building with AI, especially for developers who are still learning certain technologies.

1. You Remain The Architect

The AI can write the code, but you have to be the architect. You still need a fundamental understanding of what you're building. Even though I struggled with the GitHub API syntax, I understood the logic of what I needed: fetch data, process it, and write it to a file. This basic knowledge lets me guide the AI effectively.

2. Be a Critical Thinker, Not a Copy-Paster

This is the biggest takeaway. Don't just accept the code the AI gives you. Get critical. Ask questions. Challenge the approach. I found that I had to push back on Gemini a lot:

• "Can you run me through the code line by line and explain what they do?"

• "That suggested query seems too complex and takes a while to process. Can we simplify it?"

• "This script needs to only look for activity outside of my own repositories. How can we ensure the API query handles that exclusion?"

• "You're suggesting a whole new library, but can we just do this with native Node.js?"

• "Why did you come with this approach and not that approach? What's the difference? What's the impact?"

Sometimes, the AI would change its approach and agree with a simpler solution. Other times, it would persistently suggest things that were far too complicated or unnecessary for my simple application. Always be critical, and still check your facts with a quick Google search.

Vibe coding is an accelerator, especially when you need to bridge a knowledge gap quickly (like crafting the GitHub API query without hours of documentation reading). But the final code quality—its simplicity, efficiency, and effectiveness—is entirely up to the human review and critical challenge.

Your Turn: Getting Started with Automation

If my story resonates with you—the contributor who wants to track their journey but is tired of the manual effort—I encourage you to try out this automation or build one your own!

You can finally focus on what matters most: contributing to open source, not managing a spreadsheet.

Looking Ahead and Staying Critical

While the current system is stable and fully automated, this project is far from finished. I plan to add more features in the future. This ongoing development means one thing is constant: I must continue to manually check and refine the code the AI helped generate. I'll focus on ensuring the logic—from the Node.js implementation to the underlying data requests—remains simple, efficient, and, most importantly, true to the ethical and collaborative principles on which I built this portfolio.

This project is a testament to the power of a good idea, even if it starts on a phone during a vacation. It shows that with modern AI tools, you don't need to be an API expert to build sophisticated solutions. You only need curiosity, critical thinking, and a willingness to try something new.

What are you building with the help of AI to make your life easier as a developer? I'd love to hear your stories!

I did something different this year from previous ones and will share it with you in this post.

First Experience in Content Contribution during Hacktoberfest

I recently learned about the WriteTech Hub community on X. It's a vibrant community that empowers technical writers through its amazing programs. Eager to connect and learn from other technical writers, I joined without hesitation.

As background, since last year, Hacktoberfest has allowed low- or non-code contributions because there are more ways to contribute to open-source projects that don't involve coding skills and technical knowledge.

For Hacktoberfest, WriteTech Hub partnered with some open-source organizations, including Mautic, an open-source marketing automation platform. Mautic offered many non-code issues, including content writing/editing and user documentation. After searching for an issue to work on, I claimed a content writing/editing issue. The assignment was to review and update the content on their website's "Communication Channels" page.

What I Learned From the Contribution

Canva

After asking questions and being sure what to do, I updated the content using Google Docs. Then, I had to create a mockup page. They have a Figma design for the layout and blocks, but I've never worked with Figma.

I've used Canva to create slides and cover images for my blog posts, so I chose Canva for this task. This was my first time using Canva for a mockup page, so I learned something new!

Active Communication and Asking Questions Can Never Go Wrong

Mautic is preparing its new website. As a new contributor, I'm curious about how they want the website to look and what updates they're considering for each page, particularly the one I was working with. So, I asked a question about it.

After I got a response from the maintainer, I dug into their community page on the website to learn more about it. Then, I researched how other communities structured their community pages, asked the maintainer more questions, and offered some ideas before I worked on any changes. I wanted to ensure I was on track with what they wished to have rather than assuming.

As I mentioned, I have never had experience working with Canva to create a mockup page. I asked the maintainer if they have an example of a mockup page in Canva. And they had one! If I hadn't asked, I would have been stuck trying to figure it out for days and lost my opportunity to submit the PR in time for Hacktoberfest.

Open Source is Truly For Everyone

We often hear that open-source contributions are about more than just code. Some contributions that are as important as code are documentation, creating content like blog posts or video tutorials, promoting open-source projects through social media, and many more.

Here's the fact: Most documentation requires a bit of code because most projects' documentation is written in Markdown or other languages. Contributors will work on these files locally on a text editor or directly on GitHub, push the changes, and create a PR. This workflow is quickly recognized in open source because PR creation is involved.

However, we must remember that a project can reach broader audiences and users with the power of strategic marketing and a strong community. This is where other contributions like content creation, promotion, and the rest come in. Some people with expertise in these kinds of contributions are from something other than tech. Although they may not have coding skills, their expertise is extremely valuable and needed. Now, the question is, how can we make open source accessible to them?

Mautic includes non-code contributions during Hacktoberfest. They accommodated the contributions towards total PRs. The way to do that was for contributors to create blog posts or write or update the content or documentation listed on their issues. Once it's done and approved, they can make a PR listing their name and the issue(s) they worked on.

Yes, people without a tech background still need to learn how to create a PR. However, they can make this kind of PR directly on GitHub without any text editor. The key is clear walk-through documentation to guide them in creating a PR.

Appreciation Can Go a Long Way

Contributors volunteer their time and skills to help out open-source projects. I learned along the way that one of many things that makes contributors stay in a community and continue to contribute is acknowledgment and appreciation of their efforts. This can be done through public or community shoutouts, swag giveaways, or other means.

Contributors contribute to an open-source project for many reasons. Some do so to learn new technology, some to apply or sharpen their skills, and some to showcase their contributions to finding a job. Those who are in job hunting can share the link to their issues and PRs on their resume. However, for those contributions that don't have PRs, a written appreciation or anything concrete they can show their future employer would be helpful for their journey.

At Mautic, at the end of the month, they make announcements, tag people who contributed to their projects on Slack, and post them on their blog. They also do giveaways as a form of appreciation.

I plan to contribute more to Mautic because I like the community. I really appreciate their patience and full support during my contribution.

Final Words

Open source is for everyone, regardless of their technical background. Any contribution that helps a project improve and is used by more people is priceless. It's unfair to say that creating issues and PRs are the only metrics to acknowledge a contribution. However, of course, it's a different case for Hacktoberfest. In the future, I hope more and more projects find ways to recognize and appreciate their contributors, especially the non-code ones.

Lastly, thank you to WriteTech Hub for the opportunity to participate in Hacktoberfest with the community. I would also like to express my gratitude to the Mautic community, particularly to Ruth Cheesley, for their support and for making my contribution experience enjoyable.

It is very important to take the time to fill out these forms and templates completely and accurately. This not only makes the process smoother and faster for everyone involved but also ensures that your contribution is given the attention and consideration it deserves, benefiting both you as a contributor and us as maintainers.

So, in this blog post, I will explain why completing them is crucial and how you can do it effectively.

What are Issue Forms and PR Templates, and Why are They Important?

Issue forms and PR templates are structured questions or guidelines you encounter when creating a new issue or PR in a repository. They serve as a roadmap, guiding you through filling in information and ensuring all details reviewers need are provided.

These forms and templates are essential for several reasons:

1. Clear Communication: They ensure you provide all the necessary information for reviewers to understand your changes. This reduces back-and-forth communication and prevents misunderstandings.
2. Efficient Review Process: By providing structured information, maintainers can more easily review the contribution and provide feedback. This speeds up the review process, benefiting both contributors and the project.
3. Consistency: Using the same forms and templates for all contributions creates consistency across issues and PRs. This makes searching, sorting, and managing contributions easier, ensuring no missing information.

Filling In the Forms and Templates

When filling in these forms and templates, you should keep these in mind:

• Follow the Instructions: Read them carefully, pay attention to the instructions, and fill in all sections that don't say "optional" or "for the staff or core members to fill." If there are specific instructions, make sure to follow them.

• Be as Detailed as Possible: Provide a short and clear title and detailed description of your changes or proposal. Include specific examples and steps to reproduce issues or explain the reasons behind your PR.

• Don't Delete Anything: Even if you think a section doesn't apply to your contribution, don't delete it. Instead, leave a comment explaining why it's not relevant or provide a brief "N/A" response. If you're unsure what to fill in, you can look at previous issues and PRs. See how other contributors have done that.

Filling In Issue Forms

Various issue forms can be provided in a project for different purposes, such as bug reports and feature requests. Issue forms are easier to navigate and fill out. Instructions in these forms are usually written right below the input label, as shown in the red boxes below, or as a placeholder.

Fill in all input with as detailed information as possible. If you, for example, request a new feature, convince the maintainers why they want to add this feature to the project in the description. If you're reporting a bug, describe the bug in detail, such as what you encountered, the expected behavior, and steps to reproduce the bug. Provide visual aids such as screenshots or screen recordings if the bug is a UI-related problem.

Filling In PR Templates

PR templates are trickier than issues because they are shown and must be filled out in Markdown.

But I have some tips that I hope can help you when filling in PR templates:

• Preview mode: Click the "Preview" tab to see the sections you must fill in before you do so. It will be easier for you to notice them in this mode, but note that you cannot edit in the preview mode.

  

• Headings: Now that you're back in writing mode, pay attention to the headings with # symbols. You need to provide information right under these headings. Don't skip any heading.

• Comments: The instructions on what information you must provide are usually written in the comments under each heading. Read and follow all instructions thoroughly.

Here is an example of a PR template in Markdown at OpenSauced:

## Description

<!-- 
Please do not leave this blank 
This PR [adds/removes/fixes/replaces] the [feature/bug/etc]. 
-->

## Related Tickets & Documents
<!-- 
Please use this format link issue numbers: Fixes #123
https://docs.github.com/en/free-pro-team@latest/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword 
-->

## Mobile & Desktop Screenshots/Recordings

<!-- Visual changes require screenshots -->


## Steps to QA
<!-- 
Please provide some steps for the reviewer to test your change. If you have wrote tests, you can mention that here instead.

1. Click a link
2. Do this thing
3. Validate you see the thing working
-->


## Tier (staff will fill in)

- [ ] Tier 1
- [ ] Tier 2
- [ ] Tier 3
- [ ] Tier 4

## [optional] What gif best describes this PR or how it makes you feel?



<!-- note: PRs with deleted sections will be marked invalid -->

<!--
  For Work In Progress Pull Requests, please use the Draft PR feature,
  see https://github.blog/2019-02-14-introducing-draft-pull-requests/ for further details.

  For a timely review/response, please avoid force-pushing additional
  commits if your PR already received reviews or comments.

  Before submitting a Pull Request, please ensure you've done the following:
  - 📖 Read the Open Sauced Contributing Guide: https://github.com/open-sauced/.github/blob/main/CONTRIBUTING.md.
  - 📖 Read the Open Sauced Code of Conduct: https://github.com/open-sauced/.github/blob/main/CODE_OF_CONDUCT.md.
  - 👷‍♀️ Create small PRs. In most cases, this will be possible.
  - ✅ Provide tests for your changes.
  - 📝 Use descriptive commit messages.
  - 📗 Update any related documentation and include any relevant screenshots.
-->

Here is a mini challenge for you. After looking at the PR template above, try to answer the questions below. You can also share your answers in the comments.

1. How many sections are there in the template that you must fill in?
2. What is the format to link a related issue?
3. An important note is included in this template. If you don't follow it, your PR might not be accepted. What does this note say?

Now, let's continue where we left off. When filling in the PR template, you must ensure you provide the following:

• Short and clear title. Your title needs to describe the change that you make. For example, "fix: broken link to the About page".

• Detailed description. Explain your changes in as much detail as possible. What did you fix? How did you fix it? Did you add a new function or modify a function? Consider using bullet points if there are several changes and link the resources you use to back up your changes. Here is an example:
  

    ## Description
  
    This PR fixes the long repos' names that are partially stacked at the back of another name in the search input of the Explore tab.
  
    The changes made here:
  
    -  Add Tailwind className:
       - [`truncate`](https://tailwindcss.com/docs/text-overflow#truncate) to truncate overflowing text.
       - [`tracking-tighter`](https://tailwindcss.com/docs/letter-spacing) to reduce letter spacing for better space.
       - `inline-block` to the `<span>` .
  
    - Remove Tailwind classNames:
      - `overflow-hidden` as it's [included in the `truncate`](https://tailwindcss.com/docs/text-overflow).
      - `break-all` as we don't want to add line breaks.
  

• Related issue(s): Most open source projects don't receive unsolicited PRs (PRs that are not accompanied by an issue). One reason is to avoid spam PRs that might introduce irrelevant, low-quality, or harmful changes to the project's codebase.

  So, when you create a PR, you want to include the number of the related issue. Add a keyword of "Closes", "Fixes", or "Resolves" in front of the issue number, like "Closes #123". Linking a pull request to an issue will automatically close the issue once the PR gets merged. You can find the issue number right after the issue's title.

  

• Screenshots or screen recordings: If your changes relate to UI improvement, consider adding screenshots or screen recordings to show the before-and-after changes.

Conclusion

Taking the time to fill out issue forms and PR templates thoroughly demonstrates respect for the project and its maintainers. It also ensures that your contributions are well-received, efficiently reviewed, and more likely to be merged. Remember, every project is unique, so always refer to the guidelines and templates the maintainers provide.

If you don't know, May is Maintainer Month. You can show your love and appreciation to open source maintainers in many ways, including completing those forms.

But what if there was a way to tear down those walls and build bridges of understanding instead? That's where the documentation comes in.

In this post, we will explore why clear and comprehensive documentation is the key to a thriving open source community.

What Exactly is Documentation (Docs)?

Open source documentation, often shortened to "docs", is essentially written guides that explain everything you need to know about an open-source project. Think of it as a friendly guide that welcomes newcomers and empowers experienced users. It explains how things work, how to get started, and how to contribute to a project.

And good documentation is like a bridge connecting the code and the people who will use it.

The Three Pillars of Open Source Documentation

Open source projects have three main types of documentation, each serving a specific purpose:

1. Technical Documentation

This is the developers' documentation. It delves into the codebase, explains APIs, and provides instructions for setting up development environments. README and API documentation are examples of technical documentation.

2. Product Documentation

This type of documentation is meant for general users. Think user manuals that guide them through using the project and its features, such as installation guides, tutorials, troubleshooting guides, and FAQs.

3. Guidelines

These are the rules and roadmap for new contributors. Common types of guidelines in an open source project are:

• Contribution Guidelines: They usually explain how to submit code and bug reports and how to participate in the project, such as the contribution process and communication etiquette.
• Style Guides: They mainly guide contributors in maintaining coding and documentation consistency and quality.

Why Does Documentation Matter? Let's Break it Down!

So, why exactly is good documentation so crucial? It benefits everyone involved in the open source ecosystem:

For Users

Clear documentation empowers users to quickly grasp the project's functionality and unlock its full potential. It reduces frustration by providing solutions to common problems and guiding users through advanced configurations that they can do independently and efficiently. Overall, it can improve user experience and increase the possibility of your software to attract and gain new users.

For Contributors

Clear documentation attracts new contributors by streamlining collaboration. Everyone can understand the expectations and contribute effectively. With detailed instructions, code reviews become faster, and PRs merge quickly. And that can make contributors happy! Happy contributors are most likely coming back for more contributions. The more contributors a project has, the faster it grows and innovates.

For Maintainers

Comprehensive documentation makes maintaining the project much smoother. It reduces the number of repetitive questions from users and allows maintainers to focus on improving the project.

Good documentation attracts new users and contributors who are excited to explore a project with a welcoming guide, which leads to a sustainable project that thrives in a vibrant community.

Keys to Clear and Accessible Documentation: Reaching a Global Audience

Open source projects are inherently open and global, attracting users and contributors from all corners of the world. To ensure everyone benefits from your documentation, consider these tips:

• Simple and Clear Language: Avoid overly technical jargon and complex sentence structures. You also want to break down complex concepts into bite-sized pieces. Write it like you're explaining things to a friend who's not a developer. Think of people with different language and cultural backgrounds. They should be able to understand the documentation as well.

• Structure and Organization: Your documentation needs to be structured logically for better flow and understanding. Remember to make it easy to navigate, for example, by providing a clear table of contents.

• Visual Aids: When possible, complement text with screenshots, screen recordings, diagrams, and code examples. Visuals can break down complex concepts and make the documentation more engaging for all readers.

• Consistency: A clear and consistent formatting and style throughout the documentation creates a professional and easy-to-navigate experience.

• Multiple Languages: If possible, consider translating your documentation into various languages. This opens the door for a broader audience to contribute and benefit from the project.

• Active Maintenance: Treat your documentation as a living document. Encourage user feedback and keep it up-to-date with the latest project developments.

The Call to Action: Be a Documentation Champion

Whether you're a seasoned developer or just starting your open source journey, you can contribute to making documentation in open source projects accessible and welcoming. Here's what you can do:

Contribute to Existing Projects

Many open source projects rely on community members to improve their documentation. Let's start small by contributing to the existing docs of a project you care about.

Look for contribution opportunities, such as creating issues to report typos, missing steps in instructions, or anything else you can find. You can also search for a documentation-related issue that needs help and make a pull request. Another way is to write tutorials on their docs or as a blog post. Or, if you're proficient in other languages, you can help translate their existing content.

Start Documenting Your Projects

If you have a project, start documenting it. You never know if you will make it open source in the future. But even if you don't, you'll have a well-documented project. Who knows, you can help others understand your project and inspire others to document theirs, too!

Advocate for Clear Documentation

Share your knowledge and help others succeed! To support others in the community, you can create content such as blog posts and tutorial videos about a project, do live streaming, or share valuable resources—like this blog post if you find it informative.

Conclusion

Documentation is the unsung hero that keeps open source projects and its community thriving. Clear and accessible documentation can empower users, attract contributors, and strengthen the foundation for maintainers. By investing in documentation, we build bridges of understanding, opening doors to a world of collaboration and limitless possibilities.

Remember, contributing to open source projects is not always about code. Sometimes, the most powerful tool is a well-written explanation! So, let's unlock the full potential of open source, together, one well-written document at a time!

Author note: I recently gave a lightning talk about the same topic in the Virtual Coffee community. If you prefer a video over a blog post, feel free to check it out!

Maintainers are the backbone of any open source project. They review code, merge pull requests, triage issues, and keep the project moving forward. Just like contributors, maintainers also come and go. They may have other commitments outside the project or experience burnout due to the role's demands.

When I joined a maintainers team, we all started doing what we thought best. However, without a clear standard or guidelines, it quickly became chaotic. We each had our way of doing things, and there was little consistency in handling tasks.

This lack of standardization made it confusing for new maintainers like me. I often felt unsure of the "right" way to do things and had to rely on asking my team for guidance, which wasn't always efficient. It made me wonder, "Why don't we have clear guidelines for maintainers, just like we do for contributors?" From there, these maintainer guidelines were born.

Based on this experience, I will share with you the importance of having maintainers' guidelines and how to create one in this article.

From Confusion to Clarity: Why Onboarding Guidelines Matter

Maintainer onboarding guidelines are crucial for several reasons.

• Clear role and responsibilities: Onboarding guidelines provide a clear understanding of the role and its responsibilities. Each project is unique, and maintainers need to know what is expected of them specifically within that project.
• Standardization and Consistency: Guidelines ensure consistency in handling tasks. Without them, each maintainer may have their own way of doing things, leading to confusion and inefficiency. Standardized processes make it easier for maintainers to collaborate and ensure the project runs smoothly.
• Knowledge Transfer: Onboarding documentation serves as a valuable resource for future maintainers. It captures the collective knowledge of the existing team, ensuring a smooth transition even when members move on. This continuity is crucial for the long-term health of the project.
• Reduces Burnout: Clear onboarding processes can help prevent maintainer burnout. They prevent new maintainers from feeling overwhelmed and reduce the need for constant hand-holding from existing members, leading to a more fulfilling and sustainable experience.

Documenting the Journey: From Pain Points to Guidelines

Every project is different, and understanding the challenges in your project will help you create tailored guidelines.

You can start by acknowledging the pain points you've experienced or witnessed within the project. Here are some examples:

• When should we close a PR?
• What method should we use to merge PRs?
• If changes in a PR are requested and the contributor has resolved them, can we dismiss the review and merge it without waiting for approval from the person who requested the changes?
• How long do we keep stale PRs open before closing them?
• What criteria do we use to reject an issue?
• May a contributor take multiple issues at the same time? If so, how many?
• How do we handle code reviews and merge conflicts?
• What are the communication protocols within the team and with contributors? Are there any preferred communication channels, response times, and expectations for tone and language?

And the list can go on.

Once you have a list of your pain points, discuss them openly with the team. Ask them questions such as what their current pain points are. What processes are working well, and what needs improvement? Brainstorm solutions collaboratively and translate them into actionable guidelines.

By asking these questions and documenting the answers, you can start drafting clear guidelines that address the specific needs of your project and maintainer team.

Beyond Onboarding: A Graceful Offboarding Process

While onboarding is crucial, it's also important to consider the offboarding process for maintainers. This ensures that the transition is smooth and respectful for all involved when a maintainer needs to move on and leave the team.

You can consider the following when drafting your offboarding process:

• Circumstances for letting a maintainer go: Define the criteria for removing a maintainer from the team, such as prolonged inactivity, lack of engagement, or failure to meet the project's code of conduct.
• Inactivity notice: Set a timeframe for inactivity before reaching out to gently remind them of their commitment. If inactivity persists, further action can be taken.
• Retirement process: What happens when a maintainer decides to step down? You might need a procedure for revoking access and ensuring a secure handover of responsibilities.

Collaboration is Key: Building Consensus with the Team

Once you've drafted the guidelines, it's time to seek final input from the team. Share your work, solicit feedback, and discuss potential revisions.

This collaborative approach provides valuable insights from diverse perspectives and ensures everyone feels invested in the process and is on the same page. Open discussions can further strengthen the guidelines and promote a culture of transparency within the project.

It's important to remember that these guidelines are living documents. They should evolve as the project grows and adapts to changing circumstances. You need to regularly review and update them to ensure they remain relevant and helpful.

Final Words

Investing time crafting clear onboarding documentation for maintainers is more than just good practice; it's a strategic move that strengthens your entire project.

By creating a comprehensive onboarding process for maintainers, you are not just welcoming new team members but setting them up for success. New maintainers are welcomed with a clear roadmap, existing maintainers benefit from a standardized workflow, and the project flourishes with a knowledgeable and empowered team.

So, let's give our maintainers the same warm welcome and clear direction that we offer our contributors!

Have you ever experienced the frustration of your PR being rejected or stuck in a never-ending review process? It can be demotivating and time-consuming, especially when you're eager to see your changes integrated into the project.

I want to share my perspective as a maintainer so you understand what it looks like from this side. Rejecting pull requests, especially because of things that can be prevented, has always been heartbreaking. Communicating back and forth with contributors because information is missing in PR forms or because they need to follow the existing guidelines can be frustrating. As a maintainer, I lose my time and productivity and sometimes find myself on the edge of burnout.

But here is the good news: There are secret recipes for getting your pull requests reviewed and merged faster, which also help maintainers save time and avoid burnout. I'll share them with you in this blog post.

The Magic of Issues: Ensure Your PR Has a Companion

Here's the golden rule: Always have an issue accompanying your PR.

Before working on any changes, ensure your PR is related to an issue or create one if none exists. This step is crucial because it provides context and a clear purpose for your PR. Think of an issue as a compass that guides your PR in the right direction. It ensures that your code changes align with the project's needs and helps reviewers understand the "why" behind your work.

Proposing a Feature or Reporting a Bug

Let's say you have a brilliant idea for a new feature or stumbled upon a bug. The first step is to create an issue. Propose your idea, describe the bug, and seek initial feedback from the project maintainers.

Wait for them to triage your issue before making any changes. They will let you know if it's a go or unnecessary for the project. It's always better to have that confirmation to avoid any potential misunderstandings or wasted effort.

Following Requirements for Existing Open Issues

If you're working on an existing open issue, make sure you follow the requirements and instructions provided in the issue. Following and sticking to them increases the chances of your PR being accepted and streamlines the review process.

Remember, just because you have an idea for an improvement outside what is required in the issue doesn't mean it's automatically the right solution. The project maintainers have a broader perspective on the project's vision and roadmap. Discussing your ideas first shows respect for their expertise and ensures your PR is well-received.

Unlocking the Secrets: Reading the Project Documentation

It might seem tempting to jump straight into the code, but taking the time to read the project documentation, such as the README and the contributing guidelines, will save you and the reviewers valuable time and avoid headaches in the long run.

One of the reasons I have rejected PRs is that the contributor didn't follow the contributing guidelines or the instructions to run the project, which caused the project rendering or building not to work correctly.

Project documentation is like a treasure map, guiding you through the project's structure, design decisions, and contribution guidelines. It holds the secrets to understanding the project itself and the do's and don'ts of contributing.

Every project is unique, and contributing to open source requires understanding and respecting the project's specific guidelines. Some projects might have strict coding style guidelines, while others may have particular requirements for commit messages or PR descriptions.

So, before you start coding, invest some time in reading the docs. It's an investment that will pay off in the form of smoother PR reviews and a deeper understanding of the project as a whole.

Branching Out: Creating a New Branch for Changes

Always create a new branch before making any changes. This may seem like an obvious step, but it's worth emphasizing. Working directly on the default branch (usually the main branch) can lead to chaos and version control nightmares, especially in larger projects with multiple contributors.

Imagine working on a painting. You wouldn't want to experiment with new colors directly on the finished piece, would you? Creating a new branch ensures that your changes are isolated from the main codebase until they are ready for merging. It allows you to experiment, make mistakes, and refine your code without affecting others.

When creating your branch, give it a descriptive name that reflects your changes. For example, "fix-login-bug" or "feat/add-submit-button" clearly communicate the scope of your work.

You must know that PRs with changes made directly on the default branch often get rejected. So, always create a new branch as a safe space to work on your changes. It's a simple yet crucial step towards a smoother PR process.

A Peek into the Past: Learning from Merged and Closed PRs

Take some time to browse through previously merged and closed PRs.

Study the merged PRs. See how other contributors have structured their pull requests, the level of detail they provide, and how they respond to feedback. This can be a great way to understand what reviewers look for and ensure your PR is clear and detailed.

Even more importantly, analyze closed PRs. Look for common reasons for rejection, such as missing information, incomplete tests, code that doesn't align with the project's style or vision, etc. By doing so, you can avoid making the same mistakes in your PR.

Fill in the Blanks: Complete the PR Form with Detail

Many projects have a PR template. Don't treat these as "just" formalities; don't remove any part of the template just because you think it is unnecessary or would make your PR look clean.

The PR template guides you in giving all the information the maintainers need to review your PR. You must fill it out thoroughly, clearly describing your changes and the problem you're solving.

Typically, here is what to include:

• Descriptive Title

  Keep it short, informative, and directly related to your changes. For example, "Fix: Broken links on the navbar".

• Detailed Description

  Walk reviewers through your code, highlighting your changes' "what" and "why." Be generous with examples and explanations. Think of it as a user guide for your changes. If your PR contains several changes, as in this example, consider using bullet points or checklists. Bottom line: The PR description should give reviewers an immediate understanding of your changes.

• Testing Steps

  Provide clear instructions on how to test your changes. This helps reviewers verify that your contribution works as intended.

• Visual Aids

  Screenshots or screen recordings can be beneficial in illustrating your changes, especially for user interface modifications. Include before-and-after screenshots or a short demo video showcasing the impact of your work.

• Link to an Issue

  Include a reference to the issue your PR addresses, such as "Fixes #123" or "Closes #456". This will help the reviewer know that there is an issue related to your PR. Linking your PR to the related issue will also automatically close the issue once the PR is merged.

You can write the PR form from scratch with the above details if no template is provided.

Submitting an incomplete or carelessly written PR can lead to back-and-forth communication, delays, or even rejection. Take the time to fill out the form thoroughly, addressing each section with care.

Stay Active: Keep Your Branch Up-to-Date

The review process can take some time. While waiting for your PR to be reviewed and merged, don't forget to keep your branch up-to-date with the main branch.

Periodically update your branch by pulling in the latest changes from the main branch. This way, you can quickly catch any potential conflicts and resolve them before they become a roadblock to your PR's acceptance.

If you need help resolving merge conflicts, read this blog post by @bekahhw.

Final Words

Getting your pull requests reviewed and merged faster is not just about following a set of recipes; it's also about sharpening your communication skills and seizing networking opportunities.

Clear and concise communication is key to a smooth PR process. By effectively communicating your changes and addressing reviewer feedback, you demonstrate your commitment to the project and make the reviewer's job easier.

Additionally, engaging with the project maintainers and the community provides valuable networking opportunities. It shows your enthusiasm and willingness to collaborate and learn, increasing the chances of your PR being accepted and opening doors for future contributions or even job searching.

So, as you apply these secret recipes, remember that they are about more than technical proficiency. They are also about building relationships and effective communication.

Knowing when to delegate tasks and involve external contributors is crucial for empowering contributors, fostering a healthy community, and keeping your sanity intact. However, there are also tasks that only the core team may and can handle.

In this article, I will walk you through prioritizing issues wisely and deciding when to delegate or best handle them in-house.

Prioritizing Issues: A Clear Roadmap to Success

Before deciding to delegate or tackle an issue, you must learn how to prioritize it. With a mountain of issues, effective prioritization is crucial. How do you know what to tackle first?

It would help if you considered these factors to prioritize issues:

• Severity: Critical bugs, security vulnerabilities, and blockers must be addressed first.
• Impact: How many users are affected? Issues impacting a large user base deserve your quick attention.
• Difficulty: Can the issues be resolved quickly, or will they require significant effort? Consider prioritizing these based on the time and resources that you have.
• Alignment with project goals: You want to focus more on issues that contribute to the project's vision rather than nice-to-have ones.
• Community interest: If a feature request has high community engagement, such as active discussions, and receives enough potential support, you might want to consider prioritizing it.

Now, you know how to prioritize issues. Next, we will dive into which issues are best to delegate and which are best for you to work on yourself.

Empowering Your Community: When to Delegate

Most of the time, writing an issue is more challenging and time-consuming than working on it yourself. But if you handle everything alone, you will get burnt out quickly.

Remember, the key to open source is the community. Delegating issues to the contributors can bring fresh perspectives, lighten your workload, and foster a sense of ownership within the community.

Now, the question is: What kind of issues do you better delegate?

• Bug fixes: Clear, reproducible bugs with minimal scope are perfect for contributors to tackle. You need to ensure that these bugs are not affecting the functionality of the current state of your project, even without being fixed immediately. These types of bugs are usually related to UI performance.
• Documentation improvements: Updating documentation, adding tutorials, or fixing typos and grammatical errors can be tackled by anyone with a keen eye and contributors with writing skills.
• Small feature additions: Well-defined, self-contained features are perfect for contributors looking to expand their portfolio. You must ensure these features align with your project's vision and scope.
• Testing: Do you need to test specific functionalities or add test coverage to your project? These tasks, while crucial, can often be delegated.

To manage these issues, you can label them with bug, feature, testing, help wanted, etc., depending on the issue type.

Always remember that contributors volunteer their time to help you maintain and enhance your project. So, when time is sensitive, consider handling them in-house rather than rushing contributors to finish the issue promptly.

Delegating issues is one of the ways to attract new contributors to your project and build your contributor pipeline. Contributors come and go; you want more contributors to stick around and contribute more after their first pull request for the sustainability of your project.

Delegating issues will help contributors understand your project and its codebase better, and it help you offload some of your work and build a vibrant community.

Maintaining the Core: Issues Best Handled In-House

Even though delegation is important in open source, some issues need to be handled immediately and can be complex and too sensitive to be taken by external contributors.

There are three major factors that you need to consider when deciding to handle issues in-house:

1. Time: When a problem needs to be addressed and handled quickly, or you need to ship a feature within a deadline, you want to take this on yourself. It's best to refrain from putting time pressure on contributors.
2. Complexity: The core team has more context about a feature and has a bigger picture about the direction of the production. Consider handling this in-house when you need to work on something complex.
3. Continued communication: Issues that require continued and regular communication between maintainers to update the progress and make prompt decisions in the process, potentially taking place outside GitHub for efficiency, are usually best left to core members.

"In-house" doesn't necessarily mean the tasks can only be tackled by the core team. You might have that one contributor who is a well-known community member because of their work and contributions. They regularly ship quality work, know the codebase and documentation inside out, and are familiar with your project's workflow. You know you can trust these types of contributors with the in-house tasks. However, when time is essential, you want to refrain from giving the task to them and let the core team do that instead.

Here are some types of issues that are best handled in-house:

• Critical bugs: When a bug has affected the functionality of the whole project, you can consider it critical or high priority. This kind of bug can't wait and has to be fixed immediately.
• Architectural decisions: Major changes to the project's core structure or direction require your deep understanding.
• Security vulnerabilities or privacy concerns: This type of issue is sensitive, and protecting user data is your top priority. So, you need to fix these kinds of issues yourself.
• Complex refactoring: Extensive code overhauls often need your experienced perspective and in-depth understanding of the codebase. It requires careful planning and analysis for efficient, maintainable, and scalable code.
• Creating or modifying guidelines: The rules of your project and how to contribute to it are yours to determine. Having more people outside your team to throw ideas can cause you to drift away from your original intention and direction.

Consider labeling these types of issues with core team work, critical or high priority to inform that these will be handled in-house.

Conclusion

Mastering issue management is a game-changer for open source maintainers, but it is also an ongoing process. Adapt your strategies as your project evolves, ask for community feedback, and don't be afraid to experiment to find the best approaches. By doing so, you can transform issue management into a powerful tool for community engagement and project success.

If this is the first time you read my article, I'm Ayu. I'm Indonesian and based in the Netherlands. I'm a technical blogger and a Documentation Team Lead at the Virtual Coffee community. My passion lies in collaboration and documentation (docs). I love to find ways to make documentation accessible to all users, regardless of their skill levels and cultural backgrounds.

To celebrate Maintainer Month, I want to share my journey in open source, from contributing to maintaining open source projects.

Starting with Contributing

As I self-learned to code, I had some experience with GitHub for my personal projects. However, I knew nothing about open source.

My journey in open source started with Hacktoberfest 2019. I heard about this event from X (previously Twitter) and decided to participate. Back then, resources to learn how to contribute to open source were less plentiful than today. So, I had no other option than to learn by reading the projects' README and contributing guidelines on GitHub.

Looking back, I'm grateful for this limitation because it shaped my habit of reading a project's documentation before I started contributing.

I still remember my first-ever PR being closed. The maintainer asked me to pull the latest changes, update my code, resolve merge conflicts, and create a new PR. I didn't know what "pull" the latest changes meant, why I should "update my code," or what "merge conflicts" were. I asked for clarification but never got a response (even until today).

Getting my feet wet in open source was already daunting, and not getting an answer to my question discouraged me completely from contributing.

Pushing Through and Being Consistent

In 2020, I participated again in Hacktoberfest. This time, the experience was different. I participated in the event together with the Virtual Coffee community. I had the whole village to support and mentor me. I learned so much and gained more confidence in contributing to various projects.

After Hacktoberfest, I continued contributing regularly to Virtual Coffee's repositories and began to enjoy collaborating on and contributing to open source.

You might've heard that contributing to open source is more than contributing code or creating PRs. Most of my contributions involve writing blog posts about open source, creating and updating documentation, and creating issues. And I love doing all of these!

I learned that the more I'm involved in particular projects regularly, the more I understand them in deeper level. This helps me spot bugs faster, generate ideas for project enhancement, answer questions, and support new contributors. It also allows me to work closer with maintainers and understand the project's goals and visions, which led me to become a maintainer.

Becoming a Maintainer

After contributing to OpenSauced projects for some time, I was thrilled when Bekah gave me the opportunity to help maintain some of their repositories.

Coming from the contributor side, I didn't know how to maintain a project. One of the repositories that my team maintains is an open source repository for beginners.

In the beginning, I felt overwhelmed catching up with incoming PRs. Not only do I need to review and merge PRs, but as we're receiving contributions from folks new to open source, I also need to explain why I give the feedback and suggest how to address it.

Based on my bitter experience, now that I'm a maintainer, I make sure to give feedback and explanations when reviewing PRs to help out new contributors and beginners.

But along the way, I learned about tools that can help maintainers save time and increase productivity, began to get used to the flow, and learned much more from this role.

The Ups and Downs

Being a maintainer is challenging. I need to wear many hats—a reviewer, a mentor, a communicator, a community nurturer, and many more. Sometimes, I felt frustrated when contributors rushed me to review their PRs or didn't take the time to read and follow the documentation and guidelines.

But at the same time, being a maintainer is very rewarding. Seeing people grow continuously gives me joy. It boosts my energy whenever I encounter contributors who ask questions and are eager to learn. I'm happy whenever someone tells me they appreciate my effort to support them. Communicating and collaborating with contributors also taught me many things that made me a better maintainer.

Achievements

Although I haven't been a maintainer for so long, I'm proud of some of my achievements.

Maintainers Guidelines

At the beginning of my maintainer journey, I often needed clarification about how things worked, such as handling issues and PRs, the time window for getting an issue triage, PR review and merge, and so on. Each of us on the team had our own way of doing things, and I regularly asked my team questions about our procedures, which affected my productivity. Every time I gained new information, I wrote it down in my notes.

Long story short, I proposed creating maintainers' guidelines for our team based on these notes. After some discussions and reaching a consensus, we finally came up with official maintainers' guidelines.

You can read this blog post I wrote a while ago about why onboarding maintainers is as important as onboarding contributors and how to create maintainers guidelines for your open source project.

Becoming a Maintainer Course with OpenSauced

There are many resources on how to contribute to open source, but there aren't many resources on maintaining an open source project.

OpenSauced has an Intro to Open Source course for people who want to learn to contribute to open source projects. When Bekah invited me to join her and Jessica Wilkins in creating a course for people who wish to take the next step in becoming maintainers, I didn't think twice and said yes. I'm very grateful to collaborate closely with two people I look up to in open source and to learn a lot from them during the process.

The Becoming a Maintainer course officially launched today, as I wrote this on May 20th, and we had a live stream to launch it.

I believe this course can help more people, not only future maintainers but also contributors who'd like to know what it takes to be a maintainer.

Final Words

With this Maintainer Month, I invite you to show appreciation to open source maintainers by giving them shoutouts on social media or the comment below, sending them a note of recognition, or simply thanking them in your PRs or GitHub Discussions.

With this opportunity, I want to thank these awesome maintainers and my incredible open source mentors: BekahHW, Dan Ott, and Nick Taylor. I'd also like to thank my Virtual Coffee family for their endless support throughout my open source and tech journey.

🖼️ Credit cover photo: Dino Reichmuth on Unsplash

Thank you for reading! Last, you can find me on Twitter. Let's connect! 😊

I've been an open source contributor for a few years now. And I love and enjoy the open source collaboration culture. As a contributor, I used to wonder what a maintainer does. How can they keep up with issues and pull requests, especially during Hacktoberfest? What took them so long to review and merge my PR? And there were many other thoughts and questions in my mind.

Since last September, I have had the opportunity to be an open source project maintainer. I help maintain some project repositories at Virtual Coffee, OpenSauced, and SheSharp communities. And now, I can see the view from a different perspective.

Although it was not so long ago that I became a maintainer, I learned so much from this journey. And I keep learning to be a better maintainer through my fabulous teams and mentors. I will share what it takes to be a better open source maintainer in this article.

Communication

Most conversations in open source happen asynchronously. It can be through issues or PR comments, GitHub discussions, or chat services like Discord or Slack. Written communication is prone to misunderstanding, especially in international communities. So good communication in open source is the most essential thing to have.

You want contributors to feel welcomed and keep contributing to your projects. So, improving your communication skills, especially in remote environments, is crucial.

To avoid confusion, take time to answer questions and deliver them in short and clear sentences. Sometimes, there are repeating tasks like asking contributors to resolve conflicts or personally thanking them for their contribution. Having a clear and friendly template ready in the "Saved reply" feature on GitHub is one of the time savers.

However, communication is not always with contributors. When you are part of a maintainers team, you must establish good communication, too. Communicate in which direction the project will go, what the team expects from each other, how the team wants to handle and merge a PR, etc., so everyone can be on the same line. When there is no good communication between maintainers, it can affect the contributors and the project itself.

Observation

To be a better maintainer, you need to be observant. Pay attention to what's happening around the project and how you can improve things for contributors and maintainers.

In one of my experiences, my team and I repeatedly gave feedback to resolve merge conflicts on the guestbook repository at OpenSauced. Most of the time, contributors needed to make several attempts until we could merge their PR. Resolving merge conflicts is a daunting task, especially for beginners. Going back and forth to resolve the conflicts would likely discourage them from contributing to any open source project in the future.

We use CLI for this repository. So, besides fixing some things, contributors also have to run a specific command to update a file. And they often miss this particular step, making them go back and forth. I talked to my team about this observation. I also added a section in our README to resolve conflicts in this repository. Since then, we have been able to merge in PRs faster.

Ask Questions

Being a maintainer doesn't mean that you have to know everything. Asking questions or clarifications to contributors or other maintainers is part of being a better maintainer.

I'm part of the community maintainers team at OpenSauced. So I'm more familiar with the community side than the products. I recently helped review a PR for our documentation that is related to the features of one of our products. To give feedback, I had to look at the features closely and test them out. I also asked many questions about the things that still need clarification.

Asking these questions makes me more familiar with our products. And some of those questions ended up enhancing the features.

Set Boundaries

It's fine and even encouraged for maintainers to set boundaries. The earlier, the better. Setting boundaries can prevent you from getting burned out and have balance.

Like contributors, most maintainers volunteer their time to maintain a repository. Sometimes, you have to prioritize your work or personal life before you can respond to a question or review PRs. Tell your team (and contributors) what they can expect from you. For example, if you won't do any maintenance tasks on the weekend or are unavailable during office hours.

Pull Request (PR) Review

Reviewing PRs is not only paying attention to the changes in the PR. But it's also paying attention to the details.

Pull Request (PR) Form

Before you review a PR, look closely at the PR form.

If the project has a PR template, has the contributor completed the form? And if there is no template provided, does it have a description? Is the description clear enough to describe the changes? Does it mention to which issue the PR is referred, and if not, is there any reason the PR isn't related to an issue? When the changes affect UI, are there screenshots or screen recordings to show the difference before and after the changes?

As a maintainer, you want to educate contributors about the importance of providing details in their PR forms. Clear and detailed information can help you a lot in reviewing PRs and benefit contributors in getting their PR reviewed and merged faster.

Test Changes Locally

Have you ever reviewed documentation changes to a README or any Markdown file on GitHub, and the grammar, wordings, and everything looked good, so you merged it in? But afterward, you realized that the format on the page seemed funny. Or you reviewed code changes, and everything looks neat. Then, you tested things live on Netlify Deploy Preview, and everything worked great. But after merging in the PR, it broke the production.

One of the maintainers' biggest tasks is ensuring the changes work as expected. So, you always want to test the changes locally before you merge a PR.

You can use the "Markdown Live Preview" tool to look at the page format of any Markdown files.

For another type of change like code, you want to pull the branch of the PR and test the changes locally to decide if you will merge it in or ask for some more changes to the contributor. If you don't know how to pull a branch to test it locally, read my article "How to fetch a contribution branch to test it locally as an open-source maintainer".

Final Words

Do you have other tips about becoming a better open source maintainer? Share and drop them in the comment below, and let's learn together! 😄

🖼️ Credit cover image: unDraw

Thank you for reading! Last, you can find me on Twitter, Mastodon, and BlueSky. Let's connect! 😊

When you encounter merge conflicts, where do you resolve them? Directly on GitHub or in your code editor? If you use VS Code, do you know that it has a built-in feature called "Merge Editor" that you can use to resolve conflicts?

In this article, I will walk you through how to resolve merge conflicts in VS Code using this feature.

Prerequisite

• You can download and install VS Code on your local machine if you haven't.

• This tutorial assumes that you have updated your local working branch with the latest changes from the main branch of the upstream repository.

  If you need help updating your branch, read the "How to Keep the Branches Up to Date" section of my article on freeCodeCamp.

Enable the Feature

Before using the Merge Editor, you need to ensure that the feature is enabled in your VS Code.

Follow these steps to enable it:

• Click the gear icon "Manage" at the bottom on the sidebar, then click "Settings". Alternatively, press Ctrl + , for the shortcut.

• Type "git merge editor" in the search bar.

• Check the "Open the merge editor for files that are currently under conflict" checkbox under the "Git: Merge Editor".

Resolving the Merge Conflicts with the Merge Editor

After updating your working branch, open the file(s) with conflicts. The conflicted file(s) has an exclamation mark (!) beside the file(s) name, as shown in the image below.

Then, follow these steps to resolve the merge conflicts in the Merge Editor:

Step #1 - Click the "Resolve in Merge Editor" Button

You will see a blue "Resolve in Merge Editor" button at the bottom right.

After clicking the button, you will see the Merge Editor with three parts:

• Left: The incoming changes from the remote main branch.

• Right: Your (current) changes.

• Bottom: The result.

Understanding the Merge Editor

The left (incoming change) and right (current change) parts in the Merge Editor are read-only. And the bottom one (result) is where you can modify the changes.

The conflicted line(s) of code are shown in the yellow box(es) in the Merge Editor. You can see the number of conflicts in the file at the top right (shown in a red circle in the image) of the "Result".

Before resolving the conflicts, the "Result" reflects the base. The base is the state before the changes were made, either at the remote main branch or your branch.

Step #2 - Decide How to Resolve the Conflicts

Now, you need to decide how you want to resolve the conflicts. You can do it manually or by clicking the options:

• Accept Incoming: if you're going to keep the incoming changes.

• Accept Current: if you wish to keep your changes.

• Accept Incoming and Accept Current: if you want to keep both changes.

  Be noted that the order of acceptance matters. Whichever you click first will be on the top.

In some cases, you might as well get these options:

• Accept Combination (Incoming First): if you want to keep both changes but prefer to have the incoming ones at the top first.

• Accept Combination (Current First): if you want to keep both changes but prefer to have your changes come first at the top.

The changes you accept will be reflected in the "Result". You can still remove the incoming and current changes if you need to. You can also modify the changes manually here if necessary.

If you make the changes manually and want to redo resolving the conflicts, you can click "Reset to base".

You can always check the actual file(s) to see the result while resolving the conflicts when you are confused.

If you wish to undo the merge, now is the best time to do it before you complete the merge. You can run the git merge --abort command. This command will abort the merge and return your file to the state before the conflicts.

Step #3 - Complete Merge

After resolving the conflicts, click the blue "Complete Merge" button that you can find at the bottom right.

If you still have conflicts in another file(s), repeat the steps to resolve them.

And that's it! Now, you can commit and push your changes to your remote branch.

Final Words

Whichever ways you are using to resolve the conflicts, you want to always recheck your changes before committing.

You can read my article on freeCodecamp, "How to Keep Branches Up-to-Date and Resolve Merge Conflicts in GitHub and VS Code, " to learn more about keeping branches up-to-date and resolving conflicts on GitHub and VS Code.

🖼️ Credit cover image: unDraw

Thank you for reading! Last, you can find me on X, Mastodon, and BlueSky. Let's connect! 😊

I've once asked myself, "What is a personal brand?" "Do I need to build a personal brand? I'm a developer and not an influencer." "I'm an introvert. How can I put myself out there without being too uncomfortable?"

It took me a while to finally decide to put myself out there. But I'm glad I did.

This article will share ways to build a personal brand as a developer through open source.

What is a Personal Brand?

A personal brand is a widely-recognized impression of someone through their value. It can be their skills, expertise, niche, or even personality. So, it is about how you promote yourself and how you want people to know you.

But does every developer need to build a personal brand?

The short answer is no. You don't need to create a personal brand. But building a personal brand can help you advance your career, find a job, or expand your network. It allows you to show your skills, passions, and personality.

And as a friendly reminder, building a personal brand doesn't mean being an influencer. It's about building your value, something that can make you stand out.

Five Ways to Build a Personal Brand through Open Source

There are many ways to build a personal brand. In this article, I'm particularly focusing on how to build one through open source space.

1. Be a Regular Contributor

Contributing to open source is a great way to learn to collaborate with other developers. What makes it better is that you contribute to real-world projects. And it's good to know that focusing on contributing to one or two projects is better than too many.

Through my regular contributions, I got the opportunity to become a maintainer of some OpenSauced repositories. Contributions are not always about tackling an issue and creating a pull request. It can also be through creating issues to report bugs, helping maintainers triage issues or review pull requests, helping other contributors, etc.

When you dive deep into a project, you will understand the project inside out. You can spot issues and bugs faster, and you will have ideas to help the organization enhance the project. The more you contribute to the project, the more other collaborators, maintainers, and the organization recognize you and your ability. It allows you to expand your network and can lead you to an opportunity to become a maintainer of the project.

You can put your experiences as a contributor (and a maintainer) in your resume and portfolio. And it's also possible that you will cross paths with your future employer by contributing to open source projects.

2. Content Creation

Have you read a project's documentation and need help understanding what's happening? Most of the time, documentation has limited space to explain the projects. Sometimes, it is written in a very technical way. If it's challenging for you to understand, some people may have the same issue as you. Take this as an opportunity to write a blog post or create a video to deliver a broader explanation in a much simpler way.

Hosting or participating in an X space or streaming about open source can also help you build your value in the open source world.

There are various content ideas. Think of helping beginners in open source by teaching the contributing flow with Git and GitHub or GitLab. You can also share your experience as a contributor or a maintainer and what you've learned.

Creating content to help others will build your expertise. People will know you as someone with skills and knowledge in what you do.

So, find a method you're comfortable with and start from there.

3. Community Engagement

I'm part of some tech communities and love documentation. Together with the core team of the Virtual Coffee Community, I actively discuss ideas and contribute to creating and shaping the community documentation. From there, I was trusted to be the Documentation Team Lead.

Last October, I got involved in the SheSharp Community first Hacktoberfest Initiative by helping the open source team prepare the repository documentation before the event started. And that led me to be a maintainer of their open source projects.

When you're part of a tech community, consider being more active there, especially if your community has open source activities. Helping project maintainers review the pull requests or answer questions on GitHub are also good ways to engage with the community.

Engaging with the community and helping them enables you to build your credibility.

Community engagements include:

• reviewing pull requests on GitHub,

• answering questions,

• helping new contributors onboard an open source project,

• welcoming new members and contributors,

• and many more.

4. Highlighting Achievements

You made a pull request that adds a feature to enhance users' experience. Or you raised an issue of a bug that you encountered in an open source project. These wins are worth to be highlighted as your achievements.

Highlighting your achievements can help you showcase your skills and expertise through your contributions.

OpenSauced is a platform that helps engineers to expand their resume through open source contributions. Their mission is to empower open source maintainers and teams and support contributors.

You can create Highlights of your pull requests, issues, and DEV.to blog posts that help enhance open source projects. You can also share your Highlights as your open source portfolio to help you advance your career and boost your resume.

5. Self-Promotion

Self-promotion is not for everyone, but it can be powerful to help you build your brand through your niche. If you're on social media like X, optimize this platform to promote yourself. You can share your knowledge about open source. You can also use it to promote open source projects or as your public journal of your open source activities.

Consistency is Key

Consistency is the key in whatever way(s) you choose to build your brand. However, consistency is different from doing things daily. Here are some examples of consistencies:

• Content publication.

  Have you ever followed someone on YouTube or any other platforms, and you last saw their content a while ago? In the meantime, content from another creator comes to your timeline regularly. And you decide to follow them. Consistency in creating and publishing your content will not only make people stay, but it will also help you to broaden your network.

• The profile picture and social media handle.

  People will recognize you immediately without thinking twice when you have a consistent profile picture and social media handle across platforms (GitHub, socials, blogging platforms, etc.).

• Messaging.

  Create consistent messaging to tell people what you do or to associate a message with you.

  For example, take a look at Swyx. He popularized the #LearnInPublic hashtag on X. And that's what he does. He helps developers learn in public. Another example is Eddie Jaoude. He created a motto, "Collaboration First, Code Second", to socialize open source. He's well-known in the open source world and founded an open source community, EddieHub.

Final Words

Although you don't need to build a personal brand, if you decide to build yours, it can benefit your journey in the long run. It can help you build your value that makes you unique and stand out.

🖼️ Credit cover image: unDraw

Thank you for reading! Last, you can find me on X, Mastodon, and BlueSky. Let's connect! 😊

I'm participating in the #100DaysOfOSS challenge by OpenSauced. Inspired by the #100DaysOfCode challenge, #100DaysOfOSS is a challenge for everyone interested in open source to learn about open source, contribute, or maintain open source projects over 100 days, starting on July 23rd.

This challenge focuses on growth. So it's about more than just contributing code. You can learn about open source by reading or watching tutorials, engaging in the community by sharing information and knowledge, or any other ways you find comfortable and doable. You can read more about how you can participate here.

You can follow my #100DaysOfOSS daily progress in my journal below.

✅ Recap: Day 28-50

I know, I know. I need to improve myself at updating my #100DaysOfOSS journey on my blog. 😅

But I can't believe that it's halfway to the 100th day! 🤩

Learning and Supports

• I attended the "Intro to OSS" workshop by OpenSauced hosted by BekahHW.

• I attended two "Open Source Hour" Twitter spaces hosted by OpenSauced.

• I attended a Twitch stream — Pizza Bake Off — with Brian and John from OpenSauced hosted by Nick Taylor.

• We heard about this VSCode extension — CodeTour — to onboard new contributors on the Twitter space with Jerome Hardaway. So, I tried it out. I think this would be useful when a project has a big codebase.

• I wrote and published a blog post about my #100DaysOfOSS journey: #100DaysOfOSS Recap: Day 15-27.

• I wrote and published an article for beginners in open source: Open Source and Git Glossary.

Supports and Collaboration

Do you know that September is Preptember? It's the time for contributors and maintainers to get ready for Hacktoberfest!

In Virtual Coffee, we annually hold Preptember as our monthly challenge in September. As part of the monthly challenge team, I spent most of my time collaborating with the team to prepare the challenge for our members to get ready for the Hacktoberfest.

I'm excited that this year, we decided to have a repository for our members who are beginners in open source to practice open source. We also use this repo for contributors and maintainers members to list the repositories we can review and recommend for Hacktoberfest.

I was thrilled when this project received the green light from our core team — even though we only had a very short time to work on all things Preptember after we got the approval!

• I had many sync and async discussions with the monthly challenges team to prepare for the Preptember challenge.

• I researched how to prepare an open-source project and created a private repo to propose the additional new format of the challenge to our core team.

• After getting approval, I made a Preptember repository for Virtual Coffee members to practice open source and list VC-verified repositories.

• I posted an announcement for our members in Slack about the new repo for the Preptember challenge.

Contributions

Virtual Coffee

• I created an issue to fix broken links in our monthly challenges pages on the website.

• I prioritized and created a pull request to fix the September and October pages so we can reuse them.

• I created a pull request to change the current challenge and update the content of the Preptember challenge on the website.

• I created an issue and a pull request to add the September newsletter to the website.

OpenSauced

When I attended the "Intro to OSS" workshop, I saw things to improve in the documentation to create a smoother contributing experience for beginners.

• I created an issue to improve the documentation (README) in the guestbook repository.

• I created a pull request for the docs improvement. I got some feedback and am still working on this.

• I assigned myself to an issue for implementing dark mode at the OpenSauced app repository. I plan to work on this collaboratively with Dominic Duffin.

Challenges

• We were behind in rolling the Preptember. I had one sleepless night, but it paid off with great teamwork!

• We are using pnpm at Virtual Coffee. Whenever I run it, it takes me a while to render the localhost, and it sometimes shuts down by itself whenever I fix multiple things. Well, it's a Windows thing. 😅 It's kind of frustrating at times. So whenever I don't have enough time to check my work locally like these times, I make and push my changes blindly. Then, I create a draft PR and let Netlify do its thing. I'll fix and make adjustments when necessary.😆

Wins and Gratitudes

• I took three days off on a weekend from #100DaysOfOSS — even from my computer! — to enjoy time with my family. 🥰

• I attended my first-ever workshop!

• My pull requests for Virtual Coffee got merged:

  • Updated some content in the resources on the website.

  • Fixed broken links and wordings in the website's September and October challenge pages.

  • Changed the current challenge and updated the September challenge page on the website.

Final Words

If you just heard about the #100DaysOfOSS challenge and want to participate, there is still time. You can start now and join us 🙌!

And if you're doing #100DaysOfOSS, how was your experience? Do share it with us in the comment below 😄!

🖼️ Credit cover image: unDraw

Thank you for reading! Last, you can find me on Twitter, Mastodon, and BlueSky. Let's connect! 😊

At the beginning of my open-source journey, I got confused with many terms used around Git and open source.

"It is an OSS project." "In which repo can I see your project on GitHub?" "Have you created an issue and the PR?" "Have you read the README?" "You want to create a branch and not work your changes on the main branch." "LGTM!"

Let alone start contributing; the terms are already intimidating enough for me. Learning from my experience, don't let these terms scare you off if you're new to open source. In this article, I will share some terms in open source and Git — in alphabetical order — that you will often hear when you dip your toes into the open source.

Open Source Glossary

CONTRIBUTING.md

An open-source repository usually will have a file written in Markdown (.md) called CONTRIBUTING.md — some others called this file CONTRIBUTION.md or anything similar. This file is the contribution guide that contains everything you should know when you want to contribute to a project. You must first read this if you wish to contribute to a project. The contributing guide can be included in the README if you don't find this file.

Contributor

A contributor is a person who contributes to a repository by giving ideas and suggestions, reporting bugs, making changes to the code base or other resources in an open-source repository, and any other action that helps with the project enhancement and maintenance.

Documentation (Docs)

When you hear the word "docs", it refers to documentation. It's a guide that serves as an onboarding medium for new contributors and users in an open-source community. It's the place where you can learn more about how to contribute to the repository and information about how you can get started with their project, such as the installation process, the code syntax and examples, and many more.

Fork

Fork is creating a copy of a repository in your GitHub account. This copy is your remote repository.

GitHub

GitHub is a cloud-based service and platform for hosting, sharing, and collaborating on Git repositories. Other similar well-known platforms are GitLab and Bitbucket.

Issues

Issues are a project's development trackkeeper. An issue can contain a bug found, a feature request, a documentation fix suggestion, etc.

Labels

Labels are tags that inform the type or status of issues and pull requests — for example, bug, feature, documentation, triage, help-wanted, good-first-issue, etc.

LGTM

Maybe you've seen a maintainer mention "LGTM" in a comment of a pull request after a review. Some say it's the abbreviation of "Looks Good To Me", and others say it stands for "Let's Get This Merge". But whenever you see this term, your pull request has passed the maintainers' review and is ready to merge.

Maintainer

A maintainer is a person who maintains an open-source repository. They usually review issues and pull requests, assign contributors to issues, make updates to the project by merging pull requests, etc.

Open Source Software (OSS)

Open Source Software (OSS) is software where the source code is freely available and accessible to the public and distributed under a copyright license. Anyone may reuse, modify, and redistribute the software where the limit depends on the license used for the software. Because of its transparent and open nature, open source encourages open collaboration among contributors.

Pull Request (PR)

A Pull Request, commonly called a PR, is a notification about changes pushed to a branch in a remote repository and ready for the merging process.

README

A README is the face of the project. It is a Markdown file (README.md) that contains everything essential about the project. In this file, you will usually find the project description, how to install them, the license, the Code of Conduct, the contribution guide, etc.

Repository (repo)

A repository — commonly called a repo — is a storage to keep the open source project's code files and resources.

Git Glossary

Branch

A branch is an isolated environment for contributors to work on changes such as fixing bugs, developing a feature, etc. This branch is usually known as a "working branch" or any other name besides "default branch".

A default branch is the branch that people see when they visit a repository on GitHub. All changes in other branches are merged here. By convention, this branch is called a main (previously master) branch.

Clone

Clone is creating a copy of a repository in your local environment.

Commit

Whenever we finish with our changes, we must commit them. It means that we must record our changes. That is also why a commit always includes a message as the record. The message makes it easier for us and others to see what changes have been made.

Git

Git is an open-source Distributed Version Control System (DVCS) that tracks all changes we make to a program. We can see the history of the changes through commits and revert them to the previous version if necessary.

Merge

Merge is an act to merge changes from a branch into the main branch.

Origin

When you create or fork a repository and have it as your remote repository on your GitHub account, by convention, it is called the origin repository. It is an alias of your remote repository.

Pull

Pull is an act to get new changes from the remote to the local repository.

Push

Push is an act to move changes from the local to the remote repository.

Upstream

Say you fork a repository. By convention, the original repository you forked is called the upstream repository. Upstream is an alias of the original repository.

Final Words

I hope this article helps you get less confused when you hear these terms. If you want to share more terms in open source and Git, feel free to drop them in the comment below, and let's learn together 😄!

🖼️ Credit cover image: unDraw

Thank you for reading! Last, you can find me on Twitter, Mastodon, and BlueSky. Let's connect! 😊