Suggestion for improving language suggestion triage process and community involvement

[YairHalberstadt]

Problem

At the moment there is a huge backlog of issues (over 1500) and it's impossible for anyone to go over them all. Many of these issues are low quality and will probably never be actioned, but others often provide valuable ideas which are worth investigating further.

The members of the LDC can't look at all the open issues. What this means is that if they happen to look at it whilst its fresh (@333fred and @CyrusNajmabadi often do, but not all members of the LDC have the time to invest in this) it may get championed. Otherwise it will lie dormant unless an LDC member happens to think up the idea on his own and search for the issue.

This means that even though csharplang has an open platform where anyone can suggest their ideas, it often feels like anyone outside the LDC can't have much of an impact this way.

The story so far

The LDC is well aware of this issue, and have taken a first step towards solving it: they want all suggestions that are not complete enough to create a concrete detailed proposal to be opened as discussions. Then the number of issues will hopefully be small enough to triage all new issues in a reasonable timeframe.

This raises 2 further isssues:

1. Most people don't have suitable experience and knowledge of the language ins and outs to write formal proposals. How do we move the best of the large number of discussions towards a formal proposal for the LDM to triage?
2. Many people will raise issues instead of discussions but of low quality. How do we make sure that these don't bury the higher quality issues?

Suggested solution

The first step I think is to move all existing issues to discussions, thus cleaning the backlog. The minority that are issue worthy will be moved back to issues as they are noticed.

The next step is to get the community involved more to help with some of these administration issues. There are a number of community members who regularly contribute to csharplang and definitely have the capacity to judge if an issues should be a discussion, and vice versa. They should be given move permissions, to make sure that that discussions from the backlog get moved to issues as necessary, and low quality issues are moved to discussions.

The same community members should also be responsible for working with those discussions they are interested in, and getting them to the level of a formal proposal which they then open as an issue. In return for the effort they invest, the LDC will make sure to triage issues they open.

Of course this position doesn't have to be formal - people could already do this today. However I think making this an official position has a further advantage: by giving a certain amount of privilege in C# language design to people who are not from Microsoft, it makes the whole language design process feel more open and collaborative, whilst still maintaining the LDC's complete control over what actually gets accepted and what not.

cc @333fred

[leandromoh]

Most people don't have suitable experience and knowledge of the language ins and outs to write formal proposals.

How can we improve this? Some documentation or guideline?

[YairHalberstadt]

I think it's something that needs to be practiced for a start. Some good examples could definitely be included in the issue template.

[MgSam]

I don't agree that Issues vs Discussions is a good way to differentiate which things the LDC should review.

As you say, most people do not have the expertise to write formal language proposals, but I'd argue even further that most people shouldn't be writing formal language proposals. IMO language design via informal discussions is a far more effective way to garner feedback and gauge people's opinions than prescribing some specific syntax that then inevitably evolves into bike-shedding.

Put another way, we, the C# users, should be providing user requirements. It's the LDM's job to turn those user requirements into concrete syntax, compiler implementation, and runtime features. Given that, I don't think there should be any specific gate on what the LDC should be willing to look at in Github vs not look at. Yes, a small handful of the community want to assist with the making of sausage but that shouldn't be the community's primary role.

I do agree there needs to be some moderation. There are a huge number of duplicate issues, most of which never get closed unless the feature eventually gets championed. Microsoft clearly isn't willing to do this so I agree they should appoint some community moderators.

[HaloFour]

I think the term "formal proposal" needs to be quantified. I accept that it can (and will) evolve over time, but we need to know what that minimum bar would be for a feature to be considered and what any community contributions should look like.

IMO, it's a question of clarity. A "proposal" should clearly identify a problem and a way through which that problem might be solved. That could include proposed syntax with an explanation as to what that syntax does and how it works with existing syntax. But something like a specification fragment I think is way too far. That is what the LDG should be doing, and will be doing. Any proposal that gets that far into the details is likely to pigeonhole itself and either be unusable or get shredded to pieces regardless of how much community assistance is provided. And I think without some indication of interest by the LDG there's little reason for the community to spend this time and effort to come up with something formal. You guys could spend months coming up with all of the exact specifications to support optional semicolons and it'll likely still be dead-on-arrival.

Ultimately the problem that the LDG faces with this repo (and every repo that came before it) is that they don't periodically triage the backlog sufficiently. They do this infrequently for a tiny subset of proposals, but it's effectively sweeping back the sea. Most of the remaining proposals sit in perpetual limbo between not-good-enough-to-be-championed and not-bad-enough-to-be-outright-rejected. And I'd argue that a good percentage of those issues are not in a bad state. They might not be formally baked to the extent that they could be merged directly into the specification, but they're clear enough in intent to be debated. Short of process of continual and rapid triage I don't see how this situation will change. The issues will accrete until there are too many and either they all get moved or the team changes venues again.

