Skip to content

4. Pull Requests

Jump to bottom
Surbhi-MSFT edited this page Jan 13, 2021 · 8 revisions
inputs and checklist illustration

Creating, reviewing, and refining docs for publication

A pull request is a collaboration method for contributors to request a review and receive an approval from appropriate stakeholders before changes to documents in the repository become final.

Microsoft Teams

  1. Teams has a two-step process for merging changes.
  2. A contributor must create a branch from the current master branch to make changes.
  3. After a document update or addition has been created, the contributor creates a Pull Request (PR) for review. The changes can be reviewed on the Teams review site. To review, select the branch where the changes have been made from the drop-down menu:

Note

Builds with Error and/or Warning messages are unacceptable and corrections must be made to return a passing Build. If a Builds returns Suggestion messages, check with the Teams Lead for the current policy.

Select branch menu

NOTE

Review sites are only available internally and cannot be accessed by parties outside of Microsoft.

  1. If the changes are approved the branch is merged into the master branch.
  2. If all checks pass, you must create a new PR comparing the master -> to the -> Live branch.
  3. If all checks pass, you can merge the live sub-branch for publication on the Live public site.

NOTE

Impactful changes and updates to Teams Documentation are announced in the What's new for developers in Microsoft Teams Change Log page.

Microsoft Graph

  1. Guidance for Graph PRs is documented in the Graph Content Wiki.

  2. The minimum requirements for a PR to be approved for publication are as follows:

    ✔ Include docs for all the API changes/additions you're making, as specified by your updates to the metadata. For example, each entity, complex type, and applicable CRUD operation, action, and function must have its own topic.

    ✔ Author API reference content in topic structures consistent with guidance.

    ✔ All v1.0 API pages must have corresponding beta API pages.

    ✔ Expose API entry points as appropriate in the reference TOC.

    ✔ Include changelog items for API additions and updates, or any other updates that impact API behavior, such as adding a permission for an API.

    ✔ Address API Doctor warnings and errors in the content you updated in the PR.

Preparing for weekly shiproom.

Clone this wiki locally