D Language Foundation May 2024 Monthly Meeting Summary

[Mike Parker]

On Friday, 30 August 2024 at 20:36:09 UTC, Dukc wrote:
> Mike Parker kirjoitti 30.8.2024 klo 17.30:

Thanks for elaborating.


> > 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!

I can't speak for Steve, but I can tell you how I interpret what 
he said. He objected to the bitfields DIP for the same reason 
others did. Here, he was just expressing his opinion that this 
wasn't an issue he was willing to plant a flag over. He feels the 
consequences of it don't go beyond the feature itself and, since 
he thinks most people aren't going to use it anyway, he isn't 
going to waste energy fighting over it if it comes to that.

I don't see any disrespect of community opinion in that. And in 
the end, his input during the meeting on the DIP contributed to 
the outcome. He was essentially an advocate for the opposition to 
the proposal.

>
> 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.

Again, I can't speak for Timon, but I can tell you how I 
interpret this. He was simply pointing out that editions give us 
more freedom to correct mistakes when we make them. Since 
editions are intended to encapsulate breaking changes, then we 
can undo in one edition any mistakes we made in a previous one. 
That doesn't mean we have a license to go wild, it just means we 
have more room to maneuver. I son't see anything unnerving about 
that.

Speaking for myself, I agree with him. Going a step further, I 
think editions will enable us to test new features without 
preview flags. We could add a feature in an edition and 
explicitly label it in the changelog as a preview feature, or 
maybe have a "preview edition" of preview features. I don't know, 
I'm just spitballing here. But the point is, if something isn't 
working, we have the flexibility to improve it or remove it in a 
future edition without worrying about breaking changes.

>
> 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.

I want a better process because the old one wasn't working. 
Period. The DIP process itself was onerous and time consuming. 
I've seen it described as disrespectful of the DIP author's time. 
It had to change. I think the new process is much better.

The last piece was deciding on an established process for 
evaluating Walter's and Atila's DIPs and, since it came up in the 
meeting, controversial DIPs. I wanted that because I want to make 
sure that we have solid footing for any approval or rejection, 
regardless of opinion in the forums.

There has to be a balance here. It cannot be the case that forum 
opinion overrides maintainer decisions, and it must be the case 
that forum opinion is considered in the evaluations. I think the 
solution we've arrived at gets us close to that middle ground. 
Some of the members in any DIP review meeting will certainly 
represent opinions raised in the forums.

Like you said, we've got some respected voices on the team. We 
can add more voices with relevant experience or knowledge 
regarding specific DIPs when needed. Their role is to put the 
brakes on when they believe a proposal is flawed and should not 
go forward. If we then get to the point where they're satisfied 
that the flaws have been overcome, then the DIP can move forward 
on a solid basis.

Whether a DIP ends up approved or rejected after this process, 
the idea is that we'll have established a solid rationale either 
way.

Regarding contributor morale, we do consider it. Of course we do. 
That's what motivated us to go through Ucora's program, to expand 
our meeting team, to overhaul the DIP process, to start inviting 
stakeholders from the community to the planning sessions we have 
when we're discussing issues related to their interests.

It's why these days I push Walter and Atila for more verbosity in 
their rationales when they approve or reject a DIP. They are both 
very terse when they initially let me know their decision. I'm 
the one writing the announcement in the forums, so I want to make 
sure I understand the rationale fully and that it adequately 
addresses potential questions. I've learned the hard way that 
even uncontroversial decisions need a solid rationale that 
everyone can understand.

Anyway, I'm sorry that you feel we've been disrespectful of 
community opinion. I hope that over time the new process has a 
more positive impact.