This is a submission for the 2024 Hacktoberfest Writing challenge: Contributor Experience
When October began, Me and some seniors at our club Point Blank were wondering how we can get the new and existing members of our club to contribute to Open Source and Hacktoberfest.
In this blog I will outline and answer the common doubts related to open source contributions and how to make Hacktoberfest worth it for not only you, but the community as well.
Intro
I am Akash Singh, a Backend Developer and Open Source Contributor.
Here is my LinkedIn, GitHub and Twitter
I go by the name SkySingh04 online.
My Contributions
Before I start explaining and answering the FAQ's, It's important to note how I personally did my Hacktoberfest. I was able to finish all 4 PR's, and am currently working on 2 more PR's even after **Hacktoberfest **ended.
You can check out the Merged PR's here : Github Gist and read about my contributions here LinkedIn Post
As far as I scrolled through LinkedIn, I realize this is on the lower end of contributions. This is where I have a very strong opinion regarding open source in general :
Quality Over Quantity
Is it easy enough to submit 10 more Readme contributions? Yes, infact a number of repos on Github are made specifically for the purpose of getting the Hacktoberfest badges, with zero / minimum actual code.
Now I am aware of the guidelines of Hacktoberfest that encourage both Code and No Code Contributions. As such, I am not against No Code Contributions , but I am strongly against low effort contributions, which brings us to one of the most common questions.
How To Avoid Low Effort Contributions?
We live in an era of the internet where making a Readme change is as simple as prompting Chatgpt/LLMs with the right data and it will literally write the Readme/ Documentation for you.
As a rule of thumb, if the issue can be solved via a simple prompt to Chatgpt, are you even making a contribution to open source in the first place?
Moving a step ahead from open source, how is making such a contribution helping you? Are you learning something new? Are you exploring a new codebase? Chances are, the answer is a NO.
Circling back to the question, I believe the best kind of contributions are those that not only are on Production Code and help the maintainers, but also help you learn / explore something new. It maybe a new language you wanted to try, or a new project you find interesting. The only rule is to not waste the maintainers time with low effort questions / contributions.
My whole agenda of doing Hacktoberfest was to get more comfortable with RUST and I am pretty satisfied with my 3/4 PR's being Rust contributions.
How To Find Repositories To Contribute?
I will be sharing the trick I shared with my peers and juniors at Point Blank. Lets assume you want to contribute to Rust based projects.
- One of the best places to find repos to contribute is the Github topics page
- On this page , we can easily sort repos by the language of choice.
- The trick is to sort the repos via recently updated. This ensures you get repos that are not only active, but are actively looking for contributions!
And voila! You now have a list of repos to go find issues to contribute to!
How To Find Issues to work on?
Now, what happened with a lot of my peers at Point Blank (and myself) is that we couldn't find good issues that interest us. And when we did, there was already someone working on it.
Well of course, one solution is to keep on looking for unassigned issues, another is to ask the maintainers if they have any issues for new contributors.
What I want to talk about is this third scenario where someone has committed to solving a issue but never does. Such kind of people not only deserve a special place in hell, but also end up ruining the spirit of open source.
Lets take this issue in Doctl for example.
In this issue, a contributor initially expressed interest in working on it, and the maintainer gave them the go-ahead. However, after stating they would "close it by Monday," no progress was made, nor was any PR submitted by the set deadline.
This left the issue open and unresolved, which can be frustrating for the project’s progress, especially when other contributors were interested in solving it but held off in respect of the initial claim.
After the original assignee didn’t follow through, I revisited the issue, ensured that no one was actively working on it, and eventually submitted the PR myself.
- Ultimately, this demonstrates why maintaining clear communication and respecting deadlines are crucial. Committing to an issue and not following through can block other contributors and delay valuable improvements.
Key Takeaway
- If you claim an issue, make sure you’re committed to completing it or communicate with the maintainers if you’re unable to continue. Open source relies heavily on collaboration and transparency, so leaving others in the dark harms the project and wastes community effort.
Amaze, Now really quickly let's go over some Do's and Don'ts
Do’s ✅
Find Projects with Active Maintainers and Open Issues ✅
Look for repositories that are recently updated and actively managed. This increases the likelihood that your contribution will be seen, reviewed, and merged.Choose Quality Over Quantity ✅
Focus on meaningful contributions that provide real value. Fix bugs, add features, or improve documentation in ways that truly help the project, rather than just seeking to increase your PR count.Be Transparent and Communicate ✅
If you claim an issue, keep the maintainers informed of your progress. If you can’t complete it, let them know so others can pick it up.Use Open Source to Learn and Explore New Tech ✅
Leverage your contributions to explore new languages or frameworks, and deepen your understanding of existing ones. This approach makes contributions more enriching for both you and the project.Ask Questions and Seek Help If Needed ✅
If you’re stuck, don’t hesitate to ask maintainers or the community for help. Clear communication shows dedication and fosters collaboration.
Don’ts ❌
Avoid Low-Effort Contributions ❌
Avoid submitting minor or trivial changes, like typo fixes or formatting updates, unless they are genuinely helpful. Contributions should add value to the project and not clutter the maintainers’ workload.Don’t Claim Issues You Aren't Committed To Completing ❌
Claiming issues without follow-through disrupts progress and blocks other contributors who may be eager to work on them.Refrain from Spammy or Artificial Contributions ❌
Resist the temptation to create pull requests on fake or spam repositories just to earn a badge. These actions dilute the purpose of Hacktoberfest and harm the integrity of open source.Don’t Submit Changes You Haven’t Tested ❌
Testing your code before submission ensures that you’re not introducing bugs or issues into the project. Untested code is a disservice to the maintainers and fellow contributors.Avoid Relying Entirely on AI Tools for Contributions ❌
While tools like ChatGPT can help with generating documentation or code snippets, ensure that your contributions go beyond automated responses. Genuine contributions involve critical thinking and adaptation specific to the project’s needs.
So What's the point of this?
Hacktoberfest is an opportunity for all of us to learn something new, build and contribute to software all across the world. Who knows what doors it may open for you? Please don't waste it with spam contributions just for the sake of a badge you get to show on LinkedIn.
Even more so, don't waste the contributors time with spam PR's and low effort contributions. Contributing to open source is about more than just adding to your GitHub profile. It’s an opportunity to grow.
Top comments (8)
I agree with most of your points, as a maintainer the most annoying things were:
If you did and then see that you cannot complete it say so, nobody will be angry about that, But repeatedly saying you are working on it and not delivering blocks progress on the issue. As a maintainer check the progress, remind the assignee, and if it seems to take too long, make the call and unassign them.
I won't even look at PRs that do not pass CI, when the tests fail, the issue is not solved.
If you introduce new functionality, or a bug fix, make sure it is thoroughly tested.
Thanks for sharing your insights, Glad to hear we share mutual opinions on Open Source!
Must read for beginners who are just stepping into open-source contribution or willing to crack GSOC or hacktoberfest.
Thank you!
Regarding “do you really make a contribution with README changes”, I would say: yes, absolutely! Stating otherwise wouldn’t be fair.
A README file is there to teach you how to do x,y and z in that repo. If that information is incorrect it doesn’t provide any value. You could argue that a repo is worthless if the README is missing or incorrect.
IMO, all contributions, minor or major, are great and it’s nice that there’s something for everyone.
Same goes for AI prompts - if it fixes an issue on that repo, does it even matter if you wrote it or AI? You took the initiative to get it fixed in the first place.
Here is my opinion from a contributor perspective, what does a README change give me as a contributor? What does an AI based contribution do for my learnings?
Yes they help with the community and yes, on any normal day, I would encourage people to ahead and help open source projects with any documentation fixes / contributions they can! That's the backbone of open source!
But in the context of Hacktoberfest, I stand by my opinion that as a contributor, you are better off trying to make meaningful contributions, rather than typo fixes just for the sake of badges.
Detailed and informative :)
Thank you good sir :D