Forem: Ayu Adiati

From Helping Out to Taking Ownership: The Art of Sticking Around

Ayu Adiati — Wed, 08 Apr 2026 13:29:40 +0000

I frequently receive messages from enthusiastic contributors who have completed 2 or 3 high-quality pull requests (PRs) in just 1 month. They’re proactive, their work is top-tier, and they’ve handled feedback like pros. Then comes the question: "Hey, would you consider me to be a maintainer for this project?"

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, @bekahhw — 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.

The Curated, Automated Open Source Portfolio: How It’s Going

Ayu Adiati — Wed, 01 Apr 2026 10:00:00 +0000

A few months ago, I shared a story about building an automated open source portfolio using just my smartphone and an AI assistant while on vacation. My main goal was to stop the "spreadsheet struggle" for myself. However, as I mentioned in that first post, I also wanted to create something others could use to track their own open source progress.

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.

adiati98 / oss-portfolio-template

A template for open source portfolio project by adiati98: https://github.com/adiati98/oss-portfolio

Curated Open Source Portfolio Template

Tip

Live Demo: You can see an example of a finished portfolio generated by this tool here: https://oss-portfolio-template.netlify.app/.

This repository is a template that automatically generates a curated portfolio of your Open Source Software (OSS) contributions. It tracks Pull Requests (PRs), issues, code reviews, co-authored commits, and collaborations, providing a detailed, organized record of your impact in the community.

The content updates automatically via a Node.js script and a GitHub Actions workflow.

🛠️ Quick Start Guide

1. Repository Setup

Choose how you want to start your project:

Option A: Click Use this template at the top of this repository.
Option B: Click Fork to create a linked copy, then clone it to your local machine:
```
git clone https://github.com/adiati98/oss-portfolio-template.git
```

2. Environment Setup

Ensure Node.js is installed and run:

npm ci

3. Update Configuration

Open scripts/config/config.js and and update your GitHub handle.

// scripts/config/config.js
// Change

…

View 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!

Open Source Engagement: What's Working Now?

Ayu Adiati — Wed, 10 Dec 2025 16:25:15 +0000

Recently, I read @bekahhw’s blog post, "When 'Local' Went Global: The Pandemic Era of International Communities." As someone active in many online communities, I found it a bit sad, but I agree with her points and think they apply to open source communities as well.

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!

Beyond Hacktoberfest: Building a True Open Source Journey

Ayu Adiati — Mon, 27 Oct 2025 09:21:19 +0000

Hacktoberfest is almost over. How has your contribution journey been so far? Are you confident about contributing to open source projects, or are you still struggling to find your way? If you're new to open source and still feel overwhelmed, that's completely normal.

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.

Pick a Project You Like: Start by finding an open source project that genuinely interests you.
Explore the Project and Documentation: Spend time exploring the project, its documentation, and contributing guidelines.
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! 🚀

My First Video Tutorials Contribution for Hacktoberfest

Ayu Adiati — Wed, 22 Oct 2025 07:34:19 +0000

If you’ve followed me for a while, you know that I'm a firm believer that everyone has a place in open source, even if you're not technical or lack knowledge in programming.

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.

Giving non-code contributions the recognition they deserve

Ayu Adiati — Wed, 15 Oct 2025 19:18:38 +0000

Let's be honest. When you hear "open source," what's the first thing that pops into your head? For many, it's lines of code, complex algorithms, and late-night debugging sessions. It's easy to think that if you can't write code for a new feature or fix a tricky bug, you don't have a place in the open source world.

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.

Hacktoberfest: Making it Enjoyable for Contributors and Maintainers

Ayu Adiati — Mon, 13 Oct 2025 08:00:00 +0000

Hey everyone! 👋

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 have 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! ✨

How I Built a Curated, Automated Open Source Portfolio

Ayu Adiati — Mon, 06 Oct 2025 08:00:00 +0000

I've been on a continuous journey in open source since 2020. First, as a contributor, and for the last few years, also as a project maintainer. It's a space where I've learned so much and given back what I can.

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:

A light daily update ('0 1 * * *') that triggers the script's incremental sync to keep things fresh.
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!

adiati98 / oss-portfolio

Curated open source portfolio

