@@ -6,7 +6,7 @@ Guidelines for contributing to the Roslyn repo.
...
@@ -6,7 +6,7 @@ Guidelines for contributing to the Roslyn repo.
-**DO** ensure submissions pass all Jenkins legs and are merge conflict free.
-**DO** ensure submissions pass all Jenkins legs and are merge conflict free.
-**DO** follow the [.editorconfig](http://editorconfig.org/) settings for each directory.
-**DO** follow the [.editorconfig](http://editorconfig.org/) settings for each directory.
-**DO** submit language feature requests as issues in the [C# language](https://github.com/dotnet/csharplang#discussion) / [VB language](https://github.com/dotnet/vblang) repos. Once a feature is championed and validated by LDM a developer will be assigned to help begin a prototype on this repo inside a feature branch.
-**DO** submit language feature requests as issues in the [C# language](https://github.com/dotnet/csharplang#discussion) / [VB language](https://github.com/dotnet/vblang) repos. Once a feature is championed and validated by LDM, a developer will be assigned to help begin a prototype on this repo inside a feature branch.
-**DO NOT** submit language features as PRs to this repo first, or they will likely be declined.
-**DO NOT** submit language features as PRs to this repo first, or they will likely be declined.
-**DO** submit issues for other features. This facilitates discussion of a feature separately from its implementation, and increases the acceptance rates for pull requests.
-**DO** submit issues for other features. This facilitates discussion of a feature separately from its implementation, and increases the acceptance rates for pull requests.
-**DO NOT** submit large code formatting changes without discussing with the team first.
-**DO NOT** submit large code formatting changes without discussing with the team first.
...
@@ -17,7 +17,7 @@ These two blogs posts on contributing code to open source projects are good too:
...
@@ -17,7 +17,7 @@ These two blogs posts on contributing code to open source projects are good too:
## Creating Issues
## Creating Issues
-**DO** use a descriptive title that identifies the issue to be addressed or the requested feature. For example when describing an issue where the compiler is not behaving as expected, write your bug title in terms of what the compiler should do rather than what it is doing – “C# compiler should report CS1234 when Xyz is used in Abcd.”
-**DO** use a descriptive title that identifies the issue to be addressed or the requested feature. For example, when describing an issue where the compiler is not behaving as expected, write your bug title in terms of what the compiler should do rather than what it is doing – “C# compiler should report CS1234 when Xyz is used in Abcd.”
-**DO** specify a detailed description of the issue or requested feature.
-**DO** specify a detailed description of the issue or requested feature.
-**DO** provide the following for bug reports
-**DO** provide the following for bug reports
- Describe the expected behavior and the actual behavior. If it is not self-evident such as in the case of a crash, provide an explanation for why the expected behavior is expected.
- Describe the expected behavior and the actual behavior. If it is not self-evident such as in the case of a crash, provide an explanation for why the expected behavior is expected.
...
@@ -27,7 +27,7 @@ These two blogs posts on contributing code to open source projects are good too:
...
@@ -27,7 +27,7 @@ These two blogs posts on contributing code to open source projects are good too:
## Coding Style
## Coding Style
The Roslyn project is a member of the [.NET Foundation](https://github.com/orgs/dotnet) and follow the same [developer guide](https://github.com/dotnet/corefx/blob/master/Documentation/coding-guidelines/coding-style.md). The repo also includes [.editorconfig](http://editorconfig.org) files to help enforce this convention. Contributors should ensure they follow these guidelines when making submissions.
The Roslyn project is a member of the [.NET Foundation](https://github.com/orgs/dotnet) and follows the same [developer guide](https://github.com/dotnet/corefx/blob/master/Documentation/coding-guidelines/coding-style.md). The repo also includes [.editorconfig](http://editorconfig.org) files to help enforce this convention. Contributors should ensure they follow these guidelines when making submissions.