What I think might be more helpful is a framework through which these issues can be triaged and the result of that triage communicated clearly to the community. Every member of the LDG can vote on a scale from -2 to 2 (no zeroes!) and if an issue can't break zero it can be closed or tossed back onto the heap. Issues with a low positive score can be punted to the community to develop further. Issues with a high positive score should theoretically be championed. It's not perfect and it puts a lot of onus on the LDG, but as the ultimate gatekeepers of the language I think that's where the onus belongs.

[yaakov-h]

My 2c from the peanut gallery:

Given that the LDG seem to be severely resource-constrained such that there is no way they can possibly keep up with this repo or its backlog, I think it would make sense to have some kind of pre-LDG review/triage board whose purpose is to provide some basic vetting, triage, and aggregation/deduplication such that by the time any proposal reaches the LDG, it is in pretty good shape and is not just wasting their time.

If the community can present anything from "here is a well-written proposal with precisely specified changes and a community-contributed PR" down to "here are about 50 different issues that have the same pain point and something should probably be done in this area but goodness knows what" - as long as these meet some basic quality control standards - then I feel the LDG would be much better equipped to triage and debate the outstanding issues, rather than just having the backlog grow indefinitely and having duplicates pile up over time.

The downside is that this could act as a form of unwanted gatekeeping.

[huoyaoyuan]

Currently the biggest community contribution should be marking duplications/finding alternative design that covers the usage.

Like other language design communities, we should have an entry for proposals sorted by votes too.

[alrz]

that sounds like a great idea to clear up priorities and team's position against any particular feature request. Also I think a "no goal" section would be beneficial to avoid out of scope proposals and maybe give a clear rationale as to why those wouldn't happen. optional semicolons?

[leandromoh]

we should have an entry for proposals sorted by votes too

@huoyaoyuan that would be amazing!

A bit tangential, but I already have seen a lot of feature proposals with tons of vote that never get prioritized over years whilst others features much less requested/voted by the community already were implemented and merged... at least for me, it is a bit frustrating.

for example, features #2152 , #1888, #1223, #1630, #98 were already implemented/shipped but these 5 features together only have 130 likes, what means that C# community does not see tons of benefits in them..

however...

Type classes feature issue #110 open since 2017 have 212 likes
Discriminated Unions feature issue #113 open since 2017 also have 224 likes
readonly for locals and parameters issue #3885 also from 2017 have 196 likes
Higher Kinded Polymorphism issue #339 also from 2017 have 143 likes

that is, any of the above 4 features are seen as more valuable by community than all the previous together..
IMHO each C# release should have at least some features selected by community, possibily considering the number of votes in proposals, or maybe an explict voting

[HaloFour]

@leandromoh

that is, any of the above 4 features are seen as more valuable by community than all the previous together..

I think it's fair to note that all four of those issues are championed by the language team, so they have interest in their implementation as well. Design is a slow and conservative process. NRTs took over 6 years. DIM almost as long. HKTs and type classes will likely require quite a bit of design work and runtime changes to support. DUs are going to build on top of records, which are shipping in a few months. The team is conservative and deliberate about their approach to evolving the language and I, for one, am thankful for it.

what means that C# community does not see tons of benefits in them..

Also note that this repository represents a very tiny fraction of the C# community as a whole.

[leandromoh]

@HaloFour

I think it's fair to note that all four of those issues are championed by the language team, so they have interest in their implementation as well (...) Design is a slow and conservative process. NRTs took over 6 years.

I know they are championed and design and conservative process are slow, and that is fine, but what make it so hard to creep over years? it's not just a matter of prioritizing what give developers more benefits?

The team is conservative and deliberate about their approach to evolving the language and I, for one, am thankful for it.

I agree too, C# is a well designed language and carefull design must be done for new features; my point is about prioritize the championed proposals with more votes (which supposedly indicates the feature value for the language).

Also note that this repository represents a very tiny fraction of the C# community as a whole.

Of course, but this is the tiny fraction of the C# community that is interessed to discuss/contribute actively with C# design.
I agree that not all people have free time to read each issue and upvote/downvote them, so we could do some voting with the already championed features. In the planning of each new release we could do something like open a voting with the already championed features to community selected at least 1 of the new freatures that the team should prioritize and spend time. Maybe this way proposals, at least the more voted, dont creep over years.

[scottdorman]

The other things to keep in mind, beyond what @HaloFour stated, are that

• sometimes what appear to be simple features to us are not so simple in reality
• some features, which might appear to be small, not overly useful, or have very little "community" interest are necessary stepping stones in order to get to a larger (more complex, more useful, higher interest, etc.) feature.

To add to the list that @HaloFour mentioned, "extension everything" (specifically extension properties) was first brought up 11+ years ago and has been a sort of running joke between @MadsTorgersen and myself since then. (Incidentally, I'm both happy to see we'll be getting them and saddened by it at the same time. :) ) Just because the community wants a feature doesn't mean it's going to happen or happen in the timeframe we want it to. Everything has to be evaluated in terms of the amount of work it will take, if there are compiler or CLR changes needed, the availability of developer resources to work on it, how it fits into the prioritization of other tasks, and a slew of other constraints and conflicts that we aren't usually aware of. The fact that the language design process is as open as it currently is and accepting of outside help is a significant thing. (It wasn't always this way.)