Curated Open Source Portfolio

This repository serves as a portfolio of my open source contributions. You can check out the Contribution Log to see my work.

Tip

Want to build your own? I created this system to be reusable. If you want to generate a similar portfolio for your own GitHub activity, please use the Curated OSS Portfolio Template for a clean, standard setup.

I created this log to maintain a detailed and organized record of my journey, including Pull Requests (PRs), bug reports, and general collaborations.

The content in this repository updates automatically via a Node.js script and a GitHub Actions workflow.

If you want to learn about the motivation and development process for this project, read my full write-ups:

💡 How It Works

This project uses GitHub Actions as an…

View on GitHub

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!

Goals Check-In: How's Your Progress Flowing?

Ayu Adiati — Wed, 30 Apr 2025 07:00:00 +0000

Remember way back in January? A new year begins with fresh possibilities and an exciting sense of setting big goals. In Virtual Coffee, we kicked off the year with the "New Year, New Goal" challenge: to dream big and set one significant goal for the entire year. Then, we took it step-by-step, breaking it down into smaller, achievable monthly goals.

Well, time flies when you're working towards something awesome! Now that we're moving into May, it's a perfect moment to pause, take a deep breath, and check in on those goals we set earlier in the year.

Our Own Big Goal: A Community Success Story!

Speaking of ambitious goals, we would like to share our story before we begin. We've recently accomplished our own big goal at Virtual Coffee!

To celebrate our 5th anniversary, we set our sights on holding our very first-ever online conference in April. We had three months from welcoming the Call for Proposals (CFPs) to preparing our speakers. But thanks to our amazing team and volunteers' incredible dedication and hard work, and a big thank you to CFE.dev for hosting, the event was a huge success!

Looking Back and Looking Forward: Evaluating Progress

The "Goals Check-In" challenge isn't about judgment or pressure. Instead, it's an opportunity to reflect on your journey so far. Think back to when you set your goal. What was that big goal you set? Have you been making progress on your monthly goals?

We know that the path to achieving any meaningful goal isn't always a smooth journey. Life happens. Unexpected challenges pop up, priorities might shift, and sometimes, what felt right initially might need a little tweaking now.

So, let's ask ourselves some important questions:

What have you accomplished so far? Let's take a moment to celebrate the wins, no matter how small they seem. Did you complete some of your monthly goals? What are you most proud of achieving?
What challenges have you faced? It's okay if things haven't gone exactly as planned. Did you encounter any roadblocks? Were some monthly goals harder to achieve than you initially thought? Understanding these challenges is the first step towards overcoming them.
Do your monthly goals still feel right? As we learn and grow, our perspectives can change. Do your current monthly goals still align with your big goal? Do they feel realistic and motivating? It's perfectly fine if you need to adjust them. Maybe you need to break them down into even smaller steps, or perhaps you've gained momentum and can aim a little higher!

An Invitation to Reflect

This challenge isn't just for those who started with us in January. We believe reflecting on our progress is a valuable practice for everyone, including those who might be inspired to set goals now in May! Whether you set your goal and plans in January or are thinking about setting a goal now, this is a great time for a personal review.

How We Can Support Each Other

Virtual Coffee is all about supporting and lifting each other up. We're here to offer encouragement, share experiences, and provide support in any way we can.

