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

language-csharp

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.

![low hanging fruit](https://rion.io/content/images/2017/04/the-easy-ones.jpg)

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:

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):

![current open easy and up for grabs tags](https://rion.io/content/images/2017/04/this-could-be-you.PNG)

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.

![family guy phoney](https://rion.io/content/images/2017/04/big-fat-phony-developer-1.jpg)

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](https://github.com/dotnet/coreclr/tree/master/Documentation) a wide range of topics such as:

 - [Suggested Contribution Workflow](https://github.com/dotnet/coreclr/blob/master/Documentation/project-docs/contributing-workflow.md#suggested-workflow)
 - [Coding Style Guidelines](https://github.com/dotnet/corefx/blob/master/Documentation/coding-guidelines/coding-style.md)
 - [Formatting Your Commit Messages](https://github.com/dotnet/coreclr/blob/master/Documentation/project-docs/contributing-workflow.md#commit-messages)
 - [How the Project CI Works](https://github.com/dotnet/coreclr/blob/master/Documentation/project-docs/contributing-workflow.md#pr---ci-process)
 - [Building Instructions](https://github.com/dotnet/coreclr/tree/master/Documentation/building) 
 - [Performance Testing Guidelines](https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/performance-tests.md)
 - 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](https://github.com/dotnet/corefx/wiki/New-contributor-Docs#main-page-section-content)

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.

![something big](https://rion.io/content/images/2017/04/uh-oh.PNG)

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 will 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](https://github.com/dotnet/coreclr/blob/master/Documentation/building/windows-instructions.md). 

Basically, you'll need to become 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](https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/developer-guide.md#build-and-run-tests).

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](is:issue is:open label:easy label:up-for-grabs ) as mentioned earlier, or try out an aggregate site like [Up For Grabs](http://up-for-grabs.net/#/). 
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.
2. **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.
3. **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](https://github.com/dotnet/coreclr/tree/master/Documentation/building) these  projects, which can get you pointed in the right direction.
4. **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.
5. **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.
6. **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.
7. **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 that 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.