RELEASE: Move some BYOS steps to be standard #3107
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
|
|
||
| 1. Add the provider to the `PROVIDERS` list. | ||
|
|
||
| * Add the name of the provider to the PROVIDERS list. |
There was a problem hiding this comment.
Question: Is the idea to create a sublist? Then this content should get an extra indentation.
| * Add the name of the provider to the PROVIDERS list. | |
| * Add the name of the provider to the PROVIDERS list. |
{width=750px}
There was a problem hiding this comment.
The two lines are a duplicate. i've removed one.
documentation/writing-providers.md
Outdated
| @@ -317,6 +368,7 @@ These are the things we'll be checking when you submit the PR. Please try to co | |||
| 5. Re-run the [integration test](#step-7-integration-test) one last time. | |||
| * Post the results as a comment to your PR. | |||
| 6. Re-read the [maintainer's responsibilities](providers.md#providers-with-contributor-support) bullet list. By submitting a provider you agree to maintain it, respond to bugs, periodically re-run the integration test to verify nothing has broken, and if we don't hear from you for 2 months we may disable the provider. | |||
| 7. [Create an issue (feature request)](https://github.com/StackExchange/dnscontrol/issues/new?title=Add%20label%20for%20PROVIDERNAME) with the text "Please create the GitHub label 'provider-PROVIDERNAME'". | |||
There was a problem hiding this comment.
Idea: Is it an idea to put this more as a checklist for us? Also in a review I feel the need to be able to tick off a checklist.
There was a problem hiding this comment.
It might make more sense to include the (create the GitHub label 'provider-PROVIDERNAME') request in the original GitHub pull request.
There was a problem hiding this comment.
My philosophy is that if someone's work is going to be judged using a rubric, they should know what the rubric is ahead of time. This helps them get everything right on the first try.
I've moved the label request to the PR. Good idea!
Co-authored-by: Jeffrey Cafferata <jeffrey@jcid.nl>
Co-authored-by: Jeffrey Cafferata <jeffrey@jcid.nl>
Co-authored-by: Jeffrey Cafferata <jeffrey@jcid.nl>
|
@tlimoncelli, can you let me know when I can do a review? 🤓 |
Co-authored-by: Jeffrey Cafferata <jeffrey@jcid.nl>
|
|
||
| 1. Add the provider to the `PROVIDERS` list. | ||
|
|
||
| * Add the name of the provider to the PROVIDERS list. |
There was a problem hiding this comment.
The two lines are a duplicate. i've removed one.
documentation/writing-providers.md
Outdated
| @@ -317,6 +368,7 @@ These are the things we'll be checking when you submit the PR. Please try to co | |||
| 5. Re-run the [integration test](#step-7-integration-test) one last time. | |||
| * Post the results as a comment to your PR. | |||
| 6. Re-read the [maintainer's responsibilities](providers.md#providers-with-contributor-support) bullet list. By submitting a provider you agree to maintain it, respond to bugs, periodically re-run the integration test to verify nothing has broken, and if we don't hear from you for 2 months we may disable the provider. | |||
| 7. [Create an issue (feature request)](https://github.com/StackExchange/dnscontrol/issues/new?title=Add%20label%20for%20PROVIDERNAME) with the text "Please create the GitHub label 'provider-PROVIDERNAME'". | |||
There was a problem hiding this comment.
My philosophy is that if someone's work is going to be judged using a rubric, they should know what the rubric is ahead of time. This helps them get everything right on the first try.
I've moved the label request to the PR. Good idea!
|
@cafferata PTAL |
No description provided.