PR and issue management

Pull requests

PRs are reviewed at least weekly. We currently don't get a large number of PRs, so the review process is not automated. Simply look at the list of active PRs, merge what's ready, and leave feedback where changes are needed. If any changes require a broader design discussion, feel free to loop in others from the team.

PRs opened by external contributors will not run the Azure Pipelines build by default, but a successful Azure Pipelines run is required to merge. To run Azure Pipelines, leave a comment on the PR with the text /azp run. The commenter must have write access to the repository for this to trigger a run.

When merging PRs, label related issues with the fixed-pending-release label and and leave comments explaining that a fix for the issue will be included in the next release of the extension. If you want additional testing of the fix, include a link to the VSIX produced by the CI builds. Automation will automatically close fixed-pending-release issues the next time a release is tagged.

Issues

Issues are triaged at least weekly following this workflow. The goal is to keep the list of active issues short, actionable, and easy to query.

1. Query for all issues with the investigating label. These are existing issues that have enough information from the creator and now require investigation from maintainers.
   • If you have time to investigate and discover that more information is required from the creator, remove the investigating label, add the needs-more-info label and follow the steps below.
   • If you have time to investigate and are able to fix the issue, open a PR with the fix and leave a comment on the issue with a PR link.
   • If you don't have time to investigate, leave the issue alone.
2. Query for all issues with the needs-more-info label. These are existing issues that require more information from the creator to be actionable.
   • If the creator has responded to the request for information, remove the needs-more-info label and follow the triage process in step 2.
   • If the creator has not responded, leave the issue as-is. Automation will eventually close the issue if there is no response.
3. Query for all issues with the triage label. These are new issues that have not yet been triaged.
   • If the issue is a duplicate, has already been fixed, or will never be actionable or fixed, close the issue and leave a comment explaining why it was closed.
   • If the issue is not actionable because it's missing details like repro steps, ask the creator for the relevant details, remove the triage label, and add the needs-more-info label.
   • If the issue is actionable, simply remove the triage label. If there is additional context that would be helpful for the creator, like a workaround or related issue, feel free to leave a comment.

A few bits of automation powered by GitHub Actions help support this workflow.

• Every time an issue is opened, the triage label is added to the issue.
• Every time an issue is closed, the triage and needs-more-info labels, if present, are removed.
• Issues with the needs-more-info label are evaluated hourly for staleness. If the issue has been inactive for 30 days, a reminder comment is added and the stale label is added. If the issue is inactive for another 7 days, a closed comment is added, the issue is closed, and the stale label is removed.
• Issues with the fixed-pending-release label are closed when a release tag is pushed. A comment is added explaining that the fix is now available on in the extension marketplace.