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
- Submit small, focused PRs addressing a single concern/issue.
84
+
- Make sure the PR title reflects the contribution.
85
+
- Write a summary that helps understand the change.
86
+
- Include usage examples in the summary, where applicable.
85
87
86
88
### How to Get PRs Merged
87
89
88
90
A PR is considered to be **ready to merge** when:
89
91
90
-
* Major feedbacks are resolved.
91
-
* It has been open for review for at least one working day. This gives people
92
-
reasonable time to review.
93
-
* Trivial change (typo, cosmetic, doc, etc.) doesn't have to wait for one day.
94
-
* Urgent fix can take exception as long as it has been actively communicated.
92
+
- Major feedbacks are resolved.
93
+
- It has been open for review for at least one working day. This gives people
94
+
reasonable time to review.
95
+
- Trivial change (typo, cosmetic, doc, etc.) doesn't have to wait for one day.
96
+
- Urgent fix can take exception as long as it has been actively communicated.
95
97
96
98
Any Maintainer can merge the PR once it is **ready to merge**. Note, that some
97
99
PRs may not be merged immediately if the repo is in the process of a release and
@@ -100,32 +102,33 @@ the maintainers decided to defer the PR to the next release train.
100
102
If a PR has been stuck (e.g. there are lots of debates and people couldn't agree
101
103
on each other), the owner should try to get people aligned by:
102
104
103
-
* Consolidating the perspectives and putting a summary in the PR. It is
104
-
recommended to add a link into the PR description, which points to a comment
105
-
with a summary in the PR conversation.
106
-
* Tagging subdomain experts (by looking at the change history) in the PR asking
107
-
for suggestion.
108
-
* Reaching out to more people on the [CNCF OpenFeature Slack channel](https://cloud-native.slack.com/archives/C0344AANLA1).
109
-
* Stepping back to see if it makes sense to narrow down the scope of the PR or
110
-
split it up.
111
-
* If none of the above worked and the PR has been stuck for more than 2 weeks,
112
-
the owner should bring it to the OpenFeatures [meeting](README.md#contributing).
105
+
- Consolidating the perspectives and putting a summary in the PR. It is
106
+
recommended to add a link into the PR description, which points to a comment
107
+
with a summary in the PR conversation.
108
+
- Tagging subdomain experts (by looking at the change history) in the PR asking
109
+
for suggestion.
110
+
- Reaching out to more people on the [CNCF OpenFeature Slack channel](https://cloud-native.slack.com/archives/C0344AANLA1).
111
+
- Stepping back to see if it makes sense to narrow down the scope of the PR or
112
+
split it up.
113
+
- If none of the above worked and the PR has been stuck for more than 2 weeks,
114
+
the owner should bring it to the OpenFeatures [meeting](README.md#contributing).
113
115
114
116
## Automated Changelog
115
117
116
-
Each time a release is published the changelogs will be generated automatically using [dotnet-releaser](https://github.com/xoofx/dotnet-releaser/blob/main/doc/changelog_user_guide.md#13-categories). The tool will organise the changes based on the PR labels.
118
+
Each time a release is published the changelogs will be generated automatically using [googleapis/release-please-action](https://github.com/googleapis/release-please-action). The tool will organise the changes based on the PR labels.
119
+
Please make sure you follow the latest [conventions](https://www.conventionalcommits.org/en/v1.0.0/). We use an automation to check if the pull request respects the desired conventions. You can check it [here](https://github.com/open-feature/dotnet-sdk/actions/workflows/lint-pr.yml). Must be one of the following:
120
+
121
+
- build: Changes that affect the build system or external dependencies (example scopes: nuget)
122
+
- ci: Changes to our CI configuration files and scripts (example scopes: GitHub Actions, Coverage)
123
+
- docs: Documentation only changes
124
+
- feat: A new feature
125
+
- fix: A bug fix
126
+
- perf: A code change that improves performance
127
+
- refactor: A code change that neither fixes a bug nor adds a feature
128
+
- style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
129
+
- test: Adding missing tests or correcting existing tests
117
130
118
-
- 🚨 Breaking Changes = `breaking-change`
119
-
- ✨ New Features = `feature`
120
-
- 🐛 Bug Fixes = `bug`
121
-
- 🚀 Enhancements = `enhancement`
122
-
- 🧰 Maintenance = `maintenance`
123
-
- 🏭 Tests = `tests`, `test`
124
-
- 🛠 Examples = `examples`
125
-
- 📚 Documentation = `documentation`
126
-
- 🌎 Accessibility = `translations`
127
-
- 📦 Dependencies = `dependencies`
128
-
- 🧰 Misc = `misc`
131
+
If you want to point out a breaking change, you should use `!` after the type. For example: `feat!: excellent new feature`.
1. Acquire a [GitHub personal access token (PAT)](https://docs.github.com/github/authenticating-to-github/creating-a-personal-access-token) scoped for `read:packages` and verify the permissions:
156
-
```console
157
-
$ gh auth login --scopes read:packages
158
-
159
-
? What account do you want to log into? GitHub.com
160
-
? What is your preferred protocol for Git operations? HTTPS
161
-
? How would you like to authenticate GitHub CLI? Login with a web browser
162
-
163
-
! First copy your one-time code: ****-****
164
-
Press Enter to open github.com in your browser...
165
-
166
-
✓ Authentication complete.
167
-
- gh config set -h github.com git_protocol https
168
-
✓ Configured git protocol
169
-
✓ Logged in as ********
170
-
```
171
-
172
-
```console
173
-
$ gh auth status
174
-
175
-
github.com
176
-
✓ Logged in to github.com as ******** (~/.config/gh/hosts.yml)
177
-
✓ Git operations for github.com configured to use https protocol.
0 commit comments