I wonder: how can we persuade the team to reconsider a long open issue?

Question

I wonder: how can we persuade the team to reconsider a long open issue?

Closed this issue 4 days ago · 3 comments

Acknowledgement

I acknowledge that issues using this template may be closed without further explanation at the maintainer's discretion.

Comment

Introduction

It is very frustrating when we encounter a problem and call for help here, only to find an issue already reported many years ago with no sign of being resolved.

More frustrating when we don't see any good way to draw the team members to come and discuss with patience, let alone persuade them.

An example

A perfect example that prompted me to write this is issue #16665: "Include Default Parameter Values in Signature Help".

It was created in 2017 and has been neglected for eight years.

In September of this year, a team member "RyanCavanaugh" finally gave a lengthy response reasoning why they are very, very reluctant.

That issue is not closed, but seems totally dead.

Difference

People like me just want a very small, probably quite easy, improvement.

But team members like RyanCavanaugh apparently believe this improvement will be inevitably extended and enlarged into a daunting pitfall.

Some comments have pointed out the difference. But there's been no further reply.

Rejection

Please Note: The crux of the matter is no longer technical.

The most desperate thing is:

Even if anyone can solve that issue (just the small improvement we ask for), their PR will be deliberately rejected.

Because the team does not want to start a possible chain reaction of following needs which they hate to work on.

Self-contradictory

Their logic is quite weird:

They have abundant mental strength, organizational steadiness, whatsoever to disregard a reasonable request for so many years, but they won't have these to face possible requests (some of which are unlikely, or at least would be easy to dismiss) in the future?

"I deny you because I'm afraid of denying"?

Dilemma

I wanted to argue with RyanCavanaugh loudly. But on second thought, I guess it won't help at all.

If I am too soft, my comment will be simply ignored, just as the ones before me.
If I am too hard, RyanCavanaugh may be irritated and even close the issue for good.

A sense of powerlessness

TypeScript is free. We don't pay the team.

If a small proportion of us stop using TypeScript due to dissatisfaction (which is not very likely for professionals), the team would hardly feel any bit of loss.

How can such a team keep listening to the voice of users, collect adequate information before making decisions, and allow more discussions over some old judgements in case they might be changed?

Don't get me wrong:
The TypeScript team has done excellent work. I have no doubt that they can discover important demands and endeavor to push the frontiers.

And of course they are not obliged to accept all requests with infinite patience and effort.

However, when needs are not so easily recognized as worthwhile by all people, some issues might get neglect, indifference or illogic...

TypeScript is a great tool, being used by countless developers. Even an seemingly minor issue can affect many people.

We don't want to be too importuning. But we cannot just turn away when our issues are rejected in such ways which feel like raw deals.

How can we carry on with the arguments, trying to change the team's mind?

Questions

I wonder:

if one member's opinion truly represents the team's consensus.
if there are other members who may be relevant but have not noticed the issue yet.
if there is a "referee" who is not a "player", so that they can evaluate issues impartially, without direct stress from the burden of work.
how to demonstrate that an issue adversely affects considerable users and how to prove it is worth considering with moderate seriousness.
how to motivate someone who has essentially told us they don't like troubles while we are unable to offer any substantial incentive.

Answer 1 · 2025-11-03T05:17:44.000Z

It's perhaps worth explaining that most of the comments I'm posting here (in terms of product direction) are the results of discussions with several other members of the team if not the entire team, and I'm relaying information that is a combination of multiple people's opinions, not even necessarily my own but rather the current best approximation of consensus.

Singling me out because I'm the person trafficking information back from these discussions isn't particularly helpful; you will get the same answer on all of these from Anders, or any arbitrary third party whose job was to relay the results of a conversation as to the suitability of a particular feature request.

Answer 2 · 2025-11-03T05:39:00.000Z

I wrote this at another time but didn't bother posting it, but saved it. What you're talking about in the linked issues is the problem we whenever there's strong demand to ship a half-baked feature, e.g. one that only works in some scenarios, but not all scenarios (under some reasonable definition of "all"). This is from learned experience.

For every person who says, before the feature exists, "It's fine to just implement this as a nice-to-have", another person shows up later to say "You shouldn't ship half-baked features, they need to either work in 100.0% of all scenarios or not exist at all, this is literally broken".

A few recent case studies that come to mind:

