[meta] Language evolution process.

[modulovalue]

Hello @mit-mit,

I have a question and I hope that you can help me out. (I'm pinging you because you seem to be the right person to ask this question.)

The Dart language evolution process document states:

When a member of the language team decides to take up an issue [...]

Does this imply that there is no way to propose changes to Dart (and land them) without first convincing a member of the language team to take on full responsibility for a proposal? (I'm not trying to criticize, I'm just trying to adjust my expectations)

To me, this makes it seem like the only realistic way to contribute to the language is to either try to join the team (which might not be practical due to e.g. IP related concerns) or to give feedback on existing issues.

Is that more or less accurate or am I missing something?

(If you think that this is not an appropriate place to ask such questions, please let me know and I will reach out through a different channel.)

[lrhn]

I can assure you that no feature will be added to the language without the language team agreeing to it.
The language team's job is to guide and control the language's development.

It may, hypothetically, be possible for someone else to drive a feature, do all the design work, implementation plans and release scheduling, write all the tests and documentation, etc., and just get the language team's sign-off on it.
It's not likely to succeed.
And even if doing so is possible, if the change is one that the language team doesn't consider right for the direction
of language evolution, it still won't get in. (That's why it's a good idea to ask first, before doing too much work).

The language team still needs to understand the feature, its impact on the language and the expected long term effect on the ecosystem, as well as the requirements on the development teams of the parser and all the different back-ends. At that point, it's likely the language team would take over and ensure that all the necessary processes are satisfied and that the specification is written in a language that is compatible with the existing language specification, and that the changes are communicated to all the necessary sub-teams.

I'd say that a very small, non-breaking, front-end only feature might be possible. Say #2, which might be implemented almost entirely in the parser, and where it's fairly easy to argue that it has no potential for breaking existing code or introducing parsing ambiguities, and that the impact of adding it is predictably small and limited. It's a simple syntactic increment with no effect on static or runtime types or semantics.

If you can implement something like that, and convince the language team that the change is something we actually want in the language, it shouldn't be hard to find a language team member to champion landing the change.

[modulovalue]

Lasse, I completely agree with you and I'm not trying to say that any of that shouldn't happen.

I meant to imply that I have no issues with anything related to the technical side of landing a feature, but I'm a little unsure about how to deal with some social aspects.

For example, you, Lasse are very active and always provide valuable feedback and I feel like it wouldn't be appropriate to constantly "annoy" you (or other members of the language team like Erik) with requests to "move a feature forward". But it seems like, according to the language evolution process document, that that is the only accepted way to move a feature forward i.e. The squeaky wheel gets the grease?

[munificent]

But it seems like, according to the language evolution process document, that that is the only accepted way to move a feature forward i.e. The squeaky wheel gets the grease?

This is true, but the language team priorities squeaks from a large number of wheels over a large number of squeaks from a small number of very squeaky wheels. Our goal is to make the language useful to many different people with a wide variety of use cases, not just make it a product beloved by a few.

If you have a feature that you're particularly passionate about, it's most effective to evangelize that to other users and get them all clamoring for it too. That shows that it isn't just a niche feature.

[modulovalue]

Thank you Bob for the response.

it's most effective to evangelize that to other users and get them all clamoring for it too. That shows that it isn't just a niche feature.

But wouldn't that turn language design into a popularity contest? The pros (or most importantly cons) of many features might not be clear to the average programmer (or even an experienced programmer that has just picked up Dart) as they don't specialize in the domain of language design. For this reason I've assumed that trying to make people be vocal about a particular feature is frowned upon and so I've tried to consciously avoid doing that.

Is this opinion really shared across the whole team? As I said, I'm not trying to criticize, just to adjust my expectations so that I can be hopefully more often helpful than not.

[lrhn]

The goal of language design is to provide the best possible experience to the largest possible number of users over the longest possible time, within resource, technology, and backwards-compatibility bounds.
So it's trade-offs all the way down.

Winning a popularity contest by being popular should count as a success.

The trade-offs to worry about is short term popularity vs long term sustainability. That's why we don't just add every feature someone asks for, because making few people happy in the short run might not be a net positive, and that's not just counting opportunity cost.
It might cost by adding complexity, hurting maintainability and ability to evolve the language further in the future, it might make the language large and hard to learn, costing future users. It might be breaking, adding a costly migration to all users (the more users, the more popular, the more breaking changes cost).

Clean, consistent, teachable and understandable, orthogonal, all great goals. Which are most easily satisfied by a small language, which Dart can't be said to be any more. Every addition has a complexity cost. The cost may grows with every new feature.

So if you want a feature, argue that the trade-offs are in its favor. That includes impacting a large number of people, otherwise it just won't be worth it.
Small implementation cost. Small complexity cost, to implementations, language and user understanding.
Or big, long-term benefits to many users.

It's fine to tell people to go 👍 a feature request when they ask for a feature which is already requested.
Tell them to post concrete use-cases for the feature on that issue.
If enough people have enough pain, mitigating that pain becomes valuable.

But only if the cost/benefit trade-off warrants it. And only if it beats the cost/benefit of other features, because implementation resources are finite.

[modulovalue]

My personal takeaway is that it is permitted to be more proactive in trying to get the attention of the language team (e.g. via @-based-mentions of language team members) to move requests forward, and that advertising those requests to communities outside of github is allowed since the popularity of a request (e.g. 👍-based-upvotes and comments) is an important and signal to the language team.

If that is accurate, then from my point of view, this issue can be closed. Thank you, Bob and Lasse.

[lrhn]

As long as you don't expect that @-mentioning someone is guaranteed to get their attention. If nothing has really changes since the last time an issue was looked at, it's unlikely that bringing it to anyone's attention will make a difference, or warrant any new answer.

Giving, or encouraging others to give, useful and actionable feedback is always great. Plain votes need to be massive to make a difference.
Aka., I promise nothing!

[modulovalue]

As long as you don't expect [...] I promise nothing!

Of course!

[munificent]

that advertising those requests to communities outside of github is allowed since the popularity of a request (e.g. 👍-based-upvotes and comments) is an important and signal to the language team.

Yes, that's fine, though be careful to make sure you're doing it in a good faith way and not brigading. Asking other people to lend support to an issue they do actually care about it is fine. Asking them to lend support to an issue for some other reason is not.

[modulovalue]

Yes, that's fine, though be careful to make sure you're doing it in a good faith way and not brigading. Asking other people to lend support to an issue they do actually care about it is fine. Asking them to lend support to an issue for some other reason is not.

Of course, but it's impossible to enforce that other people aren't doing that.

That's why I personally would like for votes to be seen as extremely weak evidence and not be paid much attention to, but I understand that it is hard to find good metrics for language design and I suppose it is a reasonable metric in many cases.

[modulovalue]

Thank you to everybody. Any confusion that I had has been cleared up, so I'm going to close this issue.