Feature Updates

[RyanCavanaugh]

Feature Updates

We're starting a new initiative called Feature Updates.

For longstanding and highly-upvoted issues, we'll be dedicating time each milestone to address these issues and deliver an update on where the feature stands in our planning. My initial goal is to issue five-ish per milestone, though possibly more or fewer might happen due to other obligations or opportunities.

Long-open issues have many problems that need addressing:

• The community rightfully wants to know whether we intend to implement highly-upvoted issues, what potential blockers are, and what kind of feedback is needed
• Upvotes given at one point in time may have been from people whose needs have since been met by other features, or who no longer need the feature due to the shifting JS landscape
• The GitHub UI isn't particularly friendly when there are hundreds of comments, which is common
• Due to this and general human avoidance of reading long threads, many comments are duplicative or off-topic
• Even if we've posted long comments explaining the current state of things, they tend to get lost in the middle
• Many highly-voted issues actually describe a huge range of possible functionality, e.g. "Compiler Plugins" which could mean practically anything

The goals here are to:

• Collect scenarios and use cases, assess which have been met in the interim since the feature was first proposed, and which still make sense
• If necessary, split up the feature into sub-features for clarity
• "Start fresh" with new threads with fewer filler (e.g. "Me too!") comments
  • Feature Updates will be moderated more stringently; while we almost never delete comments elsewhere, in Feature Update threads, comments which don't contribute meaningfully to the presented problems will be deleted.
• Describe current solutions, why they're not part of TypeScript yet, and discuss possible next steps forward

Our request to you in Feature Update threads is to stay focused, since they will likely garner a lot of attention and potential for noise.

Examples of constructive feedback that would be greatly appreciated:

• Discussion of possible solutions to presented problems
• Code examples that demonstrate where the lack of the feature is painful
• Explanations of existing libraries with behavioral constraints that can't be represented without the feature
• Bugs that would have been found if you had the feature
• Opinions on presented options, preferably using the aforementioned framings

To keep thread size manageable, we'll be pruning (deleting) unconstructive comments that don't meaningfully contribute to progress. Examples of comments that may be less helpful and could potentially be removed:

• General observations like "This has been open for X years", etc.
  • We don't prioritize the design of the language solely based on when ideas were first conceived. TypeScript has been around for a while, and most ideas have been present in one form or another for a long time.
• Unspecific "I need this", "Me too", "This is a must-have", etc.
  • If we don't know why you need it or what you want to use it for, we can't make design progress in terms of making trade-offs, shipping a minimum viable implementation, considering alternative features which would accomplish the same thing, or predicting what kinds of feature interactions people might expect
• Comments that suggest obvious solutions: "Why not put it behind a flag", "Do it already", "Not hard, just do what Erlang does", etc.

Requesting Feature Updates

For the foreseeable future, we'll be working off the "most-upvoted" suggestion list. Please don't post comments in issues or iteration plans asking for feature updates. Once the top suggestions have been cleared out, we might change this policy, possibly by having a survey or something.

[RyanCavanaugh]

I'm going to unlock and just ask politely that people not request specific feature updates on certain issues and instead stick to meta-conversation.

Also I just realized what the acronym for it is; maybe someone can propose a better name? 😶

[xiBread]

Maybe add "News"/"Notes" or something of the like to the end so it's F.U.N? 😄

[Andarist]

One question: how can I help? 😉

[icecream17]

Perhaps "Feature Reloads" or "Feature Refreshes" a la https://github.com/Spiker985/x-terminal-reloaded

[x87]

I'm going to unlock and just ask politely that people not request specific feature updates on certain issues and instead stick to meta-conversation.

Also I just realized what the acronym for it is; maybe someone can propose a better name? 😶

RFC (example https://github.com/rust-lang/rfcs)

[danvk]

Very excited about this initiative and reading all the updates on these issues!

In case it's not obvious, you can see all the Feature Updates by clicking the "Feature Update" label.

I've found RSSHub helpful for turning these labels into RSS feeds. The Feature Update label is worth following, as is Design Notes:

• https://rsshub.app/github/issue/Microsoft/TypeScript/all/Feature%20Update
• https://rsshub.app/github/issue/Microsoft/TypeScript/all/Design%20Notes

[michaelKurowski]

This is a significant step forward. As an outsider, it was quite challenging to understand why certain issues had not been introduced and what are their chances to get accepted.

Now that each feature will be more formally organized and presented, perhaps you could consider defining a process for each feature to follow? Maybe you could consider introducing a tracker similar to the proposal system used by ECMAScript?