My First Open Source Contribution: A Non-Engineer's Complete Experience Submitting a Documentation PR

A Non-Engineer's First Open Source Contribution

Recently, a Reddit user shared their experience making their first real open source contribution. They're not a software engineer, but they frequently use various technical products and spend a lot of time learning on GitHub. A few days ago, they discovered an interesting project they wanted to use, but while deploying it locally, they were completely stumped by a certain section of the installation instructions.

So they mustered the courage to submit a documentation-related Pull Request (PR), received genuine feedback from the project collaborator, made the requested changes, and ultimately received thanks before their changes were merged into the main branch.

A Pull Request is a core collaboration mechanism on code hosting platforms like GitHub. When a contributor wants to make changes to a project, the typical workflow is: first Fork the original project to your own account, make modifications on your own copy, then submit a Pull Request to the original project, requesting that the maintainers "pull" and merge your changes into the main codebase. A PR is more than just a code submission — it's a space for discussion and review. Maintainers can leave comments and suggest modifications on the PR, and contributors iterate and improve accordingly until both parties are satisfied and the merge is completed. This mechanism allows millions of developers around the world who have never met to collaborate in an organized manner.

In their own words: "I know it's small, but this is my first time contributing to an active project, not some unmaintained, stale, abandoned repo. I ran into a real problem that someone from a non-engineering background would encounter and felt like fixing it might help someone else."

This seemingly unremarkable experience actually embodies the most touching and essential aspect of the open source community.

Why Documentation Contributions Are Equally Important to Open Source Projects

Many people new to open source have a misconception: that only submitting code, fixing complex bugs, or implementing new features counts as a "real contribution." This isn't true. According to multiple studies by the Linux Foundation and GitHub, code commits account for only about 30-40% of all contribution activity in open source projects. Other contribution types include: documentation writing and improvement, bug reporting and reproduction, user interface design, translation and localization, community management and question answering, testing and quality assurance, and more. Large open source projects like Mozilla Firefox, Kubernetes, and VS Code all have dedicated "good first issue" labels to help new contributors find suitable entry points. Many projects also adopt the "All Contributors" specification, explicitly listing all types of contributors in project documentation — not just code authors.

Documentation Is the First Barrier to Entry for Open Source Projects

For any open source project, documentation is often the first point of contact for new users. Installation instructions, quick-start guides, API documentation — the clarity of this content directly determines whether a project can be successfully used by more people.

Documentation written by core developers often suffers from the "Curse of Knowledge" problem: developers are so familiar with the project that they unconsciously omit steps or prerequisites that are crucial for newcomers. This non-engineer user, with their "outsider" perspective, spotted exactly this blind spot.

The "Curse of Knowledge" is a cognitive bias first systematically described by Stanford University's Elizabeth Newton in her 1990 doctoral dissertation. It describes the phenomenon where once a person has mastered certain knowledge, they find it very difficult to imagine what it's like not knowing it, and therefore unconsciously skip key information when communicating with others. This phenomenon is particularly prominent in software development — documentation written by developers often assumes readers already understand specific environment configurations, dependencies, or terminology, which are precisely the things that trip up newcomers most easily. Research shows that documentation written or reviewed by non-experts or newcomers has a significant effect on lowering a project's barrier to entry.

The Unique Value of a Non-Expert Perspective

Precisely because they're not an engineer, they can more easily stand in the position of an ordinary user and identify confusing parts in the installation documentation. This "beginner's perspective" is a valuable resource that experienced developers find difficult to replicate. When they fixed the part that confused them, they were effectively clearing obstacles for all future users with similar backgrounds.

There's a widely circulated saying in the open source community: "A documentation PR is the best first contribution." It has a moderate barrier to entry, clear value, and carries almost no risk of breaking code logic.

How to Overcome Psychological Barriers When Submitting Your First PR

In this experience, the most noteworthy word is "nervously." The anxiety of submitting a first PR is a psychological state that almost every open source newcomer experiences.

Impostor Syndrome and Open Source Participation