Share your insights: In our Slack (if you're a member) or the comment below, feel free to share your progress, challenges, or any adjustments you're considering. You might be surprised how many others are going through similar experiences, and your insights could be invaluable to them.
Offer encouragement: If you see someone sharing their journey, offer a word of support! A little encouragement can go a long way in keeping motivation high.
Brainstorm solutions together: Don't hesitate to ask for ideas if you're facing a particular challenge. Some people might have resources and suggestions that you need.
Celebrate milestones: Let's celebrate each other's successes, big or small! Celebrating wins helps keep spirits up and keeps the good vibes going.

Final Words

Remember, goals are meant to guide us, not limit us. This check-in is an opportunity to ensure they are still serving that purpose. It's a chance to be kind to ourselves, acknowledge our efforts, learn from our experiences, and make necessary adjustments to keep moving forward.

So, take some time this month to reflect on your goals. What have you learned? What needs to change? And how can we, as a community, help you continue your journey towards success?

We're excited to hear about your progress and support you in reaching your goal! Let's make the rest of the year even more impactful!

If you'd like to know more about Virtual Coffee and are interested in joining our community, you can visit our website and join the waitlist.

Hello, 2025: The One Big Goal

Ayu Adiati — Sun, 26 Jan 2025 18:59:06 +0000

In my last post, I shared my achievements and challenges in 2024. I also mentioned that I will write about my goal for 2025 in another post, which is the one you're reading.

You might want to check out my previous post to understand what I will share here.

Ayu Adiati

Jan 9 '25

Thank You, 2024: The Challenges and Achievements

#devchallenge #newyearchallenge #career

Comments 12

6 min read

Deep Thinking

After a long pause and reflection, I realize I no longer want to pursue a front-end developer job. I shared why I made this decision in my last post, so I won't repeat myself here. But I do have a thought about pivoting from there.

The Virtual Coffee community is running the New Year, New Goal challenge this month. It gives me strong reasons to plan my one big goal and what I should (or could) do to achieve it.

So, I started to reflect on myself, brainstorm, then I came up with these:

What Were My Biggest Challenges

Coding for hours: Don't get me wrong. I still enjoy coding, but coding for hours alone doesn't excite me as much as it used to.
Absorbing concepts: I can't absorb concepts as fast as I used to, and I can't learn late at night anymore. Whenever I can take one step forward, others are already 10x ahead of me.
Job opportunities: Many front-end developer positions, especially in the Netherlands, are seeking candidates at the senior level. My current skills are not even enough to get a junior-level job, and I have already exhausted and lost my confidence.

What Motivates and Keeps Me Excited

Learning: I enjoy learning new technology, especially if I can learn at my own pace.
Knowledge sharing: Writing blog posts has become a satisfying way to express myself. It allows me to organize my thoughts, share what I've learned, and connect with diverse audiences.
Variations: I feel excited when I learn various topics. The dynamic of doing various tasks—changing between learning, researching, coding, and writing—also gives me more energy than coding for the whole day, everyday.
Documentation: I really enjoy working with documentation and making it easier to understand.
Open source: I've always been drawn to the open source world. I love the spirit of collaboration and the opportunity to contribute meaningfully to a project.
Community: I love engaging with the community and helping others, especially those new to the field. The community has kept me here until today.

Setting Up That One Big Goal'

Based on these realizations, I have set an ambitious goal for 2025: to get a job as a Technical Writer or Developer Advocate/Educator focusing on technical writing and/or community.

I have considered being a developer advocate for a long time. One thing that holds me back is public speaking.

In one of the Coffees (casual weekly Zoom meetings at Virtual Coffee) I attended, I remember a member said:

"The best medium for you to learn is the best outlet for you to share knowledge."

The funny thing is that I'm an audio/visual person. So, I learn best from video tutorials. However, I feel much more comfortable writing than talking in front of a camera. If I could shake off my fear, I may try streaming or making video content at one point, but not today. 😅

The Path Forward: My Plans to Achieve My Goal

Deepen My Technical Writing Knowledge

Learning about technical writing: I will search for and do online courses, workshops, and mentorships to improve my technical writing skills.
Reading much more: I will read more technical documentation and articles to better understand effective technical communication.
Learning with others: If I could find (or create) one, I would join a cohort or learning group of aspiring technical writers to learn from each other, receive valuable feedback, and support each other.

Sharpen My Writing Skills

I work a lot with community documentation and basic tutorials. However, I haven't worked much with more complex technical documentation and writing. So, I will actively practice my technical writing skills by:

Creating high-quality content: I will write and publish more technical articles and blog posts, refining my writing style and improving my ability to explain complex concepts clearly.
Contributing to open source projects: I will search for open source projects, contribute to their documentation, and gain real-world experience.

Building My Network

I want to connect with more technical writers through online communities or social media to seek career opportunities and a supportive network.

Final Words

I'm excited about the challenges and opportunities that lie ahead in 2025. This year will be a year of growth, learning, and self-discovery as I embark on my journey to become a technical writer or developer advocate/educator.

I hope this post inspires you to pursue your passions and set one ambitious goal for yourself this year.

If you love technology, writing, and community like I do, let's connect and learn from each other! You can find me on X, LinkedIn, and BlueSky. 😊

This is a submission for the 2025 New Year Writing challenge: Compiling 2025.

Cover photo by Content Pixie on Unsplash

Thank You, 2024: The Challenges and Achievements

Ayu Adiati — Thu, 09 Jan 2025 22:13:16 +0000

The year 2024 was such a roller coaster for me. In one minute, I felt on top of the world, and the next minute, I was running around aimlessly like a headless chicken. It was a year of victories but also the year I stepped back and paused.

Achievements and Happiness

I will start by highlighting my achievements and the little things that have brought me happiness. These moments have given me all the reasons to keep doing what I do and push through.

Becoming a Maintainer Course with OpenSauced

There are plenty of resources for contributing to open-source projects but not maintaining them. So, when Bekah (@bekahhw) offered me the chance to be on the team creating the Becoming a Maintainer Course, I didn't think twice and said yes. Working and collaborating closely with Bekah and Jessica (@codergirl1991) was one of my most valuable experiences! 💖

You can look at the public archived repository below to see how we collaborated to create this course.

open-sauced / maintainer-intro-course

🍕 Becoming a Maintainer with OpenSauced 🍕

The site provides course materials for OpenSauced's Becoming a Maintainer Course.

Welcome to the Becoming a Maintainer Course with OpenSauced! This course is designed to provide you with an introduction to how to become an open source maintainer and guide you through the process of creating your open source project, working with contributors, and more.

Course Overview

The course is divided into chapters, with each covering a different aspect of being an open source maintainer:

Intro: Understanding the Role of an Open Source Maintainer

This chapter introduces the role of maintainers in open source, the benefits and the responsibilities of becoming a maintainer, and the challenges they face.

How to Setup Your Open Source Project

This chapter walks you through the crucial elements necessary for every project to succeed during its initial setup.

How to Handle Open Issues and Pull Requests

In this…

View on GitHub

The excitement didn't stop there. OpenSauced already has an Intro to Open Source Course built on docsify. Having both courses in one place would make more sense. I never worked with docsify and had no idea if it would work. But I researched, played around, and successfully put both courses in the same repository and website! 🎉

feat: add "Becoming a Maintainer" course #174

adiati98 posted on Apr 25, 2024

Description

This PR adds the "Becoming a Maintainer" course with following changes:

Added a becoming-a-maintainer folder in the docs directory.
Moved the course's files from maintainer course repo to the becoming-a-maintainer folder.
Fixed links and adjusted wording to accomodate both courses.
Moved .nojekyll file into the root of docs.
Changed styling for accessibility purpose as shown in the screenshots. Color palettes are following OpenSauced's brand.

Related Tickets & Documents

Closes #169 #171

Mobile & Desktop Screenshots/Recordings

Before

After

Screen Recording

https://github.com/open-sauced/intro/assets/45172775/30bbb77c-a84b-4651-8e74-862cd9df3ef8

Steps to QA

Tier (staff will fill in)

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

[optional] Are there any post-deployment tasks we need to perform?

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

View on GitHub

I can't express how happy and proud I was when we launched it in May 2024! I hope this course can help folks who are or want to be open source maintainers. 😊

Last Cohort of The Collab Lab

Since I finished my cohort in 2021, I have volunteered at The Collab Lab as a Code of Conduct Responder and mentor.

The Collab Lab is a volunteer-driven non-profit organization that helps early-career developers learn the collaboration side of software development. Unfortunately, it closed because of some challenges. The last cohort started in July 2024, when my family and I had planned a long vacation. That meant I couldn't volunteer for the last time, and it broke my heart.

But luck was on my side. When we returned home in August, they still needed a code of conduct responder to handle some teams. I was blessed to get the chance to give back to the community that helped me tremendously for the last time! 🥰

Catching a Pokemon

I've been part of the Virtual Coffee community for almost five years. Virtual Coffee is an international online community of developers at all levels.

After the COVID lockdowns passed, some of us had the opportunity to meet in person at meetups, conferences, or other events. One of our members invented the term "I caught a Pokemon!" when they could meet another member(s) in person.

This year, my family and I went to my hometown, Jakarta, Indonesia, for summer vacation. This was one of my highlights of the year because I haven't been back for 5 years! And I could spend my birthday in my hometown after 11 years of living abroad. Seeing my sister, big family, and friends after so long and speaking entirely in Indonesian after a while boosted my spirit.

Surprisingly, one of my friends I made online (and now becoming one of my dearest friends) happened to be in Jakarta. Yes, I met Victoria (@lo_victoria2666) in person! My first-ever Pokemon caught!🥳

Victoria has been one of my biggest inspirations and motivation in tech, particularly blogging. At this point, I was on the edge of giving up tech, which I will tell you later. Meeting and talking with her over coffee gave me many reasons to stay and push through. I feel very fortunate to know and have her as a good friend! 🥰

First Time Workshops

Public speaking has always been my kryptonite. I've given some talks and been a guest on several podcasts, but I'm still terrified of public speaking. However, with a nudge from the community, I keep trying to leave my comfort zone.

In September, we had the Pretember challenge at Virtual Coffee. For this challenge, Bekah asked me if I wanted to co-run two open-source workshops to prepare our members for Hacktoberfest. One was an Intro to Open Source workshop, and the other was a Becoming an Open Source Maintainer workshop.

At first, I hesitated and needed some time to think. But in a couple of days, I agreed to the offer. Although I felt nervous, I did well. Had I not taken the chance, I would never have done it, and I would never believe I could! 🥰

Challenges

All my achievements didn't come without challenges. This year was an actual roller coaster for me. I'm going to be open and share my true feelings here.

I've been learning coding, blogging, and being involved in tech communities for almost six years. Although I enjoy what I do, I reach the point where I feel exhausted, stagnant, and don't know what else to do, which leads me to want to give up.

I don't have as much energy to learn late at night as I used to, and I can't absorb things as fast as I used to. I started to lose focus and do everything half-heartedly. The tech field is dynamic, and I lose my breath trying to catch up.

The tech job market has been more challenging these past years. Most companies are looking for senior-level and Dutch-speaking developers in the Netherlands, and I don't meet the requirements. I can understand and speak Dutch, but not at a working level, let alone in tech. And obviously, I'm an early career in tech. Receiving rejection letters is not new to me, but I won't lie. It often disappoints me and leaves me feeling defeated.

I did get a handful of interviews through some networks (for which I'm super grateful). However, I mostly fail in technical interviews because my skills "are not there" yet, which makes me believe that my skills will never be there. I would then beat myself up because I let those who referred me to the companies down.

For the last six months, I've been struggling. I know it's not an imposter syndrome anymore. It's more than that. I still love tech and wish to stay in this field, but being a front-end developer is no longer something I want to pursue. I'm too far from what it takes to be a junior developer and just too exhausted to get there. So, I paused and did some deep thinking. From there, I realized some things that motivated me to pivot in 2025.

Final Words

The year 2024 was tough, but I learned so much from it—most importantly, I learned so much more about myself. I'm also blessed and grateful to be part of great communities and have friends who continuously support and motivate me. I can't say thank you enough to all of you for believing in me! 🫶

I have one big goal for next year, which I will discuss in a separate post. Lastly, thank you for all the lessons, year 2024!

This is a submission for the 2025 New Year Writing challenge: Retro’ing and Debugging 2024.

Cover photo credit: Rod Long on Unsplash

Join Virtual Coffee in New Year, New Goal: Setting One Big Goal and Achieving It!

Ayu Adiati — Mon, 30 Dec 2024 18:12:41 +0000

Hey, everyone! It's almost new year! 🎆

The new year is often a time for reflection and new beginnings. We look back on the past year, acknowledging our accomplishments and identifying areas for growth. Then, here comes the question: what is your biggest goal for the year ahead?

This month, we are rolling out the New Year, New Goal challenge at Virtual Coffee. We encourage our members (and you!) to set up one big goal they want to accomplish by this year and break it into small goals to achieve it.

You might ask, "One big goal? But I have several goals that I want to achieve this year." Then, you should keep reading this post to find the answer.

But before we go any further, we want to share something. This challenge is not only for you and our members. We (Virtual Coffee) also have our big goal this year.

To celebrate five years of Virtual Coffee, we will hold Virtual Coffee Community Online Conference for the first time ever, and we're very excited about that!

If you're a Virtual Coffee member and one of your goals is to speak at tech conferences, this is the perfect time to get ready!

Okay. Now, let's get back to our challenge!

Why One Big Goal?

There's nothing wrong with having many goals to achieve in a year. But how many of you actually stick to all of them?

Focusing on one ambitious goal can be more effective in improving your chances of success. This goal could be anything from landing your dream job to becoming a speaker at tech conferences, from mastering a skill to finally launching that side project you've been dreaming of.

Your goal doesn't have to be related to your professional life. It can also be something that you want to achieve in your personal life. Maybe you want to learn a new language, play a musical instrument, travel the world, or get in shape—whatever you want to achieve!

Here are some benefits of focusing on one big goal:

Increasing Focus and Motivation: Concentrating your energy on a single goal reduces your chances of feeling overwhelmed or distracted. This focused effort can significantly increase your motivation and drive.
Boosting Productivity: Focusing on one main goal helps you work more efficiently. It keeps you from spending time on activities that don't help you reach that goal.
Greater Sense of Accomplishment: Achieving one significant goal can provide a powerful sense of accomplishment and increase self-confidence. This success can then fuel your motivation to tackle future challenges.
Discovering Your Hidden Potential: Setting an ambitious goal pushes you beyond your comfort zone. You'll learn new skills, develop strength, and discover hidden talents you never knew you had.
Improving Your Career: Whether you're seeking a promotion, a new job, or the opportunity to start your own company, achieving a well-defined goal can significantly impact your career trajectory.

Choosing Your One Big Goal

When choosing one big goal from several, you can try these:

Brainstorming

You can start by brainstorming a list of potential goals. These could be professional, personal, or a combination of both. For example:

Professional: Finding a new job, learning a new technology (like AI or cloud computing), becoming a speaker at tech conferences.
Personal: Learning a new language, improving your fitness, traveling to a new country.
Combination: Finding a remote job you can do while traveling, learning a new language to get a job abroad.

Prioritization

Once you have a list of potential goals, prioritize them based on their importance to you until you find one that speaks loud to you. You can consider these factors:

Long-Term Vision: Does this goal contribute to your overall vision for your life? Will achieving it impact your long-term happiness and fulfilment? Choosing a goal that excites and fulfils you will boost your motivation and help you overcome challenges.
Personal Growth: Will achieving this goal lead to your personal growth, such as developing new skills, overcoming fears, or building confidence?
Realistic Expectations: Is this goal challenging but achievable within the given timeframe?
Measurable Progress: Can you track your progress towards this goal with clear milestones and metrics? This will help you maintain motivation and identify areas for improvement.
Time Commitment: How much time and energy will this goal require? Do you have the necessary resources (time, finances, etc.) to dedicate?
Support System: Do you have the support of friends, family, or mentors to help you achieve this goal?
Life Stage: Consider your current stage of life (career, family, etc.). Choose a goal that fits with your current responsibilities and commitments.

Breaking Down Your Big Goal

To make your big goal more manageable, break it down into smaller, more achievable goals. This will make your journey less daunting and give you a roadmap for success. How do you break your goals into small ones?

Set SMART goals: Ensure your smaller goals are Specific, Measurable, Achievable, Relevant, and Time-bound. For example, instead of "Learn to code," set a goal like "Complete a beginner-level Python course within the next three months."
Create a timeline: Establish deadlines for each smaller goal to maintain momentum and stay on track.
Track your progress: Regularly monitor your progress and celebrate your accomplishments along the way. This could involve keeping a journal, using a project management tool, or simply reviewing your goals weekly.

Final Words

Let's set one ambitious goal this year and commit to making it a reality! Take time to reflect on your aspirations, choose your one big goal, and break it down into smaller, actionable goals.

Whatever your goal is, you want to remember this:

It's okay to adjust your goals throughout the year as your priorities and circumstances change.
Celebrate your progress along the way, no matter how small.
Don't be afraid to seek guidance and support from others.

Come and share with us your goal for 2025 in the comment below, and let's hold each other accountable!

Lastly, visit our website if you want to know more about our community, and join the waitlist if you want to be a member!