<p dir="auto"><em>[I still consider this somewhat incomplete, and I feel  the suggestions for 'Declined' (hardest one) are not varied enough, but I felt it was valuable enough to post. I also subtly changed my mind on some of these during the weeks since this was written, but within the time constraints I feel this is the best I could do]</em></p>
<p dir="auto">I've made my best to come up with alternative terms for the current labels. For inspiration I used the Roslyn, F#, Go and Rust issue trackers, and some originals of my own. The toughest one (by far) was <em>Declined</em> - It was so difficult I had to resort to <a href="https://english.stackexchange.com/questions/319695/concise-phrase-or-term-to-express-there-are-no-plans-to-address-or-implement-th" rel="nofollow">opening a question on the 'English language and usage' stack exchange</a>.</p>
<h2 dir="auto">Examples of current best alternative label sets through the various stages of an issue</h2>
<p dir="auto"><strong>Positive outcome :-)</strong></p>
<ol dir="auto">
<li><em>Feature Suggestion</em>, <em>Needs More Info</em></li>
<li><em>Feature Suggestion</em>, <em>Needs Specification</em></li>
<li><em>Feature Suggestion</em>, <em>Under Consideration</em></li>
<li><em>Feature Suggestion</em>, <em>Planned</em></li>
<li><em>Feature Suggestion</em>, <em>In Development</em></li>
<li><em>Feature Suggestion</em>, <em>Implemented</em></li>
</ol>
<p dir="auto"><strong>Negative outcome :-(</strong></p>
<ol dir="auto">
<li><em>Feature Suggestion</em>, <em>Needs More Info</em></li>
<li><em>Feature Suggestion</em>, <em>Needs Specification</em></li>
<li><em>Feature Suggestion</em>, <em>Under Consideration</em></li>
<li><em>Feature Suggestion</em>, <em>No Foreseeable Plans</em>, <em>Not Enough Value</em></li>
</ol>
<p dir="auto"><strong>Positive outcome :-)</strong></p>
<ol dir="auto">
<li><em>Enhancement Suggestion</em>, <em>Needs More Info</em></li>
<li><em>Enhancement Suggestion</em>, <em>Under Consideration</em></li>
<li><em>Enhancement Suggestion</em>, <em>Accepting Community Contributions</em></li>
<li><em>Enhancement Suggestion</em>, <em>Implemented</em></li>
</ol>
<p dir="auto"><strong>Negative outcome :-(</strong></p>
<ol dir="auto">
<li><em>Feature Request</em></li>
<li><em>Feature Request</em>, <em>Outside Design Goals</em>, <em>Auxiliary Tooling Candidate</em></li>
</ol>
<p dir="auto"><strong>Positive outcome :-)</strong></p>
<ol dir="auto">
<li><em>Bug Report</em></li>
<li><em>Bug Report</em>, <em>Confirmed</em></li>
<li><em>Bug Report</em>, <em>Confirmed</em>, <em>Fix Planned</em></li>
<li><em>Bug Report</em>, <em>Confirmed</em>, <em>Fixed</em></li>
</ol>
<p dir="auto"><strong>Negative outcome :-(</strong></p>
<ol dir="auto">
<li><em>Bug Report</em></li>
<li><em>Bug Report</em>, <em>Needs Further Investigation</em></li>
<li><em>Bug Report</em>, <em>External: Edge</em></li>
</ol>
<p dir="auto"><strong>Negative outcome :-(</strong></p>
<ol dir="auto">
<li><em>Enhancement Suggestion</em></li>
<li><em>Enhancement Suggestion</em>, <em>Needs More Detail</em></li>
<li><em>Enhancement Suggestion</em>, <em>No Foreseeable Plans</em>, <em>Taken As Information</em></li>
</ol>
<p dir="auto"><strong>Neutral outcome :-|</strong></p>
<ol dir="auto">
<li><em>Feature Suggestion</em></li>
<li><em>Feature Suggestion</em>, <em>Needs Specification</em></li>
<li><em>Feature Suggestion</em>, <em>Subsumed</em>, <em>Taken As Information</em></li>
</ol>
<h2 dir="auto">Initial stage</h2>
<ul dir="auto">
<li><em>Suggestion</em>:
<ul dir="auto">
<li>Intended meaning: "Any suggestion"</li>
<li>Problem: too broad, sometimes covers enhancements as well (which may also be seen as 'bugs' sometimes by the issuer), doesn't separate between "requests", "suggestions", and "specifications".</li>
<li>Suggestions: Split to possibly (or include as a secondary label)
<ul dir="auto">
<li><em>Feature Request</em></li>
<li><em>Feature Suggestion</em></li>
<li><em>Feature Specification</em></li>
<li><em>Implementation Proposal</em></li>
<li><em>Enhancement Request</em></li>
<li><em>Enhancement Suggestion</em></li>
</ul>
</li>
</ul>
</li>
<li><em>Bug</em>:
<ul dir="auto">
<li>Intended meaning: "Confirmed Bug"</li>
<li>Problem: No way to label an unconfirmed bug.</li>
<li>Suggestions:
<ul dir="auto">
<li><em>Bug Report</em>, followed by</li>
<li><em>Bug Report</em> and <em>Confirmed</em></li>
</ul>
</li>
</ul>
</li>
<li><em>Needs More Info</em>:
<ul dir="auto">
<li>Intended meaning: "The team needs more information about this suggestion or bug in order to understand what's going on. Generally, Suggestions will start out as Needs More Info, graduate to Needs Proposal, then finally go to In Discussion"</li>
<li>Problem: doesn't separate "more info" from "further investigation".</li>
<li>Suggestions: split to
<ul dir="auto">
<li><em>Needs More Info</em> or <em>Needs More Details</em></li>
<li><em>Needs Further Investigation</em> (for bugs)</li>
<li>and possibly <em>Under Investigation</em>.</li>
</ul>
</li>
</ul>
</li>
<li><em>Needs Proposal</em>:
<ul dir="auto">
<li>Intended meaning: "A suggestion that has a well-understood use case and a plausible outline of a solution, but lacks a formal definition of how exactly the problem will be solved".</li>
<li>Problem: may be read as "please write a complete, detailed, formal implementation proposal or else this will not be considered".</li>
<li>Suggestions: <em>Needs Specification</em>, <em>Requires Specification</em>.</li>
</ul>
</li>
</ul>
<h2 dir="auto">Review stage</h2>
<ul dir="auto">
<li><em>In Discussion</em>:
<ul dir="auto">
<li>Intended meaning: "The suggestion is ready to be discussed at a Design Meeting or Suggestion Backlog Slog".</li>
<li>Actual usage: includes suggestions that are continuously discussed for relatively long periods of time.</li>
<li>Problem: could be interpreted as just being just "discussed" or as a "community discussion" or debate about a problem (my initial interpretation).</li>
<li>Suggestions: <em>Under Consideration</em> (inspired by the <a href="https://developer.microsoft.com/en-us/microsoft-edge/platform/status/" rel="nofollow">Edge platform status</a> terminology), <em>Under Review</em>, <em>In Review</em>, <em>Candidate Proposal</em>, <em>Candidate Suggestion</em>.</li>
</ul>
</li>
<li><em>Revisit</em>:
<ul dir="auto">
<li>Intended meaning: "A suggestion or bug that can't be adequately addressed today, but will probably be able to be addressed in the future (e.g. we need to wait for the ECMAScript committee to make up its mind)"</li>
<li>Problem: could be interpreted as referring to an old suggestion being "revisited" in the sense of it being "reconsidered' or 're-examined' (my initial interpretation).</li>
<li>Suggestions: <em>For Future Review</em>, <em>For Future Consideration</em>.</li>
</ul>
</li>
</ul>
<h2 dir="auto">Outcome stage</h2>
<ul dir="auto">
<li><em>Committed</em>:
<ul dir="auto">
<li>Intended meaning: "Someone from the TypeScript team will fix this bug or implement this feature"</li>
<li>Problem: highly ambiguous with Git 'Commit', could be read as "Implemented" (which was my initial interpretation and I still suspect I was right.. :) ).</li>
<li>Suggestions: Split to
<ul dir="auto">
<li><em>Planned</em> (<em>Approved</em> may also fit in some cases), for bugs maybe <em>Fix Planned</em>.</li>
<li><em>In Development</em></li>
</ul>
</li>
</ul>
</li>
<li><em>Fixed</em>:
<ul dir="auto">
<li>Intended meaning: "Was a planned bug-fix or feature but now implemented"</li>
<li>Problem: frequently applied to feature requests or enhancements as well.</li>
<li>Suggestions: Split to
<ul dir="auto">
<li><em>Fixed</em> for bugs</li>
<li><em>Implemented</em> for features or enhancements (also, use <em>Implements #####</em> instead of <em>Fixes #####</em> in PRs to make it clear it is not actually a bug).</li>
<li><em>Addressed</em> could cover cases that don't fit either one of them, like correcting a mistake in the specification or documentation.</li>
</ul>
</li>
</ul>
</li>
<li><em>Accepting PRs</em>
<ul dir="auto">
<li>Intended meaning: "We are accepting pull requests to implement this feature or fix this bug."</li>
<li>Problem: Is not clear on whether this also include pull requests from Microsoft team members?</li>
<li>Problem: not everyone knows what a "PR" is (Public Relations?)..</li>
<li>Suggestions: keep as-is or <em>Accepting Pull Requests</em> (if it includes Microsoft members as well) or <em>Community Contributions Accepted</em> (if not).</li>
</ul>
</li>
<li><em>Declined</em>:
<ul dir="auto">
<li>Intended meaning: "For reasons explained in the issue, we are not going to accept this suggestion"</li>
<li>Actual usage: occasionally applied to ideas that are not really suggestions or specifications, or requests that were not originally presented as formal proposals.</li>
<li>Problems:
<ul dir="auto">
<li>Excessively highlights the 'act' of proposing, or the personal 'appeal' of the issuing person, rather the interest of the design team in the idea at hand.</li>
<li>Could be seen as inappropriate for suggestions that have valid use cases but did not provide a good-enough solution (or not at all) or wide-enough set of applications.</li>
<li>Could be unconditionally interpreted as "we think this suggestion is bad or exhibits poor design therefore we reject it".</li>
<li>Too 'final' and 'verdict-like'. Doesn't really leave enough room for future reconsideration.</li>
<li>Doesn't feel very 'friendly' and may create a somewhat harsh atmosphere.</li>
</ul>
</li>
<li>Suggestions (this was the toughest one by far): Split to:
<ul dir="auto">
<li><em>No Foreseeable Plans</em>: (or <em>No Prospective Plans</em>) for sound suggestions or proposals that have reasonable merit but for some reason were not deemed as appropriate or suitable for the language. This may be paired an additional label such as <em>Not Enough Value</em> or <em>Auxiliary Tooling Candidate</em>, described below.</li>
<li><em>Taken As Information</em>: for suggestions that had valuable content but did not provide a solution that was seen as conforming to high enough standards (thanks to the StackExchange member who suggested this).</li>
<li>... Other ideas...</li>
</ul>
</li>
<li>Other alternatives: <em>No Team Interest</em>, <em>No Team Approval</em>, or <em>No Team Consensus</em> for borderline ones (see the <a href="https://github.com/dotnet/roslyn/issues/2136" data-hovercard-type="issue" data-hovercard-url="/dotnet/roslyn/issues/2136/hovercard">C# 7 feature work list</a> for some inspiration.</li>
</ul>
</li>
<li><em>By Design</em>:
<ul dir="auto">
<li>Intended meaning: "This is an intentional behavior of TypeScript"</li>
<li>Actual usage, includes:
<ul dir="auto">
<li>Aspects of the language that were purposely designed with the belief they are good practices.</li>
<li>Design compromises or are known to be sub-optimal in some way.</li>
<li>Aspects that could have been done differently but are not possible or worthwhile to change due to it being a breaking change.</li>
<li>Aspects that are simply known to the designers, regardless of it being desirable or not, or being worthwhile to change or not.</li>
</ul>
</li>
<li>Suggestions: Split to
<ul dir="auto">
<li><em>Intended Behavior</em> and</li>
<li><em>Design Limitation</em> (other possible terms: <em>Design Constraint</em>, or <em>Design Compromise</em>.)</li>
</ul>
</li>
</ul>
</li>
<li><em>Out of Scope</em>:
<ul dir="auto">
<li>Intended meaning: "A suggestion that is outside the design parameters of TypeScript, either because it is a poor fit (e.g. make TypeScript look exactly like C#), is outside the constraints of the language (e.g. asm.js compilation), or better belongs to another tool or process (e.g. a built-in Collections library, or a runtime language feature that should start in the ECMAScript committee)".</li>
<li>Suggestions: Split to more specific cases:
<ul dir="auto">
<li><em>Outside Design Goals</em></li>
<li><em>Requires ECMAScript Approval</em>,</li>
<li><em>Auxiliary Tooling Candidate</em> (or <em>Third-party Tooling Candidate</em>)</li>
<li><em>Externally Scoped</em></li>
</ul>
</li>
</ul>
</li>
<li><em>Duplicate</em>:
<ul dir="auto">
<li>Intended meaning: "This issue is the same, or has the same root cause, as another issue."</li>
<li>Problem: sometimes applied to somewhat different suggestions or enhancements that solve mostly the same problem set, but are simply preferred one over the other.</li>
<li>Suggestions: split to:
<ul dir="auto">
<li><em>Duplicate</em> for exact duplicates.</li>
<li><em>Converged</em>, <em>Subsumed</em> or <em>Assimilated</em> for intersecting suggestions or enhancements.</li>
</ul>
</li>
</ul>
</li>
<li><em>Too Complex</em>:
<ul dir="auto">
<li>Intended meaning: "Relative to the complexity required to implement or understand it, the suggestion does not provide enough value."</li>
<li>Problem: could be read as "too difficult to implement" (my initial interpretation).</li>
<li>Suggestions: <em>Not Enough Value</em>, <em>Not Worthwhile</em>.</li>
</ul>
</li>
<li><em>Won't Fix</em>:
<ul dir="auto">
<li>Intended meaning: "While the behavior described is agreed to be incorrect, the cost (in time, complexity, performance, etc.) is too high to justify taking a fix relative to the cost of simply living with the bug"</li>
<li>Problem: may be perceived to demonstrate an un-constructive or un-friendly attitude..</li>
<li>Suggestions: <em>Not Enough Value</em>, <em>No Fix Planned</em>, <em>Not Enough Team Interest</em>, <em>No Foreseeable Plans</em>.</li>
</ul>
</li>
<li><em>External</em>:
<ul dir="auto">
<li>Intended meaning: "Catch-all bucket when an issue reported is not an issue with TypeScript, but rather an external tool, library, website, person, or situation".</li>
<li>Suggestions: leave as-is or consider extending the label to include the particular external entity referenced, e.g.:
<ul dir="auto">
<li><em>External: Internet Explorer</em></li>
<li><em>External: ECMAScript</em></li>
<li><em>External: VS Code</em></li>
<li><em>External: Node</em></li>
</ul>
</li>
</ul>
</li>
</ul>
<h2 dir="auto">Questions and discussions</h2>
<ul dir="auto">
<li><em>Question</em>:
<ul dir="auto">
<li>Intended meaning: "The issue is (intentionally or otherwise) simply asking a question about TypeScript. Answers to Questions, if provided, will generally be to-the-point because we do not have time to be a support community for all TypeScript users; please use Stack Overflow for TypeScript questions."</li>
<li>No alternative suggestions.</li>
</ul>
</li>
<li><em>Discussion</em>:
<ul dir="auto">
<li>Intended meaning "This issue is a discussion with no defined outcome. The TypeScript team may weigh in on these issues, but they are not regularly reviewed".</li>
<li>Problem: a bit vague, can be confused with <em>In Discussion</em>.</li>
<li>Suggestions: leave as-is and rename <em>In Discussion</em> (see suggestions below) or use <em>Community Discussion</em>.</li>
</ul>
</li>
<li><em>Canonical</em>:
<ul dir="auto">
<li>Intended meaning: "This issue contains a lengthy explanation of a common question or misconception".</li>
<li>Problem: unconventional usage of the term 'canonical' when applied to the issue itself. I'm not sure what the exact intention was but I believe it should mean 'recognized', 'well known', or alternatively 'authoritative'? (here's the <a href="http://www.thefreedictionary.com/Canonical" rel="nofollow">dictionary entry for 'canonical'</a>).</li>
<li>Suggestions: Use a combination of two separate labels: <em>Common Query</em> (or <em>Common Question</em>) and <em>Contains Reference Answer</em>.</li>
</ul>
</li>
</ul>
<h2 dir="auto">Misc and auxiliary labels</h2>
<ul dir="auto">
<li><em>Infrastructure</em>:
<ul dir="auto">
<li>Intended meaning: "Technical debt associated with the TypeScript project".</li>
<li>Problem: could be read as meaning to do with things like the JS runtime, Node runtime, Chakra/V8 engine etc (my initial interpretation).</li>
<li>Suggestions: <em>Technical Task</em>, <em>Technical Enhancement</em>, <em>Implementation Task</em>, <em>Implementation Enhancement</em>.</li>
</ul>
</li>
<li>Effort: Easy/Moderate/Difficult:
<ul dir="auto">
<li>Intended meaning: "For issues Accepting PRs, these are an approximation of how difficult we think fixing the bug or implementing the feature will be. As a rough guide, fixing typos or modifying lib.d.s are generally Easy; work that requires understanding the basics of the codebase is Moderate; things marked Difficult will require an understanding that is rare outside the core TypeScript team."</li>
<li>Problem: 'Effort' does not naturally refer to a level of difficulty.</li>
<li>Suggestions:
<ul dir="auto">
<li>Change to <em>Effort: Low/Moderate/High</em> or</li>
<li><em>Difficulty: Easy/Intermediate/High</em></li>
</ul>
</li>
</ul>
</li>
<li>High Priority:
<ul dir="auto">
<li>Intended meaning: "Issues affecting runtime behavior or high-occurrence crashes"</li>
<li>Suggestions: leave as-is or use a granular label for each priority level like:
<ul dir="auto">
<li><em>Priority: Low/Medium/High</em></li>
</ul>
</li>
</ul>
</li>
<li>ES6 / ES7 / ES Next:
<ul dir="auto">
<li>Intended meaning: "Refers to issues related to features found in these specific ECMAScript versions".</li>
<li>Suggestions: consider updating to newer terminology and using more literal labels like:
<ul dir="auto">
<li><em>Domain: ES2015/ES2016/ES2017</em></li>
</ul>
</li>
</ul>
</li>
</ul>
<p dir="auto"><em>Notes: Some of these may be used in a complementary way, together, or sometimes in addition to the existing label. Some are two or three word long, which may seem a bit excessive, but that seemed inevitable to successfully convey clearer semantics.</em></p>
<p dir="auto">Edit 2/29: Update proposal based on design changes; moved 'Solution' to top since most people viewing this are familiar with the problems</p>
<hr>
<h2 dir="auto">Solution</h2>
<p dir="auto">Support a "native UMD" declaration form that allows for a global var to be of the type of a module.</p>
<p dir="auto">A <em>global module export declaration</em> has the syntax:</p>
<div class="highlight highlight-source-ts notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="export as namespace id;"><pre class="notranslate"><span class="pl-k">export</span> <span class="pl-k">as</span> <span class="pl-k">namespace</span> <span class="pl-s1">id</span><span class="pl-kos">;</span></pre></div>
<p dir="auto">where <code class="notranslate">id</code> is any <em>Identifier</em>.</p>
<p dir="auto">This is only legal as a top-level declaration a <code class="notranslate">.d.ts</code> file containing other top-level <code class="notranslate">export</code> declarations (e.g. <code class="notranslate">export function</code>, <code class="notranslate">export var</code>, <code class="notranslate">export =</code>, etc.). Multiple of these declarations may appear in the same file so long as they supply different identifiers.</p>
<p dir="auto">When the containing file is imported through <code class="notranslate">import</code> syntax, the declaration has no effect.</p>
<p dir="auto">When the containing file is added to the compilation via a <code class="notranslate">/// &lt;reference</code> directive or by being a top-level file provided to the compiler (e.g. on the commandline, or as part of <code class="notranslate">tsconfig.json</code>'s <code class="notranslate">files</code> list), the supplied identifier[s] are added to the <em>global scope</em> of the program. The type of these identifiers is the type of the <em>module object</em> of the file in which they were declared.</p>
<p dir="auto">These declarations may engage in module merging, though this should probably be discouraged somehow.</p>
<h2 dir="auto">Example</h2>
<p dir="auto"><strong>my-lib.d.ts</strong></p>
<div class="highlight highlight-source-ts notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="export function doThing(): string;
export function doTheOtherThing(): void;

export as namespace myLib;"><pre class="notranslate"><span class="pl-k">export</span> <span class="pl-k">function</span> <span class="pl-s1">doThing</span><span class="pl-kos">(</span><span class="pl-kos">)</span>: <span class="pl-smi">string</span><span class="pl-kos">;</span>
<span class="pl-k">export</span> <span class="pl-k">function</span> <span class="pl-s1">doTheOtherThing</span><span class="pl-kos">(</span><span class="pl-kos">)</span>: <span class="pl-smi"><span class="pl-k">void</span></span><span class="pl-kos">;</span>

<span class="pl-k">export</span> <span class="pl-k">as</span> <span class="pl-k">namespace</span> <span class="pl-s1">myLib</span><span class="pl-kos">;</span></pre></div>
<p dir="auto"><strong>globalConsumer.ts</strong></p>
<div class="highlight highlight-source-ts notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="/// &lt;reference path=&quot;my-lib.d.ts&quot; /&gt;

myLib.doThing();"><pre class="notranslate"><span class="pl-c">/// &lt;reference path="my-lib.d.ts" /&gt;</span>

<span class="pl-s1">myLib</span><span class="pl-kos">.</span><span class="pl-en">doThing</span><span class="pl-kos">(</span><span class="pl-kos">)</span><span class="pl-kos">;</span></pre></div>
<p dir="auto"><strong>importConsumer.ts</strong></p>
<div class="highlight highlight-source-ts notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="import * as m from './myLib';
m.doTheOtherThing();"><pre class="notranslate"><span class="pl-k">import</span> <span class="pl-c1">*</span> <span class="pl-k">as</span> <span class="pl-s1">m</span> <span class="pl-k">from</span> <span class="pl-s">'./myLib'</span><span class="pl-kos">;</span>
<span class="pl-s1">m</span><span class="pl-kos">.</span><span class="pl-en">doTheOtherThing</span><span class="pl-kos">(</span><span class="pl-kos">)</span><span class="pl-kos">;</span></pre></div>
<h2 dir="auto">Problem</h2>
<p dir="auto">Many definition flies are written like this:</p>
<div class="highlight highlight-source-ts notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="declare var Promise: {
  // some stuff here
}
declare module 'bluebird' {
    export = Promise;
}"><pre class="notranslate"><span class="pl-k">declare</span> <span class="pl-k">var</span> <span class="pl-smi">Promise</span>: <span class="pl-kos">{</span>
  <span class="pl-c">// some stuff here</span>
<span class="pl-kos">}</span>
<span class="pl-k">declare</span> module <span class="pl-s">'bluebird'</span> <span class="pl-kos">{</span>
    <span class="pl-k">export</span> <span class="pl-c1">=</span> <span class="pl-smi">Promise</span><span class="pl-kos">;</span>
<span class="pl-kos">}</span></pre></div>
<h2 dir="auto">Symptoms</h2>
<p dir="auto">This is bad for three reasons:</p>
<ol dir="auto">
<li>We can't find this file from normal module resolution, so it has to get into the compilation context through a 'reference' mechanism</li>
<li>This pattern can't handle the case where you have two versions of <code class="notranslate">'bluebird'</code> because there is no path with which to disambiguate</li>
<li>People who are using the module version still get global scope pollution and might accidently use the global names when they meant to use an import name</li>
</ol>
<h2 dir="auto">Root Cause</h2>
<p dir="auto">The <em>reason</em> people do this (define globals, then <code class="notranslate">export =</code> from an ambient module declaration) is that the *reverse * (define a module, then declare a var with that module's type) is impossible.</p>