As this week marks the end of the second week of Hacktoberfest, I'm thrilled to share my experiences and progress on my journey in the open-source community. Hacktoberfest is an annual celebration of open-source software that encourages developers to contribute to various projects on GitHub. Participants are expected to work on different open-source projects each week and make contributions by creating pull requests.
In my previous blog post, I talked about how I started small, documenting my contributions to open source. It was a great way to ease into the process and get comfortable with the workflow.
Exploring Beyond Code
This week, I continued the same path. Instead of diving straight into coding, I wanted to become more comfortable with the non-coding aspects of contributing to open source. This involved finding issues, practicing forking repositories, creating topic branches, and, of course, making pull requests.
A Podcast Discovery
While my initial contributions were relatively small, I stumbled upon something more significant this week. I discovered the podcast Software Engineering Unlocked by Michaela Greiler. This podcast is a treasure trove of knowledge, where the host interviews software engineering leaders from around the world to discuss best practices, pitfalls, and the journey of building software that people love.
A Helping Hand
As I was exploring this podcast's open-source contributions, I found an issue that piqued my interest. This issue, related to episode 47, focused on how to enhance the transcripts of the episodes. The author needed help improving the clarity and understanding of these transcripts.
The Contribution Process
The process of contributing was familiar but still exciting. I followed the usual steps: fork the repository, create a branch, start the work, publish the branch, and finally, create a pull request. However, this time, my contributions went beyond code.
Collaborating and Clarifying
Throughout this journey, I had to collaborate with the author on several occasions to clarify various aspects of the transcripts. In some instances, the timestamps in the text didn't align with the audio. Additionally, I needed to confirm whether it was appropriate to remove filler words like "like" from the transcript.
The transcripts were originally generated by Text-To-Speech software, which can produce errors and awkward sentence structures. For instance, when speakers repeat sentences or jump between topics, the software struggles to maintain coherence.
Enhancing Clarity
My primary goal was to enhance the transcript's clarity and make it more reader-friendly. I diligently worked on the entire episode, ensuring that the text was both accurate and easy to understand.
The Final Step
After completing my work, I listened to the episode one more time to catch any errors that I might have missed initially. Finally, I was ready to create the pull request.
The Wait for Acceptance
As of writing this blog entry, my pull request has not been merged yet. While I do not have the final merge commit at this moment, I'm hopeful that it will be accepted soon. I'll be sure to update this post once that happens.
Final Merge Commit
After reaching out to the owner of the repository to bring my pull request to their attention, they quickly approved and merged my contributions. The merge commit can be found here.
Non-Coding Contributions Matter Too
While my recent open-source contribution involved non-coding work, it emphasized the importance of taking a similar approach to coding issues. Even when the task doesn't require writing code, it's crucial to understand the expectations and adhere to any provided guidelines. In my case, the project maintained specific guidelines for the transcript enhancement work, such as requesting a maximum paragraph width of approximately 80 words.
Open source projects often have established norms and guidelines that contributors must follow, regardless of whether the task is code-related or not. Adhering to these guidelines ensures consistency and helps maintain the project's quality and integrity.
In my experience with Software Engineering Unlocked, paying attention to these non-coding aspects proved to be just as significant as writing code. It's a reminder that open-source contributions come in various forms, and every form of contribution is valued and contributes to the project's success. So, whether it's code or non-code, always make an effort to understand and comply with project-specific guidelines.
My journey in the open-source community has been an incredible learning experience, and I'm excited to see how my contributions can make a positive impact on other open-source projects as well. This week, I ventured beyond code and realized that open-source contributions come in various forms, each equally valuable in the community.
Top comments (0)