Is there an intention to 'finish' D2?

[Adam D Ruppe]

On Thursday, 18 November 2021 at 23:19:20 UTC, H. S. Teoh wrote:
> OK, so the big question: who's "we"?

The international proletariat.

> And who are "we" negotiating with

The bourgeois class.

> and what specific result(s) are we after?

The dissolution of all class distinctions.


Duh.


ok fine really it is anyone who wants to see real change in the 
language vs the leadership. And what want to see is the 
aforementioned change. Personally what I want is a new leadership 
structure, a steering group of probably seven, maybe eleven, 
selected by D stakeholders on some term basis, probably annually, 
who have authority to make whatever changes they see fit. From 
there, they guide the language.

Now, what I'd like to see from the steering group is:

1) A new DIP policy that dispenses with the pretensions of 
grandeur and focuses on getting things done. These aren't Ph.D. 
theses, they're ways to solicit use cases and associated feature 
requests and technical analyses from the community. The process I 
propose is letting the steering committee deliberate on them in a 
private forum thread, which is then made public (but read only) 
after the decision is locked. This decision can thus be reviewed 
without being bikeshedded to hell.

I would vote for steering committee members who weigh changes 
with a cost/benefit eye. Some breaking changes are short term 
pain for long term gain. That's worth it.

2) A radically different approach to Phobos development that is 
significantly more open than it is now. Phobos is currently where 
code goes to die. It should be where code goes to thrive among 
the community. Breaking changes are discouraged, but made when 
necessary.

I've heard people say the package manager renders the standard 
library obsolete, but this isn't really true. In fact, I think it 
might be the opposite: a strong stdlib gives a solid foundation 
for reliable and interoperable third party packages.

What I'd do is to curate things from the community that can be 
tested and adopted if need be. Then if there's multiple options, 
work with the authors to abstract out some common interface into 
Phobos and get the others to use them. Then other packages can 
depend on the Phobos interface as users swap out implementations.

But again, the steering group would have the final say. I'd just 
want them to create a process that can be reliably delegated so 
it isn't using any particular bottleneck; a decentralized 
development model of a centralized library. They'd say what they 
want then they can pull from community work if/when it pops up.

3) The steering group would also have access to the foundation 
budget for hiring outside consultants when necessary. While this 
might be programming work sometimes we'd more likely need outside 
help for things like marketing since we have significant in-house 
code talent.


But what I'd push for is the steering group reform specifically 
as a condition to stop the fork. The other details can be worked 
out once we have that formed. The steering group must have 
binding authority - if they decide a change is going to happen, 
it gets merged in and no individual can overrule that.