5 Key Takeaways from Hacktoberfest 2020
Rate this article
Hacktoberfest 2020 is over, and it was a resounding success. We had over
100 contributions from more than 50 different contributors to the O-FISH
project. Learn about why the app is crucial in the NBC story about
O-FISH.
Before we get to the Lessons Learned, let's look at what was
accomplished during Hacktoberfest, and who we have to thank for all the
good work.
If you were a part of Hacktoberfest for the O-FISH
project, make sure you watch the
wrap-up
video
below. It's about 10 minutes.
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 MongoDB Community
forum badges! You can
still get an O-FISH
badge
at any time, by contributing to the O-FISH
project. Here's what the badges
look like:
Just go to the community forums post Open Source Contributors, Pick Up
Your Badges
Here!
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
| Merged/Closed | o-fish-android | o-fish-ios | o-fish-realm | o-fish-web | wildaid. github.io | Total |
|---|---|---|---|---|---|---|
| 01 - 04 Oct | 6 | 6 | 0 | 7 | 14 | 33 |
| 05 - 11 Oct | 9 | 5 | 0 | 10 | 3 | 27 |
| 12 - 18 Oct | 15 | 6 | 1 | 11 | 2 | 35 |
| 19 - 25 Oct | 4 | 1 | 1 | 4 | 1 | 11 |
| 26 - 31 Oct | 2 | 4 | 2 | 3 | 0 | 11 |
| Total | 36 | 22 | 4 | 35 | 20 | 117 |
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 onClick and Link in
node.js,
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.
O-FISH has a great backend infrastructure that anyone can build for
free. However, it takes time to build
and it is unrealistic to expect someone doing 30 minutes of work to fix
a bug will spend 2 hours setting up an infrastructure.
So, we set up a sandbox instance where people can fill out a
form
and automatically get a login to the sandbox server.
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!
O-FISH is open source and still accepting contributions. If you want to
work on O-FISH, just follow the contribution
guidelines -. To
contact me, message me from my forum
page -
you need to have the easy-to-achieve Sprout
level
for messaging.
If you have any questions or feedback, hop on over to the MongoDB
Community Forums. We
love connecting!
Rate this article