Anax test branch #3273
Anax test branch #3273
Conversation
Signed-off-by: anaxceron <[email protected]>
Signed-off-by: anaxceron <[email protected]>
Signed-off-by: anaxceron <[email protected]>
Signed-off-by: anaxceron <[email protected]>
Signed-off-by: anaxceron <[email protected]>
Signed-off-by: anaxceron <[email protected]>
Signed-off-by: anaxceron <[email protected]>
Signed-off-by: anaxceron <[email protected]>
Signed-off-by: anaxceron <[email protected]>
Signed-off-by: anaxceron <[email protected]>
Signed-off-by: anaxceron <[email protected]>
Signed-off-by: anaxceron <[email protected]>
Signed-off-by: anaxceron <[email protected]>
Signed-off-by: anaxceron <[email protected]>
Signed-off-by: anaxceron <[email protected]>
Signed-off-by: anaxceron <[email protected]>
…we/docs-site into anax-v2.9-prinstructions-docs
Signed-off-by: anaxceron <[email protected]>
Signed-off-by: anaxceron <[email protected]>
Signed-off-by: anaxceron <[email protected]>
Signed-off-by: anaxceron <[email protected]>
Signed-off-by: anaxceron <[email protected]>
Signed-off-by: anaxceron <[email protected]>
Signed-off-by: anaxceron <[email protected]>
Signed-off-by: anaxceron <[email protected]>
Signed-off-by: anaxceron <[email protected]>
Signed-off-by: anaxceron <[email protected]>
Signed-off-by: anaxceron <[email protected]>
Signed-off-by: anaxceron <[email protected]>
Signed-off-by: anaxceron <[email protected]>
updating comment line breaks
Signed-off-by: anaxceron <[email protected]>
updating comments
Signed-off-by: Timothy Johnson <[email protected]>
anaxceron
added
the
area: docs
anaxceron
requested review from
janan07,
lparadkar-rocket,
nellietan and
samanthasusu
Signed-off-by: anaxceron <[email protected]>
.github/pr-comments/for-labeller.md
Outdated
|
|
||
| - [ ] Add the label `review: doc`. | ||
| - [ ] Identify your content topic with a label. (Examples: `area: apiml`, `area: cli`, `area: install and config`, etc.) | ||
| - [ ] Specify the major Zowe release for your content. (Examples: `release: V1`, `release: V2`, `release: V3`) |
There was a problem hiding this comment.
As discussed, for v3, it seems like a good idea to inform the PR opener to target the v3 branch. Glad we discussed this. ;-)
There was a problem hiding this comment.
These refactored instructions look much clearer than what we currently have. I still think it would be great to automate the reviewer list from the community to automatically add the list of doc squad members to sign off on it, but I understand that creating this automation creates extra work for our dev support, so I agree that this PR is good to merge now and perhaps we can add this functionality at some point in the future. Great job with this PR!
Signed-off-by: anaxceron <[email protected]>
Signed-off-by: anaxceron <[email protected]>
| - [ ] Link any [Doc Issues](https://github.com/zowe/docs-site/issues) related to this PR. | ||
| - [ ] Fix broken links found in your content areas. | ||
| - [ ] Notify the SME to review this PR (if applicable). | ||
| - [ ] Merge to the `master` branch if your PR updates content that is on the live site. Merge to `docs-staging` if your PR updates content for a future release. |
There was a problem hiding this comment.
I'm wondering if this point is necessary or could perhaps cause someone to open a PR against a different branch than that which was used as the base branch (e.g. someone opens a new branch against docs-staging, but then targets the master branch). Maybe it would be best to say to target the branch that was used to base your PR branch.
There was a problem hiding this comment.
@janan07 That would be the intent -- to remind folks that the live changes use the master branch and changes for the future use the docs-staging branch. So if their base branch doesn't align w/ this, then, yep, they'd need to change their branch to align w/ our branching strategy.
Introduces updated instructions for pull requests opened in the docs-site repository.
Instructions to have Zowe Docs content reviewed/published are provided based on the type of user that opens a pull request, and the labels the user adds to the pull request.
Instructions presented to TSC in November and subsequently updated after receiving feedback. These PR instructions have now been updated to be used by committers, contributors, and people who do not have the access to add labels to issues or PRs in this repo.