A New Era for the D Community

[FeepingCreature]

On Sunday, 7 May 2023 at 02:15:02 UTC, monkyyy wrote:
> On Wednesday, 3 May 2023 at 11:13:34 UTC, Mike Parker wrote:
>> IVY, their organizational development program
>
> Your solution to hearing luas dev saying "I dont manage 
> anything" and whatever feedback from your survey, is you got 
> corporate training and now you gun-ho about management?
>
> Was I in an extreme minority here?
>
> https://monkyyyscience.substack.com/i/93037044/stop-pretending-d-is-a-corporate-language
>
>>> *Stop pretending D is a corporate language*
>
>>> You have a community of meta-programming-crazed iconoclasts
>
>>> Either you believe this small community has great 1000x 
>>> programmers or you don't and we are doomed anyway
>
>>> If Adr says "I want to make a color lib", don't stand in his 
>>> way give him the namespace std.community.color that can be 
>>> written to his style guide, to his standards, on his github, 
>>> and when a new version of the compiler ships a script will 
>>> grab a snapshot
>
> Please redesign and relaunch `std.experimental` to have a 
> completely hands-off, anarchic structure. I'm confused how you 
> came to the conclusion that complaints about management mean 
> there should be more management instead of a fundamentally 
> different approach.
>
>>> Don't herd cats, just clean out the litter boxes.

To be honest, this has always been my take as well.

I don't want to be critical here, because I have no idea what IVY 
is and what is supposed to come of this, but I have seen people 
for years saying that D has a management problem, and this has 
always seemed wrong to me. D has an effort and agreement problem, 
but that's not something you can manage in a community of 
volunteers. Management implies an ability to focus effort. 
Broadly, D doesn't have users who want to improve D, D has users 
who want to improve doing X *with D.*

Now D management can say "we want to reach style X" or "we are 
working on improvement Y"; they can do this by setting review 
standards and only merging PRs that go in the direction they want 
the project to do. But they cannot decide what work gets done - 
only accept or reject.

Isn't the point of the DIP process primarily to be able to 
forecast whether a feature will be accepted or rejected? So 
managing the work requires an inherently reactive approach.

This is why I never understood why people were saying D "needed 
better management". What work got done has always been, in this 
language, a matter of some person saying "I could do this cool 
thing" and going and doing it. This can be mismanaged, sure, and 
there's room for improvement, granted, but better management can 
still not make improvements appear where currently there are none.

(Honestly, maybe 80% of the time when I've seen "D needs better 
management", it has been code for "D management didn't like my 
proposal.")