-
Notifications
You must be signed in to change notification settings - Fork 29.4k
Issue Tracking
This page describes how we track issues in the vscode
repository.
- Global Inbox
- Bugs to be Verified - VS Code only
- Verification Needed - VS Code only
New issues or pull requests submitted by the community are initially triaged by an automatic classification bot. Issues that the bot does not correctly triage are then triaged by a team member. The team rotates the inbox tracker on a weekly basis.
A mirror of the VS Code issue stream is available with details about how the bot classifies issues, including feature-area classifications and confidence ratings. Per-category confidence thresholds and feature-area ownership data is maintained in .github/classifier.json.
💡 The bot is being run through a GitHub action that runs every 30 minutes. Give the bot the opportunity to classify an issue before doing it manually.
The inbox tracker is responsible for the global inbox containing all open issues and pull requests that
- are neither feature requests nor test plan items nor plan items and
- have no owner assignment.
The inbox tracker may perform any step described in our issue triaging documentation but its main responsibility is to route issues to the actual feature area owner. If you're not sure who to assign, try looking at the working areas document.
Feature area owners track the feature area inbox containing all open issues and pull requests that
- are personally assigned to them and are not assigned to any milestone
- are labeled with their feature area label and are not assigned to any milestone. This secondary triage may involve any of the steps described in our issue triaging documentation and results in a fully triaged or closed issue.
💡 Use the bot commands (like /needsMoreInfo
, /extCpp
, etc) to your advantage. They offer a wide range of canned responses from needing more info, to closing as a result of specific extensions.
💡 The github triage extension can be used to assist with triaging — it provides a "Command Palette"-style list of triaging actions like assignment, labeling, and triggers for various bot actions.
💡 The inbox notebook can also assist with triaging.
The details can be found in our issue triaging documentation.
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.
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 global 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-needed
label and remove theverified
label - If the issue still shows, add the
verification-found
-label and remove theverified
label - Go back to #3
- Start with setting
In some cases, such as when a bug is particularly hard or time-consuming to reproduce, it can be desirable to allow the initial, community member, author of the bug report to verify an issue. This can be achieved by adding the author-verification-requested
label, which launches a workflow where the author is be pinged when the relevant patch is released, and then asked to verify the issues themselves.
Issues must be closed with a reference to a commit SHA in order for the bot to accurately ping users when the Insiders release with their fix is released.
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.
To enable planning across repositories all the Visual Studio Code related repositories need to define the same milestones.
We use issues for iteration plans. Iteration plans have a label iteration-plan
with 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-item
is created. All our iteration plans can be found here
Project Management
- Roadmap
- Iteration Plans
- Development Process
- Issue Tracking
- Build Champion
- Release Process
- Running the Endgame
- Related Projects
Contributing
- How to Contribute
- Submitting Bugs and Suggestions
- Feedback Channels
- Source Code Organization
- Coding Guidelines
- Testing
- Dealing with Test Flakiness
- Contributor License Agreement
- Extension API Guidelines
- Accessibility Guidelines
Documentation