Community

Open source movement at its center is a vast, interconnected community project. Most open source initiatives aim for the benefit of “everyone”, this huge community is composed of thousands of individual projects and sub-communities, each with its own culture, goals and methods for interaction. For my contribution, understanding how to communicate and working in such communities was incredibly important.

My initial search for a suitable project revealed the size and supportiveness of the wider open-source community. Resources like Stack Overflow, Reddit (particularly subreddits like r/opensource) and dedicated platforms such as helpwanted.dev, up-for-grabs.net and goodfirstissue.com almost invaluable in finding a project to contribute to. These sites act as aggregators, curating project and their issues into a single place. GitHub’s own version of this further streamlines this process, making it accessible for both seasoned developers and newcomers like myself to find projects that align with their interests and skills.

One I identified the project I wished to contribute to, the next step was to get closer to the community and insert myself by offering my help. I found a few different things very useful in finding a relevant issue to work on.

Before I started to actively participate in the project, I spent some time looking over all the current issues, as well as the different communication channels they were using. Primarily they used github issues and discord for communication. This helped me understand the typical tone in how contributors and maintainers interacted and what the typical contribution looked like.

To easily find issues I wanted to attempt, I searched for tags such as “good first issue” or “easy” inside projects. This was my main method for finding a suitable entry point into a project. These issues are intentionally scoped for newcomers, allowing them to start on a easier problem whilst also leaning and understand the current code-base.

As I experienced it, technical discussion was usually made underneath the individual github issues. Here problem were clearly described, assigned, and often debated in hopes of finding the right solution.  This structured approach ensured clarity and allowed for asynchronous collaboration, which was vital.

Beyond the focused discussion on GitHub, the project’s discord channel served as a significant method for community building and engagement. This project offered more informal discussion on diverse aspects of design, potential future features, and significantly, direct communication with the projects users. This was a key strategy for the project to gather real-world feedback and for contributors to understand the user impact of their work. It allowed me to see the bigger picture and the human element behind the code.

In my experience, the combination of these methods of community exploration and understanding was key. The structured environment of GitHub issues provided the framework for technical contribution, while the more fluid, social environment of Discord helped i understanding the communities’ thoughts and needs. The clear “good first issue” labels seem to me to be the most direct and effective method for bridging the gap from an outsider to a potential contributor, making these communities feel quite accessible. These communities have helped me not only to contribute code, but also to begin understanding the collaborative spirit that underpins successful open source projects