Before coming into tech, I spent ten years teaching college English. I've also written a couple of science fiction screenplays. To say that I'm fascinated by the power of storytelling would be an understatement. It's no surprise to me that science fiction has made an impact on open source and vice versa. So every Monday for the next three weeks, I'll have a post inspired by that relationship to hopefully inspire you.
It can be really exciting to get your first open source Pull Request (PR) merged in. But it’s important to remember that this is a step in the process and it’s perfectly normal to review feedback, make updates, and have questions before it’s merged in. Should you celebrate getting that PR in? Absolutely, but save the big celebration for when it’s merged.
Welcome to the Choose Your Own Adventure blog post for new contributors! Each person’s journey into open source will take a different path. As a new contributor, you may have different goals that you want to achieve through contributing to open source projects. This blog post will guide you through a few different paths based on your goals. Choose your path below and start your adventure!
Three years ago I maintained my first open source project for Hacktoberfest. As a first-time maintainer, I underestimated the time and effort it would take to write good issues for my contributors. What I also learned that year was that writing issues is an important form of communication, and, as a contributor, it can be a valuable skill to develop to create relationships and support maintainers. If you’re trying to get involved in open source, one way to get started is by writing issues that report bugs, request features, or suggest improvements.
One barrier to entry to contributing to open source is understanding the terminology, especially if you’re new to tech. Below, I've defined some of the common vocabulary and provided some examples to help provide context.
One of the first pieces of advice I got before graduating from bootcamp was to get involved in open source. I browsed around GitHub. I looked at issues. I peeked into code bases. I was overwhelmed. I didn’t quite feel like I had the capabilities to jump in and start working on an issue. Skill-wise, could I? Maybe, depending on the repository. Confidence-wise? No way. I was a career-changer with ten years of expertise in English and zero years of expertise in coding. But, if someone would have told me that I could start where I was most comfortable, without writing code, I think I could have eased my way into the open source waters sooner. Open source projects don’t always require code contributions; in fact, non-code contributions can be as valuable as code contributions.
I know, I know. It’s kind of ironic to create content about not needing to create content to get noticed. In recent years, there’s been a big push to have new developers create content to “get noticed.” But here’s the thing, creating content might feel daunting and discouraging for those who don't have the time or resources to create content regularly or it might take away from making progress in deepening your coding skills. The good news is that there are other ways to get noticed without relying solely on content creation, and in today’s post we’re going to talk about using open source to get noticed.
Pairing is more than just coding with someone else. Pairing is about communication, teaching, learning, positive reinforcements, and growing. This is why at Virtual Coffee, we’re challenging our members to practice their pairing in the month of May and we’re inviting everyone at Dev to join us too!
Before you start, we recommend you take a look at Martin Fowler’s article On Pair Programming.
It seems like my Twitter feed is all about folks joining or asking about invites to Bluesky. I was lucky enough to get an invite this week to be able to check it out, and the user experience is a lot like Twitter, but what’s going on behind the scenes is really interesting.
I collect open source projects like some people collect discord servers. To be accurate, I have 525 repositories. Now, before you yell at me, many of those are from my bootcamp lessons when I was learning to code. But I’ve been known to start and stop projects more than once. What I have learned through that experience is the importance of consistency. If you’re in an organization that has multiple repositories, you might find yourself adding the same files over and over–files like the CODE_OF_CONDUCT.md, Pull Request (PR) and Issue templates, and CONTRIBUTING.md. As developers, adding these files repeatedly starts to feel like we’re violating DRY code principles. Fortunately, the .github repository can help solve this problem.