"I'm not a software engineer" — behind this statement lies the common "Impostor Syndrome" experienced by many technology learners. People often worry that their contributions aren't professional enough, that they'll be mocked, or that they simply don't have the right to participate in mature projects.

Impostor Syndrome was first proposed by psychologists Pauline Clance and Suzanne Imes in 1978, initially used to describe self-doubt among high-achieving women, but later found to be widespread across all types of people. In the tech community, this phenomenon is particularly prevalent: according to GitHub's 2022 developer survey, over 60% of respondents admitted to having given up on submitting contributions to open source projects because they felt they "weren't qualified enough." This psychological barrier results in a large number of valuable potential contributions — especially those from people with non-traditional technical backgrounds — never being submitted. This is precisely why many modern open source projects explicitly welcome all types of contributions in their contribution guidelines, including documentation improvements, translations, design, and testing.

However, this user's experience proves exactly the opposite: open source communities are often friendlier than imagined. The project collaborator not only provided "real feedback" to help them refine their changes but ultimately expressed gratitude. This positive interaction loop is key to sustaining a healthy open source ecosystem.

Contributing to Active Projects vs. Abandoned Repositories

They specifically emphasized that this was their first contribution to an "active project" rather than a "stale, abandoned repository." This distinction is profoundly meaningful.

An "active" open source project typically has the following characteristics: regular commit history, Issues that receive timely responses, Pull Requests that are reviewed and processed within a reasonable timeframe, and clear contribution guidelines and codes of conduct. Code Review is the core quality assurance mechanism for such projects — it's not a judgment of a contributor's abilities, but rather a manifestation of collective wisdom. Through review, maintainers ensure consistent code style, correct logic, and no introduction of security vulnerabilities; at the same time, for contributors, it's an excellent learning opportunity. The internal code review systems at large tech companies like Google and Microsoft essentially originate from this open source community practice.

Contributing to an active project means your changes will actually be used, reviewed, and merged into a codebase that gets deployed in production. This real feedback loop is far more fulfilling than modifying a project nobody cares about, and it better helps you experience the true process of open source collaboration — from discovering a problem, submitting a PR, receiving a review, to the final merge.

The Essence of Open Source: Everyone Can Participate

The end of this post is particularly sincere: "I don't have anyone in my life who understands why this makes me so happy, so I'm posting here. I actually did it."

This statement reveals another layer of meaning to the open source community's existence — it's not just a platform for code collaboration, but a community that can understand and appreciate these "small achievements."

Every Open Source Contribution Accumulates Value

The open source world is built from countless "small contributions." Correcting a typo, supplementing installation instructions, clarifying an ambiguous expression — these seemingly insignificant changes collectively form the infrastructure that makes technology more accessible and inclusive.

For individuals, the significance of a first contribution far exceeds the change itself. It breaks through the psychological barrier of "only professionals can participate" and builds the confidence that "I can contribute too." Many of today's active core open source contributors started with a small documentation PR.

Practical Advice for Open Source Newcomers

If you also want to start your open source journey, this experience provides an excellent template:

• Start with problems you've actually encountered. The pitfalls you've stumbled into are likely the same ones others are stumbling into.
• Don't underestimate the value of documentation. Clear documentation is just as important as elegant code.
• Be brave in submitting PRs, and accept feedback gracefully. Code Review isn't criticism — it's part of the collaboration process.
• Choose active open source projects. Real interactions bring real growth and a sense of accomplishment.
• Look for issues tagged with "good first issue." Many projects specifically label tasks suitable for newcomers — these typically have a clear scope and moderate difficulty, making them ideal starting points.
• Read the project's CONTRIBUTING.md file. This contribution guide will tell you the project's coding standards, commit format requirements, and communication methods. Following it will make your PR much more likely to be accepted.

Conclusion

This user's story contains no earth-shattering technical breakthrough, yet it vividly demonstrates the most precious aspect of open source culture: anyone, regardless of background, can become a member of this vast collaborative network as long as they're willing to share and contribute.

"I actually did it" — this simple joy is the eternal wellspring of the open source spirit.