Runtime: How I can contribute to dot net core source code

Created on 19 Feb 2017  路  3Comments  路  Source: dotnet/runtime

@Petermarcu ,can you help me please, I want to contribute to dot net core source code, but I don't know how to start , I did not contribute to any open source projects before, but I love .Net too much.

Thank you.

Most helpful comment

  1. Take a look at How to Engage, Contribute and Provide Feedback and the documents it links to.

  2. If you don't know it already, learn about the GitHub Flow (though only the first few slides will apply to you, the last two are about how project owners make use of contributions).

  3. For that matter if you don't already know about branching in git, learn that. It's also possible to have used git for a long time and never bothered with rebasing, but it's used here to keep PRs just about their own changes (if you had to merge in changes because your PR had been made out of date, you should rebase so that the merge doesn't end up in the PR but just your changes are applied on top of the current state). The git book and git docs explain that, but some people find doing it in TortoiseGit easier.

  4. If you don't already know xUnit learn a bit about it, as the tests here are written in it, and you'll want to make sure that your changes are covered by tests. Take a look at the tests that already exist, especially those relatively recently added (some of the tests that were created by porting tests from elsewhere are a bit strange and not xUnit-idiomatic).

  5. Take a look at the existing Pull Requests to see the process in action.

  6. Find an up for grabs issue you think you can handle. I recommend starting with testing. There are several projects that need a lot more tests, and if there's a part of the library you are particularly interested in and it has some gaps in coverage then filling those with good tests (that actually test, rather than just make the red lines go green in the coverage report!) will be good. As well as contributing in its own right it's a good way to become more familiar with that project which will be necessary when it comes to contributing actual changes (and a benefit to you as a .NET developer generally since deep knowledge of any part of the framework libraries is good to have) and you may also uncover fresh issues that way and be in the prime position to fix them. It will also give hands-on practice with xUnit and as I said above, you'd want any changes you make to the source libraries to be covered by tests demonstrating that you've fixed what you wanted to fix and (if not already heavily covered) not broken anything in the process.

  7. (Optional) Find the process oddly addictive and keep going!

All 3 comments

  1. Take a look at How to Engage, Contribute and Provide Feedback and the documents it links to.

  2. If you don't know it already, learn about the GitHub Flow (though only the first few slides will apply to you, the last two are about how project owners make use of contributions).

  3. For that matter if you don't already know about branching in git, learn that. It's also possible to have used git for a long time and never bothered with rebasing, but it's used here to keep PRs just about their own changes (if you had to merge in changes because your PR had been made out of date, you should rebase so that the merge doesn't end up in the PR but just your changes are applied on top of the current state). The git book and git docs explain that, but some people find doing it in TortoiseGit easier.

  4. If you don't already know xUnit learn a bit about it, as the tests here are written in it, and you'll want to make sure that your changes are covered by tests. Take a look at the tests that already exist, especially those relatively recently added (some of the tests that were created by porting tests from elsewhere are a bit strange and not xUnit-idiomatic).

  5. Take a look at the existing Pull Requests to see the process in action.

  6. Find an up for grabs issue you think you can handle. I recommend starting with testing. There are several projects that need a lot more tests, and if there's a part of the library you are particularly interested in and it has some gaps in coverage then filling those with good tests (that actually test, rather than just make the red lines go green in the coverage report!) will be good. As well as contributing in its own right it's a good way to become more familiar with that project which will be necessary when it comes to contributing actual changes (and a benefit to you as a .NET developer generally since deep knowledge of any part of the framework libraries is good to have) and you may also uncover fresh issues that way and be in the prime position to fix them. It will also give hands-on practice with xUnit and as I said above, you'd want any changes you make to the source libraries to be covered by tests demonstrating that you've fixed what you wanted to fix and (if not already heavily covered) not broken anything in the process.

  7. (Optional) Find the process oddly addictive and keep going!

Thank you very much @JonHanna , Great description and path to start & follow . Thank you again for your time writing this replay.

@Malikshehadah indeed you are welcome to contribute. I will close this now as the question is answered but do summon me with @danmosemsft if you have questions or are looking for guidance.

Was this page helpful?
0 / 5 - 0 ratings