Auto-import
- Theory: It can usually save you from having to write an import, if not, no big deal, people can just write it themselves
- Reality: You need to enumerate all export maps of all dependencies listed in package.json (including, maybe, devDependencies, even though this doesn't make sense) (and including, maybe, transitive dependencies, even though that doesn't make sense either), map their wildcards into the file system, then sort and filter those paths (both input and output specifiers) according to user preferences so that all conceivable imports a user could legally write are always offered in all contexts.
- The preference space for import paths is enormous, and we have to manage a large configuration space as a result, needing to reason about this in the context of any new module behavior that might be considered
- The performance characteristics of this are of course terrible, so you need an additional layer of heuristics to avoid hanging the ts server process, plus another user preference to disable the "don't melt the battery" heuristics, which in turn leads to requests that there be an out-of-band notification system for informing users when we decided to not melt their batteries, which in turn would probably call for an opt-out mechanism to not get the notification
- Despite all these constraints, auto-import not working is considered a Pri 0 event, not a "nice to have"
- Maintaining this feature was someone's full-time job for over two years
Rewrite relative import specifiers
- Theory: If this works it works, if it doesn't you're not worse off
- Reality: No, you need an additional configuration layer to configure exactly which (which kinds?) of relative imports get rewritten
noUncheckedIndexedAccess
- We said this will be not a super great feature because it's really a half-baked version of what it could be
- Theory: "I think a lot of people would prefer the compiler to be strict with some needed assertions than to be loose with uncaught bugs."(#13778 (comment)) .... "Why can't we just keep it simple and not add any magic behaviour around old-style for loops at all"
- Reality: #61388, #57794, #42471, #54241, #52842, #51582, #41848, #47998, #38000, #53678, #54055, #41638, #41711, #41872, #42330, #42622, #42909 relate to the fact that noUncheckedIndexedAccess isn't 'smart' enough, and the list grows ~weekly. Should improving this be our top priority? I don't know; probably not. I'm sure there's someone that wants to discuss this with us until we change our mind and deprioritize something else; this is true for basically all suggestions.

So yeah, generally if a feature:

Has a reasonable workaround (e.g. prose in JS doc)
Implies a possibly large amount of future work (as described in the comment)
Is not strongly aligned with an existing important goal (correctness checking, perf, etc)

Then it's going to get rejected or at least stalled. This is basic project management, and every successful open source project is doing this to one degree or another. There's no methodology by which we're going to allow ourselves to get filibustered into doing something that isn't currently the right fit for the project. You have to ask yourself "what if two people could do the thing that reprioritizes a feature to the top of the queue?"

This (default values in signature help) is something that I do want to revisit when TS7 gets in better shape but you do need to be able to take "not right now" for an answer if you want to be engaged with the direction of the project, because that is going to be the answer 95%+ of the time. "When can we have X" is a question that we get regarding a thousand different values of X, only a few dozen of which we can reasonably handle simultaneously.

Answer 3 · 2025-11-04T07:10:25.000Z

@RyanCavanaugh Thank you for the quick and elaborate response!

What worries and frustrates me is not disagreements themselves in issues but is lack of a proper close based on adequate communication for mutual knowledge.

My old questions

Let me look over my five questions:

1. if one member's opinion truly represents the team's consensus.

My apologies!

I'm rather new here. Only just now I checked your title: "Development lead for the TypeScript team at Microsoft".

Oh, that can be enough as an answer.

If I had done the checking before, I would not have asked this question.

2. if there are other members who may be relevant but have not noticed the issue yet.

This question probably can be answered as the first one.

However, I still wonder: Is your team a large one? If so, how do your team make sure an issue can be seen and discussed by relevant members?

Github doesn't seem to have a "which team members have read which issues" feature. Only when a member has left a comment can we be sure they have read and thought over.

Maybe your team also use another system to track the activities of members which are not visible in GitHub?

3. if there is a "referee" who is not a "player", so that they can evaluate issues impartially, without direct stress from the burden of work.

Maybe you are?

Anyway, this question is not important compared wtih the deep problem emerged in your second reply.

4. how to demonstrate that an issue adversely affects considerable users and how to prove it is worth considering with moderate seriousness.

This a key one. But let's discuss it in another issue.

5. how to motivate someone who has essentially told us they don't like troubles while we are unable to offer any substantial incentive.

Well, similar to Question 3, this one is not important.

My new questions and thoughts

There is room to improve the feedback to the people who are waiting, if not have left with confusion, dejection or anger.
The specific policy behind #16665 explained in your second reply, is a result of the dilemma of your team as "a pig in the middle" between different groups of users.

Your hardworking team deserves better.
And users with more reasonable, modest requests deserve better.

The situation needs to be addressed.

I will write about the two topics respectively soon.

This issue as an initial discussion has served its purpose and can be closed.