5 Key Takeaways from Hacktoberfest 2020
Rate this article
The point of Hacktoberfest is to be a CELEBRATION of open source, not just "to make and get contributions." All pull requests, no matter how big or small, had a great impact. If you participated in Hacktoberfest, do not forget to claim your
badges! You can still get an
at any time, by contributing to the
. Here's what the badges look like:
There were lots of bug fixes, as well as feature additions both small and big—like dark mode for our mobile applications!
Contributions by week per repository
Here are the contributors who made Hacktoberfest so amazing for us! This would not have been possible without all these folks.
Hacktoberfest 2020 Contributors
Hacktoberfest is not about closing issues and merging PRs. It's about celebrating community, coming together and learning from each other. I learned a lot about specific coding conventions, and I felt like we really bonded together as a community that cares about the O-FISH application.
I also learned that some things we thought were code turned out to be permissions. That means that some folks did research only to find out that the issue required an instance of their own to debug. And, we fixed a lot of bugs we didn't even know existed by fixing permissions.
So, what did we learn from Hacktoberfest? These key takeaways are for project maintainers and developers alike.
Being a project maintainer means being a people manager. Behind every pull request (PR) is a person. Unlike in a workplace where I communicate with others all the time, there can be very few communications with contributors. And those communications are public. So, I was careful to consider the recipient of my feedback. There's a world of difference between, "This doesn't work," and "I tested this and here's a screenshot of what I see—I don't see X, which the PR was supposed to fix. Can you help me out?"
Tip 1: With fewer interactions and established relationships, each word holds more weight. Project maintainers - make sure your feedback is constructive, and your tone is appreciative, helpful and welcoming. Developers - it's absolutely OK to communicate more - ask questions in the Issues, go to any office hours, even comment on your own PR to explain the choices you made or as a question like "I did this with inline CSS, should I move it to a separate file?"
People likely will not code or organize the way I would expect. Sometimes that's a drawback - if the PR has code that introduces a memory leak, for example. But often a different way of working is a good thing, and leads to discussion.
For example, we had two issues that were similar, and assigned to two different people. One person misunderstood their issue, and submitted code that fixed the first issue. The other person submitted code that fixed their issue, but used a different method. I had them talk it out with each other in the comments, and we came to a mutual agreement on how to do it. Which is also awesome, because I learned too - this particular issue was about using
, and I didn't know why one was used over the other before this came up.
Tip 2: Project maintainers - Frame things as a problem, not a specific solution. You'd be surprised what contributors come up with. Developers - read the issue thoroughly to make sure you understand what's being asked. If you have a different idea feel free to bring it up in the issue.
Framing issues as a problem, not a specific solution, is something I do all the time as a product person. I would say it is one of the most important changes that a developer who has been 'promoted' to project maintainer (or team manager!) should internalize.
There are limitations on our sandbox, and some issues need your own instance to properly diagnose and fix. The sandbox is not a perfect solution, but it was a great way to lower the barrier for the folks who wanted to tackle smaller issues.
Tip 3: Project maintainers - Make it easy for developers to contribute in meaningful ways. Developers - for hacktoberfest, if you've done work but it did not result in a PR, ask if you can make a PR that will be closed and marked as 'accepted' so you get the credit you deserve.
There's a lot of work to do, that is not coding work. Issues should be well-described and defined as small amounts of work, with good titles. Even though I did this in September, I missed a few important items. For example, we had an issue titled "Localization Management System" which sounded really daunting and nobody picked it up. During office hours, I explained to someone wanting to do work that it was really 2 small shell scripts. They took on the work and did a great job! But if I had not explained it during office hours, nobody would have taken it because the title sounds like a huge project.
Office hours were a great idea, and it was awesome that developers showed up to ask questions. That really helped with something I touched on earlier - being able to build relationships.
Tip 4: Project Maintainers - Make regular time to meet with contributors in real-time - over video or real-time chat. Developers - Take any and every opportunity you can to talk to other developers and the project maintainer(s).
We hosted office hours for one hour, twice a week, on Tuesdays and Thursdays, at different times to accommodate different time zones. Our lead developer attended a few office hours as well.
When I get a pull request, I want to accept it. It's heartbreaking to not approve something. While I am technically the gatekeeper for the code that gets accepted to the project, knowing what to let go of and what to be firm on is very important.
In addition to accepting code done differently than I would have done it, I also accepted code that was not quite perfect. Sometimes I accepted that it was good enough, and other times I suggested a quick change that would fix it.
This is not homework and it is OK to give hints. If someone queried using the wrong function, I'll explain what they did, and what issues that might cause, and then say "use this other function - here's how it works, it takes in X and Y and returns A and B." And I'll link to that function in the code. It's more work on my part, but I'm more familiar with the codebase and the contributor can see that I'm on their team - I'm not just rejecting their PR and saying "use this other function", I'm trying to help them out.
As a product manager, ultimately I hope I'm enabling contributors to learn more than just the code. I hope folks learn the "why", and that decisions are not necessarily made easily. There are reasons. Doing that kind of mentorship is a very different kind of work, and it can be draining - but it is critical to a project's success.
I was very liberal with the hacktoberfest-accepted label. Sometimes someone provided a fix that just didn't work due to the app's own quirkiness. They spent time on it, we discussed the issue, they understood. So I closed the PR and added the accepted label, because they did good work and deserved the credit. In other cases, someone would ask questions about an issue, and explain to me why it was not possible to fix, and I'd ask them to submit a PR anyway, and I would give them the credit. Not all valuable contributions are in the form of a PR, but you can have them make a PR to give them credit.
Tip 5: Project maintainers: Give developers as much credit as you can. Thank them, and connect with them on social media. Developers: Know that all forms of work are valuable, even if there's no tangible outcome. For example, being able to rule out an option is extremely valuable.
The PRs that most surprised me were ones that made me file additional tickets—like folks who pointed out accessibility issues and fixed a few. Then, I went back and made tickets for all the rest.
All in all, Hacktoberfest 2020 was successful—for getting code written and bugs fixed, but also for building a community. Thanks to all who participated!
It's Not Too Late to Get Involved!