Contributing To .NET For Dummies

Over the past few months, in the little spare time that I have, I've managed to submit a handful of pull requests to various .NET related repositories (e.g. coreclr, corefx, docs, etc.) and incredibly, they were accepted.

Now, for some, this may not seem like a big deal but it felt like a pretty big one to me, so I thought, I would take some time to elaborate on the process itself, share my experience, and hopefully dispel a few myths or misconceptions that you might have, and which may be holding you back from contributing to .NET as well.

Hopefully, you'll find that you don't need to be a genius or design a better sorting algorithm to make a meaningful contribution to .NET as a whole.

Dispelling Some Myths and Preconceived Notions

I'll openly admit that before browsing through the available .NET repositories, I was seriously intimidated, but without any real justified reasons. It seemed that I had built up quite a few myths surrounding the projects that were probably holding me back from contributing, such as:

• I need to be a coding wizard and all of the open issues are out of my reach.
• All of the easy issues that I could handle are taken.
• Since this was all in the open, I will be exposed as a crap developer (see Impostor Syndrome).
• I've never worked on a project of this scale, I'll probably screw it up.

These were just a few of the things that I had mentally told myself before embarking on this journey. What I quickly found out is that none of these things were true.

Let's tackle each of them. Shall we?

Myth #1: I need to be a coding wizard and all of the open issues are out of my reach.

All is the keyword here.

There are a TON of 'up-for-grabs' issues available across all of the .NET repositories. Some of these are serious challenges that require significant dedications of time, effort, talent, and thought. These feats aren't generally tackled alone, and undergo rounds of feedback and critique from both the .NET team and the community.

For each of those wizard-level problems, there are countless other housekeeping related ones that most developers could tackle. The best part about these is that they usually only need a bit of elbow grease.

Let's take a glance at my first contribution to a .NET-related repository.

This wasn't an open issue, but one that I stumbled upon when reading through the docs one day. I noticed that several variables throughout the examples had the following format, which just looked odd.

// static public doesn't look right, does it?
static public Type Foo { get; set; }

This directly goes against the .NET Framework Coding Guidelines, which state that "the visibility modifier should always be the first modifier present". This meant I just needed to call through the repository and find any other instances of this discrepancy and change the previous examples to, 

// Ah! Much better!
public static Type Foo { get; set; }

That's it!

I didn't have to invent a new algorithm, reduce any allocations, or anything. It's housekeeping, but it's something that needs to be done and does make a difference in the long run.

The entire process took place over a lunch break. I forked the repository, make the changes, submitted the PR, and it was merged all within a matter of hours. What a great feeling!

Myth #2: All of the easy issues that I could handle are taken.

The low-hanging fruit is often the quickest to be picked, and GitHub issues are no exception.

A while back, it may have been tough to find an "easy" issue to get your feet wet before it was snatched up. This isn't really the case anymore as the .NET folks have created a simple way to find your first issue to work on: the 'easy' label.

The 'easy' label is generally reserved for first-time contributors to the framework and it allows them to get their feet wet.

If there's an issue that you want to work on, simply jump in and ask to be assigned to it, and then you can get started. The .NET team members are incredibly helpful at answering questions, and generally don't mind walking you through the process.

So if you want to contribute, consider going to one of the popular .NET-related repositories and searching for the following under the Issues area:

is:issue is:open label:easy label:up-for-grabs 

This will filter all of the available issues that are currently opened and designated as "beginner friendly" (i.e. they are both up for grabs and should be fairly easy),

The general rule of thumb has been to reserve many of these types of issues for first time contributors, so this is probably a great starting point if you want to dive in.

There are more and more added each day, but they do tend to go fast. So you may want to keep an eye out for something that piques your interest, and stake your claim when you get the chance.

Myth #3: Since this is all in the open, I will be exposed as a crap developer.

If you have done anything related to open-source, you can probably skip this section as you already know what it feels like to have your code viewed by potentially hundreds of thousands of people a day.

If you don't, then you might be a little nervous. You might not be incredibly familiar with the process, the code base, or even things like git. Or you just might be afraid that people will judge and criticize your code to the point of embarrassment.

Well, don't be.

I know that's easy to say, but everyone that you will be working with throughout the process is there to help you (i.e. you are not going to be alone during this process).

