A couple of years ago, I got to see Neil Gaiman--the English author, creator, and creative genius--live. To say the experience was inspirational would be an understatement. There's something moving about hearing a person share their stories, listening to them read though. There's deeper meaning when you can see their expressions, the ways they move on the stage. You come out of the experience inspired to pursue the things you're passionate about. And it reminded me about an interview he gave a couple of years ago about his experience speaking about science fiction at the first-ever, state-sponsored science fiction convention.

One of the reasons I love open source is because of the collaboration, community, and growth that often happens. Part of that growth includes having your pull request (PR) rejected. In fact, I think we should embrace this as part of the learning experience. To fully learn, you need to understand why your PR was rejected and what you can do to increase your chances of having your contributions accepted the next time you submit a PR. Below you'll find some of the reasons PRs are rejected.

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.