The first time I pair programmed was with one of the founders of the bootcamp I attended. I was super nervous. We talked through some concepts I was working on, and he asked me to open up an editor. Ok, side note, I had spent the previous years teaching college English. When someone said “editor,” I assumed a text editor. I opened up google docs. It wasn’t until he said something like, “Do you have notepad or something else that we can use?” that I realized he was talking about a code editor. I think I was using the now-sunsetted Integrated Development Environment (IDE) Atom, but since then, I’ve been using Visual Studio Code (VS Code), which we’re going to be talking about in this blog post, as a way to get started with creating an open source repository.

Welcome back to our final post in this series about Open Source in Science Fiction. We've looked at imaginary worlds inspiring real-world innovation, and real-life concepts inspiring science fiction. In this last post, we'll dive into the impact of open source in science fiction and the influence on the genre and tech landscape.

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.