Contributor Onboarding Agreement
See Issue ID tracking: https://github.com/GoogleCloudPlatform/pubsec-declarative-toolkit/issues/716
- Note: 20231125 - this is a collaborative creation of the COA with the entire PDT team - being edited on the fly for the remainder of 2023
- TBD - procedures for repo contributors to follow when working with the public repository code
- TBD - legal review for Day 2 support text
- Have a github issue ID ready and link to it from the PR - describing the units of work for multi-PR work items
- Add the entire team for review discussion, visibility and coverage. An example is here https://github.com/GoogleCloudPlatform/pubsec-declarative-toolkit/pull/636
- Try not to merge the PR as soon as the minimum 2 reviewers have approved the PR - leave it open enough for several of the reviewers to comment on the PR
- Try to test the PR on a running landing zone and optionally for specific cases on a new landing zone optionally in a clean GCP organization
- For script changes both in the sh/bash scripts and snippets of scripts in readme.md files - fully test out the script to avoid runtime/syntax errors
- Optionally post some evidence of script execution and LZ deployment (we are still pending a full pipeline CD deployment)
- Add commit links to other PRs' and issues. Issue ids in the text and header like "description - #568 " above in PR 636 via the commits in the PRs
- For PRs that you would like to keep un-merged beyond the minimum 2 approvals - maybe due to a larger community review - put a comment like the following in the PR to not automatically merge it once 2 approvals come in
- - "please keep this PR unmerged for the next 24 to allow for broader review"
- The strict linting is a bit of an issue - you can add the same actions to your fork if required but usually I just fix them during the PR. I find keeping the PR as a draft until you have resolved all LINT rules can be better - then when you flip your PR it is ready to be reviewed/merged