Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
This page describes how we track issues in the
Inbox tracking and Issue triage
New issues or pull requests submitted by the community are triaged by a team member. The team rotates the inbox tracker on a weekly basis. A bot assists the inbox tracker.
The Inbox query contains all the
- open issues or pull requests that
- are not feature requests nor test plan items nor plan items nor extension candidates and
- have no owner assignment.
The inbox tracker should do the following initial triage:
- Is the issue invalid? Close it and justify the reason.
- Is the issue a general question, like How can I compile TypeScript? Close it and redirect the user to Stack Overflow with this message.
- Is the issue best covered by an extension then add the
- Else, assign the issue to the owner of a feature area.
- Note: Assign JS/TS issues to @mjbvz
Everyone should do the following secondary triage to their assigned issues (the inbox tracker may do some of these steps too, if obvious):
- If an issue needs more info, assign the
needs more infolabel, add an assignee (yourself if still unknown) and ask for more information in a comment. (Adding a comment
/needsMoreInfolets the bot add the label and a generic comment asking for more info and a review of the issue guidelines.)
- Ensure that the issue has a type label, that is,
needs more info
- Ensure that the issue has a feature-area label and optionally a sub area, see Feature Areas.
- Do a best effort to identify duplicates
- If the issue is a feature-request then the initial owner optionally unassigns himself from the issue.
- If the issue is an important
bug, assign an
importantlabel and optionally mention @microsoft/vscode to get the attention of the entire team.
- If the issue needs to be fixed in this release, assign it to the current milestone (eg: blocks a scenario, completes a new feature, etc.).
- If needed, follow-up with the author.
- If the issue is a performance issue, use some of the questions, experiments and measurements collected in Performance Issues.
GitHub issue tracking tip
a to quickly edit labels and assignees.
See a complete list of GitHub shortcuts here. (Or try pressing
? when not focusing any input field on GitHub's UI)
Ongoing Issue Management
- Issues labelled with
needs more informationare automatically closed by the bot when no additional information is provided for 7 days.
- We close issues that we are not planning to work during the next 12 months. (Adding the
*out-of-scopelabel lets the bot close the issue and add a generic comment.)
Issues are classified into following types and the owner of the issues must make sure that the issues are assigned to one of these labels.
bug- the implementation of a feature has a defect in the logic and it does not work as designed. The defect in the logic is reproducible. The issue report documents these steps.
feature-request- request to change the proper implementation of a feature or a request for a new feature that needs to be implemented.
under-discussion- not decided whether the issue is a bug or feature
debt- improve the implementation/architecture
needs more info- not possible to assign a type label due to missing information
question- we should direct questions to SO
upstream- an issue used to track an issue in an upstream component
engineering- an issue used to track changes to the engineering areas
- others - All labels coloured grey (#dcdcdc)
During the iteration planning process we use the following sources as input:
- Review feature requests with many reactions. Issues we plan to work on during an iteration are assigned to the current milestone.
Filing bugs as a development team member
When team members files a bug they perform steps of the inbox tracker for the issue they filed. Therefore bugs filed by the development team do not need to be triaged by the inbox tracker.
Issues need to be verified.
Verification is a service that you request from others either implicitly with the
bug-label or explicitly with the
verification-needed-label. Find issue that are to be verified with these queries
- bugs to be verified, VS Code
- verification needed, VS Code
- bugs to be verified, all GitHub projects
- verification needed, all GitHub projects
Follow the these rules:
- Query for issues that are to be verified
- Start with issues you created (filter by
Author) but didn't close
- Pick an item
- Start with setting
verified-label (prevents duplicate verifications)
- Verify the issue
- If you cannot verify the issue due to missing or hard-to-understand repro steps, add a
verification-steps-neededlabel and remove the
- If the issue still shows, add the
verification-found-label and remove the
- Go back to #3
- Start with setting
Duplicate bugs are closed with a comment
duplicates #issue. Please try to reference an earlier issue unless a later issue is more appropriate (has more context, better scenarios, repro steps, etc.).
Debug type to extension mapping
Consistent labels across vscode repositories
Visual Studio Code consists of multiple repositories and we should use consistent work flows and labels across all our repositories.
To establish consistent labels across all our repositories use the Label Manager tool.
Consistent milestones across vscode repositories
To enable planning across repositories all the Visual Studio Code related repositories need to define the same milestones.
We use issues for iteration plans and the wiki for the test plan.
- Iteration Plans have a label
tasks[ ] for the different items. The individual items are tracked in existing issues (bugs, feature requests). If there is no existing issue then a new issue with the label
plan-itemis created. Here is an example.
- We use a wiki page for a test plan. Here is an example.