D Language Foundation May 2024 Monthly Meeting Summary

[Dukc]

Mike Parker kirjoitti 30.8.2024 klo 17.30:
> On Friday, 30 August 2024 at 13:49:09 UTC, Dukc wrote:
> 
> I can't understand how that's the impression you get from this. I was 
> looking for a solution that would find a balance between the 
> "dictatorial" aspect of approving DIPs authored by Walter and Atila and 
> the input of the community when a DIP is unpopular.
> 
> I think what we've settled on will help with that. Had something like 
> this been in place when that safe-by-default DIP was proposed, I expect 
> the outcome would have been very different. It wouldn't have made it to 
> approval without modification. That's the point here.

Right, you do aknowledge the problem and are making honest effort to 
solve it, yet I still posted criticism almost as if you didn't. I 
certainly owe details on what about the summary worries me. Let's go.

First off,

 > Steve didn't think the bitfields DIP was as controversial as the 
`extern(C)` functions being safe by default, which was the source of the 
blowup over that DIP, because not many people were using bitfields. He 
thought Walter's concerns were a non-issue as nobody would care. The 
penalty would be that we'd just inherit all of C's problems with bitfields.

There's nothing inherently wrong in this. Steve is probably right, it 
isn't _as_ controversial as the safe-by-default C functions. But saying 
that it would lead to _just_ inheriting C's bitfield problems is what 
worries me. It likely wouldn't result in a wave of ragequits of D, but 
that doesn't mean it would have no effect on general impression of the 
foundation. On positive note though, you _did_ decide revising it more 
before proceeding so there still is progress!

Second, this:

 > He said that going forward, accepting a bad DIP would be less 
consequential than it had been in the past once we had editions. In the 
worst case, we'd have one thing more to maintain in an intermediate 
edition before it was fixed. Maybe that was a calculation we could take 
into consideration. Átila said that was a good point.

You should be at least as worried about the damage to contributor morale 
on a bad decision as about the damage to the language. Editions do good 
job limiting the latter but not the former. If you accept that you can 
see why this attitude is unnerving.

Also, the general idea that you want a better process to avoid such 
failures, feels like you're using it as a substitute to simply raising 
the bar of going against community consensus. This also deserves 
elaboration.

We all know that when Walter starts pursuing an idea he just won't hear 
"no". It's just his nature. Sometimes it's a virtue - D exists because 
Walter refused to believe he couldn't implement a C compiler, and also 
the countless naysayers when he still was working alone on D. It's 
probably overwhelmingly difficult for him to seriously question those 
parts of his DIPs he considers central to his visions. Meaning I 
shouldn't have written "especially Walter" in my last post - sorry about 
that.

But, the old process already has Átila as the gatekeeper. I think Átila 
is more capable than Walter to stop and reconsider, and even if he isn't 
his fixations are different from Walter's. Therefore when the community 
is virtually unanimously screaming NO NO NO it ought to make him 
extremely unlikely to apply the green stamp. Or at least to correct his 
attitudes about that after making one bad decision, without needing a 
change to the process.

That said, I did miss a few paragraphs when I read the summary. When I 
check it again, it seems the new process isn't that heavy (discuss it on 
meeting if unpopular). Also it does address the problem - the usual 
participants of the meeting are a reasonable representation of the 
community so as long as you listen to the participants it should work. 
So I agree the process revision sounds good, even if in my view you 
shouldn't have had to do it.