- 
                Notifications
    You must be signed in to change notification settings 
- Fork 13.1k
Triage Instructions
        Ryan Cavanaugh edited this page May 24, 2017 
        ·
        3 revisions
      
    The highest priority is getting unlabeled bugs to zero.
Most issues have pretty bad titles, hindering future searches. If needed, edit the issue title to align better with the Preferred Issue Titles format.
If you can't figure out from the issue report what the title should be, then you'll definitely need clarification from the user (see "Needs More Info" below).
Classify the bug accordingly:
- Duplicate: Many issues are duplicates, so try to find an original
- If you do, add the Duplicatelabel and add a comment e.g. "See #1234567"
- If it's clearly an exact duplicate, Close
- Optional: If the user would have found this with a trivial search (e.g. searching for the title of their own bug), gently remind them to search before logging new issues
 
- If you do, add the 
- Legitimate bug (crash, incorrect behavior, etc.): Add the Buglabel- Optionally add High Priorityif it's an easy-to-hit crash or incorrect emit
- Optionally add one of the Domain:labels if you'd like to
 
- Optionally add 
- Suggestion
- Add SuggestionandIn Discussionif this is something that can be looked at immediately
- Add Suggestion,Out of Scope, and close if the suggestion is not something we would ever do (change JS runtime semantics, emit Python, switch to Haskell's type system, etc). Add a comment pointing to the Design Goals Wiki page
- Add Suggestion,Needs Proposalif something requiring a more formal description is required. Add a comment indicating what's needed
 
- Add 
- Question (the user is explicitly asking for help)
- Add the Questionlabel
- Provide an answer if it's easy for you to do so, otherwise point them at Stack Overflow and remind that the issue tracker is not a support forum
- Close the bug if it's egregiously out of scope (e.g. asking for help getting Angular2 working or whatever)
- If the question is about the compiler API and you can't answer it immediately, assign to a dev
 
- Add the 
- Not a bug
- Add Working as Intendedif the behavior is truly done on purpose, orDesign Limitationif it's something we would fix in a perfect world but are unable to do so
- Post a comment explaining why. Try to reference things from the FAQ if applicable; consider updating the FAQ if you think it's a common question
 
- Add 
- It's not clear what the issue is describing
- Add the Needs More Infolabel
- Add a comment explaining why the issue isn't actionable yet
 
- Add the 
- Issue is in external component (e.g. tslint, awesome-typescript-loader, etc)
- Add the Externallabel
- Explain why
 
- Add the 
- Completely useless
- If the issue is completely unsalvageable (e.g. it's just "Why can TypeScript not for C# now?" with no other info), add the Unactionablelabel and Close.
 
- If the issue is completely unsalvageable (e.g. it's just "Why can TypeScript not for C# now?" with no other info), add the 
- Fallback: Not sure
- Add "Needs Investigation" label
- Optional: Post comment with your thoughts (e.g. "Might be a type inference bug, need to investigate")
 
Once there are no new unlabeled bugs, start looking at issues which need investigation: Query: Bugs needing investigation
News
Debugging TypeScript
- Performance
- Performance-Tracing
- Debugging-Language-Service-in-VS-Code
- Getting-logs-from-TS-Server-in-VS-Code
- JavaScript-Language-Service-in-Visual-Studio
- Providing-Visual-Studio-Repro-Steps
Contributing to TypeScript
- Contributing to TypeScript
- TypeScript Design Goals
- Coding Guidelines
- Useful Links for TypeScript Issue Management
- Writing Good Design Proposals
- Compiler Repo Notes
- Deployment
Building Tools for TypeScript
- Architectural Overview
- Using the Compiler API
- Using the Language Service API
- Standalone Server (tsserver)
- TypeScript MSBuild In Depth
- Debugging Language Service in VS Code
- Writing a Language Service Plugin
- Docker Quickstart
FAQs
The Main Repo