Each of the major repositories has more documentation that you could imagine a wide range of topics such as:

• Suggested Contribution Workflow
• Coding Style Guidelines
• Formatting Your Commit Messages
• How the Project CI Works
• Building Instructions
• Performance Testing Guidelines
• Much, much, more.

In addition to these topics, the teams have been working hard on creating docs specifically tailored for new and first time contributors:

• New Contributor Documentation

Overall, the documentation will vary depending on which repository you are in and they are probably better documented that most projects you may have worked on, so that should ease some of the tension.

Once you actually submit a PR, a team member will review your commits and provide any feedback, which I've found to be a fairly pleasant experience. You might have a few nits here and there with minor changes or the reviewer may offer alternative approaches or recommendations to solving the problem (this commonly occurs in areas involving performance).

In my personal experience, the team was always extremely quick to react, and I felt that we were always on the same page and working together as opposed to him simply critiquing my code.

Myth #4: I've never worked on a project of this scale, I'll probably screw it up.

Let's get this out of the way: some of these projects are huge, and likely way larger than most things that you have probably encountered before. As such, you are going to need to work with them a bit differently.

When I first forked projects like the coreclr and corefx, I admit that they were a bit intimidating. Due to their sheer size and scale, they aren't terribly Visual Studio friendly, at least from a building and testing perspective. Thankfully, there is documentation available for how to go about building these tests within each of the repositories.

Basically, you'll need to become familiar with running the available building and test scripts from the command line. After building the projects, you should be able to open them up and edit them using Visual Studio, but keep that command prompt open as you'll use it frequently.

Testing and debugging are also going to be done predominately from the command-line as Visual Studio's Test Explorer will melt if it tried to run all of these tests. Thankfully, there's extensive documentation for that as well.

Getting acclimated to this environment can probably be one of the largest learning curves in this entire process, but it's something that you'll only need to do once. Another thing worth noting is that due to the scale of these projects, building can be slow, so make sure you have something to do while you wait.

How to Contribute

Hopefully, the dispelling of some of these myths have built your confidence up enough to consider making a contribution. If so, here's what you'll need to do:

1. Find an issue that you want to work on
   Consider either searching one of the popular dotnet repositories using the easy/up-for-grabs labels as mentioned earlier, or try out an aggregate site like Up For Grabs.
   
   
2. Sign a Contribution License Agreement
   In order to work and actively contribute to a .NET Foundation project, you'll need to agree to the terms of the CLA. This will also require you to set up two-factor authentication for your GitHub account.
   
   
3. Fork the Repository
   In order to work on a particular issue, you'll need to be working on your own fork of the project, which you'll eventually merge back in once your changes are complete.
   
   
4. Building and Running
   Building some of these projects isn't likely going to be the same as running your average project within Visual Studio. Thankfully, there's a wide range of documentation for building and running these projects, which can get you pointed in the right direction.
   
   
5. Make Your Changes
   After you have the solution running, make your changes to apply the fix. Don't be afraid to ask any questions on GitHub if they arise throughout this process.
   
   
6. Write Tests (As Needed)
   Some changes will require that a set of unit tests are written for any new or altered functionality. Any team member that is assigned to your issue will likely let you know about this, and about where to go about writing the tests themselves.
   
   
7. Submit Your Pull Request
   Now that all of your changes are made and they appear to be working, you can submit your pull request. It will undergo a review process and a team member will provide any feedback as needed.
   
   
8. LGTM!"
   Looks good to me!" This will usually be one of the last things that you see on your PR, and it's an indication that you are about to officially become a contributor to .NET. Congrats!

In Closing

My experiences with contributing to .NET have been nothing but stellar. It was great to have a chance to collaborate with members of the .NET team and the community towards improving the ecosystem, even in the smallest of ways. Simply knowing how a minor performance improvement that saves milliseconds here or there could save so much time on such a large scale is really rewarding.

I know that this experience certainly struck a chord with me, and in the weeks following my initial merged pull request, I've probably rattled off 10+ additional ones, and I look forward to contributing more in the future.

I hope this post helped ease your mind if you thought that you wouldn't have anything to contribute, or that it would simply be beyond your skill-set or talent. There's something out there for everyone, so go out there and get that First-Time Contributor badge and help make .NET a better place.