My friend Sarah is a talented frontend developer who had been coding professionally for about two years. She was comfortable in her job, building React components and fixing UI bugs, but she had never contributed to open source. She told me she felt like an outsider. The projects she used every day, the testing library, the date picker, the tiny utility that saved her hours, were all built by strangers. She wanted to give back, but the barrier felt enormous. So I offered to mentor her through exactly one contribution: a small, meaningful pull request to an open source project she already used. This is the timeline of that journey, the exact feedback I gave her, and what I learned about guiding someone through the intimidating world of public code.
Week One: Picking the Right Project and the Right Issue
Sarah initially wanted to contribute to a large, popular framework. I gently steered her away. Large projects have complex contribution guides, lengthy review cycles, and a higher chance of a first-timer getting lost or discouraged. We looked at her package.json instead. She found a small date formatting library that she used in a side project. The repository was active but not overwhelming, with a few open issues tagged “good first issue.” We read the contribution guide together. It was clear and welcoming, with a code of conduct and instructions for setting up the local environment. Sarah was still nervous, but the clarity helped.
She picked an issue that asked for a new feature: adding support for ordinal date suffixes, like turning “1” into “1st” and “2” into “2nd.” The issue had been open for a few weeks with no comments. It was small, self-contained, and would not break existing behavior. I told her that a perfect first issue is one where the scope is clear and the impact is visible. She claimed the issue by leaving a polite comment: “I’d like to work on this. This would be my first contribution.” A maintainer replied within a day, welcoming her and offering to review the pull request when ready. Sarah was officially on the hook, and the real work began.
Week Two: The Setup Struggle and the First Mental Block
Sarah cloned the repository and tried to run the tests. They failed. The project required a specific version of Node.js that she did not have installed. She spent an hour fiddling with nvm before asking me for help. I showed her the exact commands, but I also explained why version managers matter and how to read the engines field in package.json. This was a small but important lesson. The contribution had already taught her something about her own toolchain. Once the tests passed, she read the source code for the existing date formatting functions. They were well written but dense with regular expressions. She felt out of her depth. I told her that reading unfamiliar code is a skill, and it feels slow because it is slow. I encouraged her to take notes and draw a small diagram of how the functions connected. She did, and the fog began to lift.
She wrote her first attempt at the ordinal suffix function in a new branch. The logic was correct, but she had not followed the project’s code style. The function used a different variable naming convention, and she had added a comment in a style the project did not use. I reviewed her code before she pushed and pointed these out gently. I told her to read the surrounding code carefully and make her code blend in, as if it had always been there. She adjusted the style and pushed the commit. Then came the moment she had been dreading: opening the pull request.
The Pull Request: Writing a Description That Earns Trust
Sarah drafted the pull request description. Her first version was a single sentence: “Added ordinal suffixes to dates.” I asked her to imagine she was a maintainer with hundreds of notifications. What would she want to see? We looked at examples of good pull requests in the repository. Together, we rewrote the description. She explained what the change did, linked to the issue she was closing, showed a before and after example of the output, and noted that she had run the tests and they passed. She also explicitly asked for feedback on whether the approach was correct and if there were edge cases she might have missed. That last part was my advice: a first-time contributor signals humility by asking for review, not demanding approval.
She opened the pull request on a Tuesday evening. The maintainer responded within six hours. The feedback was positive but included a specific request: could she also handle the case where the input was a string that contained a number, like “Day 1” turning into “Day 1st”? Sarah had not considered that edge case. She felt a flash of embarrassment, but I reminded her that this was exactly what review was for. The maintainer was not criticizing her. They were helping her make the feature complete. She added the handling logic, updated the tests, and pushed a second commit. The maintainer approved the pull request. On Thursday afternoon, just two days after opening it, her code was merged into the main branch. She was officially an open source contributor.
The Aftermath: A Permanent Shift in Identity
The feeling Sarah described was not pride exactly. It was belonging. She had changed a piece of software that real people used, and her name was in the commit log. She told me she felt less like a consumer of open source and more like a participant. The barrier that had seemed so high was actually a series of small, learnable steps. The next week, she spotted a bug in a different library and opened an issue with a clear reproduction. She was already thinking like a maintainer. I did not push her. The momentum was hers.
I also saw changes in her professional work. She started reading more source code when debugging dependencies. She wrote clearer pull request descriptions at her job, explaining context and decisions. She began reviewing her teammates’ code with more empathy, because she now understood what it felt like to receive feedback on a public stage. The open source contribution was not a resume bullet. It was a growth accelerator.
What I Learned About Mentoring a First Timer
Mentoring Sarah taught me several things about how to guide someone into open source. The most important was that choosing the right project matters more than the technical difficulty of the issue. A welcoming, well-documented project with responsive maintainers makes the difference between a positive experience and a demoralizing one. I also learned that the emotional support is as crucial as the technical guidance. Sarah needed reassurance that her confusion was normal, that her code style mistakes were fixable, and that asking for help was not a sign of weakness. I provided that reassurance, and it cost me nothing.
I also realized that I should not do the work for her. There were moments when I was tempted to just type the fix for the version manager or the pull request description. I stopped myself. My job was to point at the path, not walk it. She needed to struggle with the Node.js version and the code style, because that struggle built the understanding that would carry her through future contributions. The hardest part of mentoring is restraint.
What I Would Do Differently Next Time
If I were to mentor someone else through their first contribution, I would make a few adjustments. I would spend more time upfront on reading the project’s existing code and tests. Sarah understood the issue, but she did not fully understand the codebase’s patterns until after I pointed them out. A more deliberate reading exercise at the start would have saved her the style corrections. I would also encourage her to comment on the issue earlier, before writing any code, to ask clarifying questions about the scope. The maintainer later mentioned that a specific edge case was out of scope, and if Sarah had asked first, she could have avoided rework. Finally, I would have celebrated more visibly. When her pull request was merged, I sent her a congratulatory message, but I should have suggested she share the achievement on social media or in a community she belonged to. Visibility reinforces identity, and she had earned it.
The Timeline in Brief
The entire process from claiming the issue to merge took eight days. Day one was finding the repository and reading the guide. Day two was setup and local environment issues. Days three and four were reading the codebase and writing the initial implementation. Day five was the style review with me and the push. Day six was the pull request and initial maintainer feedback. Day seven was the edge case fix. Day eight was the merge. That timeline is typical for a small, well-defined contribution. The actual coding time was maybe three hours. The rest was communication, reading, and waiting. First-timers often underestimate the non-coding work, but that work is the contribution. The code is the final artifact, not the entire process.
Why This Matters for the Open Source Ecosystem
Open source depends on new contributors. The maintainers who reviewed Sarah’s pull request spent maybe twenty minutes total, and in return they gained a feature their users wanted and a potential long-term contributor. But the pipeline is fragile. A single dismissive comment or a confusing setup process could have ended Sarah’s journey. I believe that experienced developers have a responsibility to act as guides, not just gatekeepers. Mentoring a friend through a first pull request is a small act with outsized impact. It grows the pool of people who feel ownership over the tools we all rely on. Sarah now wants to contribute again, and she has the skills and confidence to do so. If every developer mentored just one person through their first contribution, the open source ecosystem would be healthier, more diverse, and more resilient. The pull request timeline was eight days, but the investment will outlast both of us.
