www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - D Language Foundation May 2024 Monthly Meeting Summary

reply Mike Parker <aldacron gmail.com> writes:
The D Language Foundation's monthly meeting for May 2024 was held 
on Friday the 10th. It lasted about an hour and 30 minutes.



The following people attended:

* Walter Bright
* Jonathan M. Davis
* Timon Gehr
* Martin Kinkelin
* Dennis Korpel
* Mathias Lang
* Átila Neves
* Razvan Nitu
* Mike Parker
* Robert Schadek
* Steven Schveighoffer
* Adam Wilson





Steve wanted to discuss the implications of deprecating 
`toString`, `toHash`, `opCmp`, and  `opEquals` in `Object`. He 
brought this up after seeing [a post from 
Átila](https://forum.dlang.org/post/xwkithpcwnltfpvsyxft forum.dlang.org) in a
forum discussion on the topic, in which Átila had said:


 I talked to Walter and we agreed that the best way forward is 
 probably to deprecate these member functions and remove them in 
 the next edition.


I failed to record about half of the conversation, but I did 
catch the important bit. The idea was that we would have a 
`ProtoObject` similar to the one previously proposed, or whatever 
we wanted to call it, that did not contain the overrides. It 
would become the new root object in code compiled under the new 
edition and would be part of the `Object` hierarchy in legacy 
code.

Steve explained that it was supposed to be possible to compile 
libraries using two different editions, but they must be compiled 
with the same compiler. So the compiler would be aware of these 
two different root objects and the two different hierarchies. He 
just wanted to make sure we all agreed that we couldn't just 
remove members from legacy objects. He thought managing the 
runtime library would be the trickiest part with editions.

Martin thought it was going to be weird having these different 
hierarchies, but then as he was talking about it he realized that 
with the proto object deriving from `Object`, it might really 
work. Timon said that the new edition's object was `Object` 
without the methods, and the `Object` in the old edition was 
implicitly rewritten to legacy `Object`, and in new editions, you 
could refer to that implicitly.

Jonathan noted that we'd talked in the past about wanting to 
remove the monitor from `Object`. The proto object would allow us 
to do that. He said we should also look at whatever else we 
wanted to clean up in `Object`.



Steve said we'd recently been visited again in the forums by 
someone who periodically returned with sock puppets, and that had 
gotten him thinking about forum moderation. There were a couple 
of ways he thought we could improve it.

First, he thought it shouldn't just be me doing everything. It 
would be better if we had a team.

Second, he wondered if we could be more transparent about 
moderation. He knew we were running Vladimir's custom software, 
and he noted that I'd mentioned in the forums that there was no 
way to restore a deleted post because, ultimately, it was the 
NNTP interface backing everything. He wondered if we could put a 
layer of moderation tools on top of that.

Finally, he suggested we should have some moderation rules, even 
if they were very vague.

I agreed that we should have more people moderating. When I 
signed up, I didn't realize I was going to be the only one doing 
it. A big problem was my time zone. Sometimes, I woke up and 
didn't check the forums until late morning or early afternoon my 
time and discovered something had blown up in the interim.

I said I also would love more forum moderation tools. I would 
love to move away from the NNTP interface on the back end. It was 
2024, after all. We should have a trash bin that stored deleted 
posts so that they were recoverable. Then if somebody wanted to 
appeal, we could have a process for that. We could have time-outs 
and more. With those kinds of tools, we could be more aggressive 
in good conscience.

As far as rules, I said that I'd been around forum communities 
for 30 years. In my experience, in forums without rules, people 
sometimes complained about the lack of rules, but then in forums 
with rules, they argued over which rules were there. In the end, 
I didn't think it mattered if we had rules or not. I thought 
there were only two sensible forum rules we could have anyway:

1. The moderators have full discretion to remove posts and ban 
users as they see fit.
2. All decisions are final.

Those were the only things that made sense to me because they 
covered all the bases. There was no room for argument. There were 
no loopholes. Moderation was inherently subjective, inherently 
arbitrary, and inherently biased. For example, I'd give a lot 
more room to Steve if he went on a temper tantrum than I would to 
one of the sock puppets.

I noted that when Walter and I were having our coaching sessions 
with Saeed from Ucora, we'd come up with this idea of having a 
kind of philosophy rather than a set of specific rules. Not just 
about the forum, but the community in general. It was inspired by 
the honor system that Caltech had when Walter was studying there. 
Just a general philosophy about the kind of community we wanted 
to foster. Forum posts that went against that would deleted.

I asked that anyone willing to become a forum moderator please 
let me know.

Steve said that a good reason to have a set of rules was when you 
had a team of moderators. Then they'd have something they could 
agree on.

I said that made sense, but I could give an example of what could 
happen in that situation. I was in a forum once where the 
maintainers established a set of specific moderation rules that 
everyone was constantly arguing about. It evolved into "yellow 
card" rules that were appealable and "red card" rules that were 
not. And the list of red card rules just kept growing as they 
plugged more and more loopholes. It was a mess.

So I thought specific moderation rules were not the way to go. 
The other thing was that as moderators, Steve and I might have 
different red lines. Those were going to be gray areas where we'd 
never agree. He might delete a post I wouldn't have, or I might 
approve a post he wouldn't have. We should agree to back each 
other up in those cases, and any moderation guidelines we might 
come up with should account for that.

I asked who wanted to join me as moderators. Steve and Dennis 
both volunteered. Átila noted that covered all the time zones.

Razvan said he'd be happy to help, but wouldn't want to make 
moderation decisions. He'd prefer instead to flag posts for 
moderation. Steve noted that the forum software did have a link 
to flag posts (not visible to everyone) that was a little 
underdeveloped since it didn't allow you to specify the reason 
you were using it. He said he'd typically only flagged spam. If 
people were being argumentative, he felt the best solution was 
just to ignore them.

I said the general rule I'd been trying to follow was that if 
someone lobbed a blatant personal insult in a post, I didn't care 
what other information was in it, I'd delete it. Sometimes I'd 
see things that weren't blatant insults but tingled my spidey 
sense. Something close to the line for me, but not across it, 
though it might cross it for someone else. In those cases, I 
would wait and see. If the target of the insult then reached out 
to me to complain about it, in the past I'd often try to persuade 
them to let it go since I didn't see it as an insult. These days, 
I was more likely to delete the offending post. No questions 
asked.

Another thing I looked for was if a post was disruptive to a 
thread. What I considered disruptive or not, other people might 
consider the opposite. So if I started getting emails about a 
post that I initially let pass, I could say, "Okay, it's 
disruptive.".

We then devolved into a bit of discussion about the forum's spam 
filter, the types of spam we get, and so on, before moving on to 
the next item.

(UPDATE: Vladimir set up both Steve and Dennis as forum 
moderators a few days later. They've been working at it since. 
It's nice to have the extra hands and eyes, so thanks to both of 
them for stepping up.)



When I announced the new DIP process, the one thing I hadn't yet 
worked out was how to handle DIPs from Walter and Átila. I 
believed that if Walter wrote a DIP and could persuade Átila to 
approve it, that should be enough, and vice versa. But I 
remembered the big community blowup over the safe-by-default DIP 
and how we responded to that by requiring Walter and Átila to 
find someone else to take on their DIP ideas. We'd since decided 
that was a mistake, but I didn't want to make an arbitrary 
decision myself about how to handle their DIPs in the new process.

Walter and I had spoken about it and we wanted to get input from 
the rest of the team. I asked for their thoughts.

Jonathan said he wasn't sure what should be done in terms of 
approval, but he thought it was important that Walter's and 
Átila's proposals were submitted for community feedback. I said 
that was a given, and that Walter had two DIPs in the development 
forum at the moment. That was why this was coming up now.

One of the posted DIPs was [the bitfields 
proposal](https://forum.dlang.org/post/v193hc$b9c$1 digitalmars.com). It had
received a good bit of opposition, including from people in the meeting. The
other DIP was the one proposing [ref for variable
declarations](https://forum.dlang.org/thread/v11mh1$fvs$1 digitalmars.com). It
wasn't controversial. Should he and Átila approve it, then no big deal. But
what about the bitfields DIP? If they approved that, would we have another
blowup?

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.

Martin said it wouldn't just be that. The one thing he didn't 
like was that we'd lose the ability to take the address of any 
member. That would be an ugly special case.

Steve said his point was that there wasn't a whole lot of code 
out there that was suddenly going to be broken. You'd have the 
choice not to use bitfields. So he thought maybe people weren't 
going to like it, but they weren't going to use them either.

I noted that I wasn't asking what to do about any specific DIP 
but about DIPs authored by Walter and Átila in general. What 
should their assessment look like?

Steve said he didn't know of a way to do it other than having 
someone else with veto power involved to avoid the situation with 
the safe-by-default DIP. It wasn't like there wasn't feedback on 
that one, or that there wasn't complete disagreement between the 
community and the maintainers, and they approved it anyway. He 
didn't know how you could fix that. He didn't think it was the 
DIP process, just that that specific DIP was controversial.

Átila said they had walked it back anyway, so he wasn't sure 
anything failed in that case. Steve said that was true, but he 
didn't know if there was something we could do with the process 
to prevent controversy.

Timon said he didn't think the safe-by-default DIP was 
controversial in its entirety. There was just one aspect that, in 
his opinion, had an easy fix that Walter didn't want to 
implement. He instead decided to revert the decision. In the end, 
it wasn't an issue over breakage, it was just about having 
`extern(C)` functions be safe by default.

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.

I said I just wanted a solution. Razvan had made a point to me in 
one of our conversations that when someone from the community put 
a DIP forward, they had Walter and Átila as counterweights. They 
were there to temper it and tone it down after all the feedback 
to make the final decision. But if it was just Walter or Átila 
putting a DIP forward, they each had only the other as a counter. 
Did we need more than that? Did we need to set up something more? 
That was what I was looking for feedback on.

Razvan believed we did. There should be a mechanism of oversight 
for everyone submitting a DIP. Even the language maintainers 
could get it wrong, so we needed someone to point that out. Átila 
said that should be him, but maybe we could just pick one of the 
team members to be a second counter.

Razvan noted that his original suggestion to me was that we 
should have some sort of committee. It could be two or three 
people we trusted with this. If it were just one person, to the 
community it might look like Átila could just give two beers to 
Walter to get his DIP approved. Átila joked that that would be a 
lot more effective on him.

Walter said he wanted to avoid what had happened with the C and 
C++ committees. He felt they had lost their way with the features 
they were adding and approving. He said they'd approved some 
baffling stuff, like C identifiers that were normalized Unicode 
identifiers. And C++ had implemented modules in a completely 
wrong and ridiculous way. And they had a new library function 
called std::launder. He said that he laughed every time he heard 
a description of it, then forgot what it did.

He said that when the C++ committee first formed back in the 90s, 
he'd heard members say things like, "I'll vote for your feature 
if you vote for my feature." He felt that kind of thing had led 
to incredible complexity in the language.

I said that wasn't the case here. What Razvan was proposing 
wasn't a committee that made proposals, but a committee that just 
acted as a counter for proposals from him and Átila.

Átila said that either the committee should be the people in this 
call, or that I should pick someone to be the second counter.

Robert said he had thought something similar. We should just go 
round-robin or random selection. When Átila put a proposal 
forward, we could select one of us who wasn't Átila to assess the 
DIP with Walter. And if the chosen person didn't have the time or 
felt they didn't have the expertise, they should bow out and we 
would go a second round with a shorter list.

Razvan thought the point here was to avoid the situation where an 
overwhelming majority of the community felt that a DIP by Walter 
or Átila shouldn't be implemented. So we could just have a 
discussion about that particular DIP in one of our meetings, and 
then vote on it. If you felt you didn't have the expertise, you 
didn't vote. Then it would also be on Walter and Átila to agree 
that they would accept the result or modify the proposal to sync 
it with expectations.

Átila said that would be okay.

Walter asked if everyone remembered his string interpolation 
proposal. There was just him, and then everybody else. It was a 
pretty painful thing for him, all the arguing about it. He didn't 
like what happened, but he eventually threw in the towel on it. 
He couldn't fight everybody on it. He still thought it had been a 
bad idea to give up, but he accepted that the community wanted a 
different approach.

It had been him against the world, and he'd given up. So it 
wasn't the case that he could just override everyone in the 
community. It may work in theory, but it didn't work in practice. 
He'd given up on other things, too, over the years. He still 
seemed to be the only one who thought ` live` had any value. He 
thought the jury was still out on that, but he wasn't confident 
it would survive.

Steve said he thought it was important that anyone involved in 
assessing a DIP should be as neutral as possible. You didn't want 
someone deciding on it who was adamantly for or against it. They 
had to be able to look at the arguments objectively. That was 
kind of the point of not having Walter or Átila as the author 
involved in deciding. They'd be so close to it that they might 
not see the drawbacks.

I said that I was uncomfortable watering down Walter's authority 
as a language maintainer even when it came to approving his own 
DIPs. What if instead of having the team vote for a DIP, we sat 
down to identify critical flaws that would cause problems down 
the road and hash those out? I didn't know what that would look 
like, though.

Robert said it was like we were trying to discover a new 
government form next to democracy. When Walter was talking about 
how it was him against the community on certain issues, Robert 
had the thought that D is much more now than just something on 
Walter's computer all those years back. It had a growing 
community and was used, loved, and hated by a whole slew of 
people. A benefit was that Walter got to go to DConf and have a 
good time, but it also meant that he lost some control. Robert 
wasn't sure that could be avoided. He understood how Walter could 
get uncomfortable with it, but felt it was par for the course.

He said whether we went with voting in our meetings, a committee, 
or having one or two people sit in to decide when needed, it had 
to be Walter's decision to abdicate some of his power. It wasn't 
like we were a community of 80 million people. He worried about 
coming up with a detailed DIP process trying to account for all 
kinds of caveats. At the end of the day, we had to trust whoever 
we elected to evaluate Walter and Átila's DIPs, even when we 
disagreed with them. We just had to agree to disagree and move 
on. He felt we weren't going to find "perfect" here.

Steve felt whoever we picked should handle things via 
face-to-face discussions rather than via forum posts or emails. 
It was too hard to read the context and emotions involved in text.

Adam said that one of the reasons people brought things to him in 
Discord was because they knew he'd be sitting in front of Walter 
for an in-person discussion. He said it had been a bit 
frustrating at times because he didn't always get their points 
across the way they wanted, but even in those cases he was often 
able to get to a point where Walter would say, "Okay, I'll have 
to think about that." So there was something to be said for 
face-to-face communication.

We got sidetracked a bit here talking about instances where 
disagreements had been solved via video calls, conversations at 
DConf, and in other face-to-face scenarios, then Walter suggested 
that if a DIP was controversial, then we should have a meeting 
about it to work it out. The person carrying the flag for it 
should be involved, and then we could argue this way and that 
about it. Arguing about it in the forums was never going to work 
and only resulted in hurt feelings.

I said doing that for controversial DIPs was fine, but the issue 
at hand was about doing something like that for his and Átila's 
DIPs. I proposed that instead of picking one person to serve as a 
second counter, we could have a group meeting with the regular 
team. We could get together, then I'd ask if there were any 
objections to moving a DIP forward, and we'd go from there. The 
goal would be to resolve any objections one way or another. If 
they were resolved in the author's favor, the DIP could go 
forward. If not, it didn't get approved. Then if coming out of 
that, the DIP ultimately was approved and any controversy arose, 
we could explain whether any objections were raised and, if so, 
how they were overcome. The point would be that the whole team 
would be behind it if it went forward.

I asked if everyone was okay with that. There were no objections.



I next asked if anyone objected to either the ref DIP or the 
bitfields DIP. I wanted to know if we needed to call a special 
meeting to handle either DIP or to determine if any objections 
were simple enough to handle in the time remaining in this 
meeting. There were no objections to the ref DIP, but Timon and 
Steve indicated they had objections to the bitfields DIP. They 
had already brought them up in the forums, but I asked them to 
voice them here to see if we could deal with them.

This started a discussion that lasted close to 30 minutes. I 
won't walk through the entire thing here, as ultimately the major 
objections had already been aired in the three review threads in 
the DIP Development forum. The two biggest ones were that we 
should specify a layout for bitfields and require `extern(C)` on 
any bitfield that was dependent on the layout in the system's C 
compiler implementation. Walter believed that we didn't need to 
specify a layout and that it was perfectly fine to rely on the 
system C compiler implementation. We were already doing that with 
things like struct layout anyway.

Additionally, Martin reiterated his objection that we'd lose the 
ability to say that every member of an object was directly 
addressable.

At some point, I cut the conversation off and proposed we hold a 
separate meeting to discuss the bitfield DIP in detail. Everyone 
agreed.

(__UPDATE:__ Given that no objections were raised to Walter's ref 
DIP, it became DIP 1046 and I submitted it to Átila for 
assessment. He requested one clarification [and then approved 
it](https://forum.dlang.org/post/xyppgndgxdjyqtftfjgd forum.dlang.org). The
meeting regarding the bitfields DIP went well, overall. The consensus was that
there was no objection to the DIP in principle, just disagreement over the
implementation details. We talked about several potential issues with
bitfields, including layout, alignment, immutability, taking an address, etc.
In the end, Walter agreed to make a few changes to the DIP and to test the
implementation with a serialization library to see how it holds up before
deciding if the DIP should move forward.)



On May 18, we had a small planning session with Rikki to discuss 
his DIP 1045, then we had the bitfields meeting on May 25. Our 
next monthly meeting was on June 14.
Aug 28
next sibling parent reply Anonymouse <zorael gmail.com> writes:
On Wednesday, 28 August 2024 at 07:43:05 UTC, Mike Parker wrote:

 [...]


Thanks!
Aug 28
parent reply Mike Shah <mshah.475 gmail.com> writes:
On Wednesday, 28 August 2024 at 09:04:58 UTC, Anonymouse wrote:

 On Wednesday, 28 August 2024 at 07:43:05 UTC, Mike Parker wrote:

 [...]


 Thanks!


Thanks for the write-up Mike!

I do like  live, curious others thoughts? Perhaps it doesn't need 
to be an attribute though and is instead a compiler flag for an 
analysis pass on any function (kind of reminds me of frameworks 
like Soot for Java that you control various analysis passes). 
Perhaps a conversation for another thread 🙂
Aug 28
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 28 August 2024 at 12:55:35 UTC, Mike Shah wrote:

 [snip]

 Thanks for the write-up Mike!

 I do like  live, curious others thoughts? Perhaps it doesn't 
 need to be an attribute though and is instead a compiler flag 
 for an analysis pass on any function (kind of reminds me of 
 frameworks like Soot for Java that you control various analysis 
 passes). Perhaps a conversation for another thread 🙂


There are interesting things about  live, but the spec says it is 
still experimental and I don't really have the time to mess about 
with it.

importC has clearly been a bigger priority than  live over the 
past couple of years.
Aug 28
prev sibling next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 29/08/2024 12:55 AM, Mike Shah wrote:

 On Wednesday, 28 August 2024 at 09:04:58 UTC, Anonymouse wrote:

 On Wednesday, 28 August 2024 at 07:43:05 UTC, Mike Parker wrote:

 [...]


 Thanks!


 
 Thanks for the write-up Mike!
 
 I do like  live, curious others thoughts? Perhaps it doesn't need to be 
 an attribute though and is instead a compiler flag for an analysis pass 
 on any function (kind of reminds me of frameworks like Soot for Java 
 that you control various analysis passes). Perhaps a conversation for 
 another thread 🙂


Word of warning on  live, for owner escape analysis to function, you 
must have escape analysis. It uses DIP1000 for "escape analysis".

The only issue with this is, what I realized recently is that DIP1000 
isn't escape analysis, its owner escape analysis for stack memory.

These two analysis's are completely opposite in what they offer in terms 
of guarantees.
Aug 28
parent reply Mike Shah <mshah.475 gmail.com> writes:
On Wednesday, 28 August 2024 at 13:53:47 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 On 29/08/2024 12:55 AM, Mike Shah wrote:

 On Wednesday, 28 August 2024 at 09:04:58 UTC, Anonymouse wrote:

 [...]


 
 Thanks for the write-up Mike!
 
 I do like  live, curious others thoughts? Perhaps it doesn't 
 need to be an attribute though and is instead a compiler flag 
 for an analysis pass on any function (kind of reminds me of 
 frameworks like Soot for Java that you control various 
 analysis passes). Perhaps a conversation for another thread 🙂


 Word of warning on  live, for owner escape analysis to 
 function, you must have escape analysis. It uses DIP1000 for 
 "escape analysis".

 The only issue with this is, what I realized recently is that 
 DIP1000 isn't escape analysis, its owner escape analysis for 
 stack memory.

 These two analysis's are completely opposite in what they offer 
 in terms of guarantees.


Interesting -- I'll have to look more into this. I'll read along 
the other threads otherwise on DIP 1000 to keep the discussion 
there. Thanks!
Aug 28
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 29/08/2024 2:49 AM, Mike Shah wrote:

 On Wednesday, 28 August 2024 at 13:53:47 UTC, Richard (Rikki) Andrew 
 Cattermole wrote:

 On 29/08/2024 12:55 AM, Mike Shah wrote:

 On Wednesday, 28 August 2024 at 09:04:58 UTC, Anonymouse wrote:

 [...]


 Thanks for the write-up Mike!

 I do like  live, curious others thoughts? Perhaps it doesn't need to 
 be an attribute though and is instead a compiler flag for an analysis 
 pass on any function (kind of reminds me of frameworks like Soot for 
 Java that you control various analysis passes). Perhaps a 
 conversation for another thread 🙂


 Word of warning on  live, for owner escape analysis to function, you 
 must have escape analysis. It uses DIP1000 for "escape analysis".

 The only issue with this is, what I realized recently is that DIP1000 
 isn't escape analysis, its owner escape analysis for stack memory.

 These two analysis's are completely opposite in what they offer in 
 terms of guarantees.


 
 Interesting -- I'll have to look more into this. I'll read along the 
 other threads otherwise on DIP 1000 to keep the discussion there. Thanks!


Here is an example from Paul where DIP1000 is not designed to model:

https://forum.dlang.org/post/ninnlmosrxewsrwgrinv forum.dlang.org

 live is naturally going to fall apart for anything related to function 
calls (ignoring the fact that its opt-in).

Borrow checkers need to be able to differentiate between a parameter 
being an output and/or input. Otherwise they can't protect you.

Note: that is in the woes thread so its restricted on replies.
Aug 28
prev sibling parent Paul Backus <snarwin gmail.com> writes:
On Wednesday, 28 August 2024 at 12:55:35 UTC, Mike Shah wrote:

 I do like  live, curious others thoughts? Perhaps it doesn't 
 need to be an attribute though and is instead a compiler flag 
 for an analysis pass on any function (kind of reminds me of 
 frameworks like Soot for Java that you control various analysis 
 passes). Perhaps a conversation for another thread 🙂


The fact that  live is incompatible with existing  safe D code 
makes it dead on arrival.

There are ways to include this kind of analysis without breaking 
compatibility, but as you say, it has to be a global thing (like 
DIP 1000), not an attribute that's applied function-by-function.
Aug 29
prev sibling next sibling parent reply Sergey <kornburn yandex.ru> writes:
On Wednesday, 28 August 2024 at 07:43:05 UTC, Mike Parker wrote:

 Walter agreed to make a few changes to the DIP and to test the 
 implementation with a serialization library to see how it holds 
 up before deciding if the DIP should move forward.)



 On May 18, we had a small planning session with Rikki to 
 discuss his DIP 1045, then we had the bitfields meeting on May 
 25. Our next monthly meeting was on June 14.


So it's not very clear - the situation with bitfields in August.. 
is still under testing?
Aug 28
parent Mike Parker <aldacron gmail.com> writes:
On Wednesday, 28 August 2024 at 19:01:39 UTC, Sergey wrote:


 So it's not very clear - the situation with bitfields in 
 August.. is still under testing?


I haven't had any updates since then, but I'm pretty sure Walter 
has set it to the side for now to focus on other things.
Aug 28
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
Mike Parker kirjoitti 28.8.2024 klo 10.43:

 I asked who wanted to join me as moderators. Steve and Dennis both 
 volunteered. Átila noted that covered all the time zones.


Great! And also great job from yourself moderationg so far!


 When I announced the new DIP process, the one thing I hadn't yet worked 
 out was how to handle DIPs from Walter and Átila. I believed that if 
 Walter wrote a DIP and could persuade Átila to approve it, that should 
 be enough, and vice versa. But I remembered the big community blowup 
 over the safe-by-default DIP and how we responded to that by requiring 
 Walter and Átila to find someone else to take on their DIP ideas. We'd 
 since decided that was a mistake, but I didn't want to make an arbitrary 
 decision myself about how to handle their DIPs in the new process.
 
 [snip]


I don't think there's anything in particular wrong with the process. 
Àtila just happened to make a poor decision when approving that DIP of 
Walter. If anything, maybe it could help if you *didn't* discuss it 
face-to-face before making the decision. The forum feedback is all just 
text without much human element, so it's probably easier to be fair to 
the DIP if your last-minute personal exchanges about it are also just 
emails.



 Walter asked if everyone remembered his string interpolation proposal. 
 There was just him, and then everybody else. It was a pretty painful 
 thing for him, all the arguing about it. He didn't like what happened, 
 but he eventually threw in the towel on it. He couldn't fight everybody 
 on it. He still thought it had been a bad idea to give up, but he 
 accepted that the community wanted a different approach.


That was an excellent thing to do.

All this (the whole summary, not just this paragraph) sounds like you 
(especially Walter but not just him) still weigh community opinion on 
the DIPs far less than it'd be wise. I get it, it isn't a democracy, but 
nonetheless how much you respect the opinions of regular users heavily 
affects the popularity of the foundation and the language. It ought to 
be only in very rare special cases that you decide against an 
overwhelming opinion. I see a bit improvement in understanding this 
point, maybe thanks to IVY, but not as much as I'd like.

Sorry for being harsh. I appreciate that you still keep writing these 
summaries.
Aug 30
parent reply Mike Parker <aldacron gmail.com> writes:
On Friday, 30 August 2024 at 13:49:09 UTC, Dukc wrote:


 All this (the whole summary, not just this paragraph) sounds 
 like you (especially Walter but not just him) still weigh 
 community opinion on the DIPs far less than it'd be wise. I get 
 it, it isn't a democracy, but nonetheless how much you respect 
 the opinions of regular users heavily affects the popularity of 
 the foundation and the language. It ought to be only in very 
 rare special cases that you decide against an overwhelming 
 opinion. I see a bit improvement in understanding this point, 
 maybe thanks to IVY, but not as much as I'd like.

 Sorry for being harsh. I appreciate that you still keep writing 
 these summaries.


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.
Aug 30
parent reply Dukc <ajieskola gmail.com> writes:
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.
Aug 30
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
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.
Aug 31
parent Dukc <ajieskola gmail.com> writes:
On Saturday, 31 August 2024 at 08:29:57 UTC, Mike Parker wrote:

 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.


Ok, maybe I just read more to the nuances of the summary than 
there actually is. And in any case, clearly you do consider my 
points important already.
Aug 31
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 8/30/24 22:36, Dukc wrote:

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


Rejecting a DIP can be one of those bad decisions.

Anyway, obviously I prefer good decisions over bad decisions,
Aug 31
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 8/31/24 17:41, Timon Gehr wrote:

 On 8/30/24 22:36, Dukc wrote:

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


 
 Rejecting a DIP can be one of those bad decisions.
 
 Anyway, obviously I prefer good decisions over bad decisions,


but language development is an incremental process and it helps if 
progress does not have to be fully monotone.

(Accidentally hit send.)
Aug 31
parent Dukc <ajieskola gmail.com> writes:
Timon Gehr kirjoitti 31.8.2024 klo 18.44:

 On 8/31/24 17:41, Timon Gehr wrote:

 On 8/30/24 22:36, Dukc wrote:

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


 Rejecting a DIP can be one of those bad decisions.




Good point. It's easier to accept a DIP with popular pressure behind 
when there's a way to back off if necessary.
Sep 02