.NET contributor 101: What does it mean to contribute?


Given the existing Azure projects on Github and now .NET and VS Community edition, I think this brings the idea of “open source” (note the scare quotes) contribution to a potentially much larger audience of developers.

I know some guidelines have been published. What I’ve read seems a bit intimidating to me, not being familiar with projects of this size, though I’m assured they are common. I’m thinking things like CLAs, automated pull request reviews, and general etiquette for dealing with large projects of this kind… let’s call them “open contribution”.

My question more directly is:

What would you want a first-time contributor to know before forking a project or considering a pull request?

Where would you send them to learn before they write a line of code?

What are appropriate expectations for contributions being accepted?


These are excellent questions! They way my team started open source is essentially by jumping into the cold water, so to speak.

There is obviously a lot of prior around that at Microsoft, specifically WiX, ASP.NET, TypeScript, and Roslyn but each community and project is slightly different. We’ve talked a lot with people on these these projects – and still do – to learn from each other. However, I think it’s also fair to say that we started by treading a way and will improve over time until it becomes a fully paved highway.


What would you want a first-time contributor to know before forking a project or considering a pull request?

For any project you should first check out the contribution guidelines. The usual convention on GitHub is putting a a file called CONTRIBUTING.md or similar name in the root of the repository. For the .NET Core Framework, the file can be found here.

Where would you send them to learn before they write a line of code?

That’s a good question. The way I see this is similar to how any social interaction works. When you’re invited to a party in someones house you’ve never been to, you usually start by chatting with a few folks and observe the kind of conversation that are happening there before you jump in and share a story from your life.

I think open source works similar. You should take a look at some of the pull requests and see what kind of feedback people get. This gives you an idea of what folks care about. You should also look at the issue tracker and look for open bugs to get a handle on the direction of the project. If the project has a roadmap, you should read it (we’ll share one for .NET Core soon).

Most projects encourage folks to file an issue before starting to invest a lot of time into coding. This ensures that both parties can get on the same page to see whether that’s the right direction for the project. It’s also a good starting point for discussing design options.

Some projects also mark their issues as up-for-grabs to indicate issues they need help with from the community. We’ve started to do the same.

What are appropriate expectations for contributions being accepted?

I think from our point of view it’s really about these two parts:

  • Roadmap. All projects focus their energy on certain areas. In order to keep the focus and the momentum it’s important that most of the work is aligned with the product’s roadmap.

  • Quality. We’ve a responsibility for shipping high quality code. Therefore, external folks have to meet the same quality bar that Microsoft employees have to meet. This includes having the right design, architecture, sufficient test coverage and following the coding style.

We believe by doing the development in the open we provide enough context for external developers to be successful. For example, you’ll be able to observe our code reviews and read documentation about how the internals are designed.

And when in doubt: ask.


Excellent comments. These are great points. If I can sum up a bit, what you’re basically saying is “observe and do some research before diving in.” I agree with that approach (in many aspects of life).

As you pointed out earlier, the roadmap would entail, at some level, “up-for-grabs” as well as work identified through issues discussion. Are there other places people should look for guidance on the roadmap?

What would you suggest as the best place to find guidance on the Microsoft quality bar, design and coding style?

.NET Foundation Website | Blog | Projects | Code of Conduct