You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .github/CONTRIBUTING.md
+32-6Lines changed: 32 additions & 6 deletions
Original file line number
Diff line number
Diff line change
@@ -39,7 +39,7 @@ When you are creating an enhancement suggestion, please include as many details
39
39
40
40
-**Use a clear and descriptive title** for the issue to identify the suggestion.
41
41
-**Provide a step-by-step description of the suggested enhancement** in as many details as possible.
42
-
-**Provide specific examples to demonstrate the usage.** Include copy/pasteable snippets which you use in those examples, as [Markdown code blocks](https://docs.github.com/en/github/writing-on-github/creating-and-highlighting-code-blocks).
42
+
-**Provide specific examples to demonstrate the usage.** Include copy/pasteable snippets which you use in those examples as [Markdown code blocks](https://docs.github.com/en/github/writing-on-github/creating-and-highlighting-code-blocks).
43
43
-**Describe the current behavior and explain which behavior you expected to see instead** and why.
44
44
-**Explain why this enhancement would be useful** to most users and isn't something that can or should be implemented in your API project directly.
45
45
-**Verify that your enhancement does not conflict** with the [JSON:API specification](https://jsonapi.org/).
@@ -56,7 +56,7 @@ Please follow these steps to have your contribution considered by the maintainer
56
56
- Follow all instructions in the template. Don't forget to add tests and update documentation.
57
57
- After you submit your pull request, verify that all status checks are passing. In release builds, all compiler warnings are treated as errors, so you should address them before push.
58
58
59
-
We use [CSharpGuidelines](https://csharpcodingguidelines.com/) as our coding standard (with a few minor exceptions). Coding style is validated during PR build, where we inject an extra settings layer that promotes various suggestions to warning level. This ensures a high-quality codebase without interfering too much when editing code.
59
+
We use [CSharpGuidelines](https://csharpcodingguidelines.com/) as our coding standard. Coding style is validated during PR build, where we inject an extra settings layer that promotes various IDE suggestions to warning level. This ensures a high-quality codebase without interfering too much while editing code.
60
60
You can run the following [PowerShell scripts](https://github.com/PowerShell/PowerShell/releases) locally:
61
61
-`pwsh ./inspectcode.ps1`: Scans the code for style violations and opens the result in your web browser.
62
62
-`pwsh ./cleanupcode.ps1 [branch-name-or-commit-hash]`: Reformats the codebase to match with our configured style, optionally only changed files since the specified branch (usually master).
@@ -86,13 +86,39 @@ public sealed class AppDbContext : DbContext
86
86
}
87
87
```
88
88
89
+
### Pull request workflow
90
+
91
+
Please follow the steps and guidelines below for a smooth experience.
92
+
93
+
Authors:
94
+
- When opening a new pull request, create it in **Draft** mode.
95
+
- After you've completed the work *and* all checks are green, click the **Ready for review** button.
96
+
- If you have permissions to do so, ask a team member for review.
97
+
- Once the review has started, don't force-push anymore.
98
+
- When you've addressed feedback from a conversation, mark it with a thumbs-up or add a some text.
99
+
- Don't close a conversation you didn't start. The creator closes it after verifying the concern has been addressed.
100
+
- Apply suggestions in a batch, instead of individual commits (to minimize email notifications).
101
+
- Re-request review when you're ready for another round.
102
+
- If you want to clean up your commits before merge, let the reviewer know in time. This is optional.
103
+
104
+
Reviewers:
105
+
- If you're unable to review within a few days, let the author know what to expect.
106
+
- Use **Start a review** instead of **Add single comment** (to minimize email notifications).
107
+
- Consider to use suggestions (the ± button).
108
+
- Don't close a conversation you didn't start. Close the ones you opened after verifying the concern has been addressed.
109
+
- Once approved, use a merge commit only if all commits are clean. Otherwise, squash them into a single commit.
110
+
A commit is considered clean when:
111
+
- It is properly documented and covers all aspects of an isolated change (code, style, tests, docs).
112
+
- Checking out the commit results in a green build.
113
+
- Having this commit show up in the history is helpful (and can potentially be reverted).
114
+
89
115
## Creating a release (for maintainers)
90
116
91
117
- Verify documentation is up-to-date
92
-
- Bump the package version in Directory.Build.props
118
+
- Bump the package version in `Directory.Build.props`
93
119
- Create a GitHub release
94
-
- Update https://github.com/json-api-dotnet/JsonApiDotNetCore.MongoDb to consume the new version and release
95
-
- Create a new branch in https://github.com/json-api-dotnet/MigrationGuide and update README.md in master
120
+
- Update [JsonApiDotNetCore.MongoDb](https://github.com/json-api-dotnet/JsonApiDotNetCore.MongoDb) to consume the new version and release
121
+
- Create a new branch in [MigrationGuide](https://github.com/json-api-dotnet/MigrationGuide) and update README.md in master, if major version change
96
122
97
123
## Backporting and hotfixes (for maintainers)
98
124
@@ -101,7 +127,7 @@ public sealed class AppDbContext : DbContext
101
127
git checkout tags/v2.5.1 -b release/2.5.2
102
128
```
103
129
- Cherrypick the merge commit: `git cherry-pick {git commit SHA}`
104
-
- Bump the package version in Directory.Build.props
130
+
- Bump the package version in `Directory.Build.props`
105
131
- Make any other compatibility, documentation, or tooling related changes
106
132
- Push the branch to origin and verify the build
107
133
- Once the build is verified, create a GitHub release, tagging the release branch
<h2>A framework for building <ahref="https://jsonapi.org/" target="_blank">JSON:API</a> compliant REST APIs using .NET Core and Entity Framework Core. Includes support for <ahref="https://jsonapi.org/ext/atomic/" target="_blank">Atomic Operations</a>.</h2>
25
+
<h2>
26
+
A framework for building <ahref="https://jsonapi.org/" target="_blank">JSON:API</a> compliant REST APIs using .NET Core and Entity Framework Core.
27
+
Includes support for <ahref="https://jsonapi.org/ext/atomic/" target="_blank">Atomic Operations</a>.
<ahref="https://github.com/json-api-dotnet/JsonApiDotNetCore/" target="_blank" class="btn-get-started">Contribute on GitHub</a>
@@ -43,12 +46,13 @@ <h2>A framework for building <a href="https://jsonapi.org/" target="_blank">JSON
43
46
<divclass="col-lg-6 pt-5 pt-lg-0">
44
47
<h3data-aos="fade-up">Objectives</h3>
45
48
<pdata-aos="fade-up" data-aos-delay="100">
46
-
The goal of this library is to simplify the development of APIs that leverage the full range of features provided by the <ahref="https://jsonapi.org/" target="_blank">JSON:API</a> specification.
49
+
The goal of this library is to simplify the development of APIs that leverage the full range of features
50
+
provided by the <ahref="https://jsonapi.org/" target="_blank">JSON:API</a> specification.
47
51
You just need to focus on defining the resources and implementing your custom business logic.
<pclass="description">Validate incoming requests using built-in ASP.NET Core <code>ModelState</code> validation, which works seamlessly with partial updates</p>
124
+
<pclass="description">Validate incoming requests using built-in ASP.NET Model Validation, which works seamlessly with partial updates</p>
0 commit comments