On 12/24/2022 3:22 PM, ag0aep6g wrote:
> For me, dealing with D's leadership has been an infuriating experience time and time again. It's the one reason why I have dialed back my contributions to near zero. There is a lot to fix in D, but when I have to fight for the privilege of cleaning up after you guys while you refuse to even recognize your own bugs, that's just not worth it.

You have 28 merged pull requests:

https://github.com/dlang/dmd/pulls?q=is%3Apr+author%3Aag0aep6g+is%3Aclosed

and 2 that aren't:

https://github.com/dlang/dmd/pulls/ag0aep6g

Your track record of successful contribution is very, very good.

On 12/24/2022 7:10 PM, Jonathan Marler wrote:
> I have alot of memories like this one from when I use to try to fix issues with D. I have a passion about my tools being correct, but, I found myself spending more time arguing with people than writing code. It was miserable.

I don't like arguing, either. I often spend more time arguing about a PR than developing it. I understand how frustrating this can be. I suppose it just comes with the territory when there are a lot of stakeholders doing reviews.


> Now I'm able to spend time doing what I love, writing robust-maintainable software with good tooling. When there's an issue with my toolchain, I'm able to submit a fix and it gets merged. It's night and day for me. I don't understand why there's was always so much disagreement/resistance when I contributed to D, I suppose I may never know. No hard feelings though, hope y'all are doing well.

Your track record of successful merges is also very, very good and you should be proud of your achievements:

https://github.com/dlang/dmd/pulls?page=1&q=is%3Apr+author%3Amarler8997+is%3Aclosed

On Sunday, 25 December 2022 at 07:47:19 UTC, Walter Bright wrote:
> On 12/24/2022 7:10 PM, Jonathan Marler wrote:
>> I have alot of memories like this one from when I use to try to fix issues with D. I have a passion about my tools being correct, but, I found myself spending more time arguing with people than writing code. It was miserable.
>
> I don't like arguing, either. I often spend more time arguing about a PR than developing it. I understand how frustrating this can be. I suppose it just comes with the territory when there are a lot of stakeholders doing reviews.

If you don't like arguing, then just stop arguing.

>
>> Now I'm able to spend time doing what I love, writing robust-maintainable software with good tooling. When there's an issue with my toolchain, I'm able to submit a fix and it gets merged. It's night and day for me. I don't understand why there's was always so much disagreement/resistance when I contributed to D, I suppose I may never know. No hard feelings though, hope y'all are doing well.
>
> Your track record of successful merges is also very, very good and you should be proud of your achievements:
>
> https://github.com/dlang/dmd/pulls?page=1&q=is%3Apr+author%3Amarler8997+is%3Aclosed

Getting PRs in should be an achievement, it should be a part of working process. I also heavily dislike how you argue the experience of getting PRs in by how much of them exist. If people tell you their experience sucked, then you should listen to it and try to improve it.

On Sunday, 25 December 2022 at 15:58:55 UTC, GrimMaple wrote:
> On Sunday, 25 December 2022 at 07:47:19 UTC, Walter Bright wrote:
>> On 12/24/2022 7:10 PM, Jonathan Marler wrote:
>>> I have alot of memories like this one from when I use to try to fix issues with D. I have a passion about my tools being correct, but, I found myself spending more time arguing with people than writing code. It was miserable.
>>
>> I don't like arguing, either. I often spend more time arguing about a PR than developing it. I understand how frustrating this can be. I suppose it just comes with the territory when there are a lot of stakeholders doing reviews.
>
> If you don't like arguing, then just stop arguing.
>
>>
>>> Now I'm able to spend time doing what I love, writing robust-maintainable software with good tooling. When there's an issue with my toolchain, I'm able to submit a fix and it gets merged. It's night and day for me. I don't understand why there's was always so much disagreement/resistance when I contributed to D, I suppose I may never know. No hard feelings though, hope y'all are doing well.
>>
>> Your track record of successful merges is also very, very good and you should be proud of your achievements:
>>
>> https://github.com/dlang/dmd/pulls?page=1&q=is%3Apr+author%3Amarler8997+is%3Aclosed
>
> Getting PRs in should be an achievement, it should be a part of working process. I also heavily dislike how you argue the experience of getting PRs in by how much of them exist. If people tell you their experience sucked, then you should listen to it and try to improve it.

Of course, I meant it shouldn't be an achievement.

If multiple contributors with significant track records of success are telling you that the frustration of working with D's leadership has driven them to stop contributing, how many potential contributors would you estimate have given up before even getting to that point?

D's lack of manpower is often lamented on this forum. If our current approach to leadership and governance is costing us manpower, that seems to me like a serious bug in the D project, which we ought to prioritize fixing.

On Sunday, 25 December 2022 at 15:58:55 UTC, GrimMaple wrote:
> On Sunday, 25 December 2022 at 07:47:19 UTC, Walter Bright wrote:
>> On 12/24/2022 7:10 PM, Jonathan Marler wrote:
>>> I have alot of memories like this one from when I use to try to fix issues with D. I have a passion about my tools being correct, but, I found myself spending more time arguing with people than writing code. It was miserable.
>>
>> I don't like arguing, either. I often spend more time arguing about a PR than developing it. I understand how frustrating this can be. I suppose it just comes with the territory when there are a lot of stakeholders doing reviews.
>
> If you don't like arguing, then just stop arguing.

I think the point Walter's making is that he has to go through the same review process, and it sucks for him too. I take the last sentence to mean it's caused by the current system giving veto power to many people.

My impression is that in the early days functionality was more important than getting it right. That's how things like std.json ended up in the standard library. Then it changed to "it's got to be perfect" and that causes frustration and makes willing contributors quit.

The answer is to make major changes to the development process.

On 26/12/2022 4:54 AM, GrimMaple wrote:
> BetterC is the worst offender here, basically locking your framework to itself. Considering you want to make a universal framework. This is why phobos is so hindered at this point. You can't add anything to it because somebody would complain that it has to support betterC.

That is entirely incorrectly.

Nobody expects things to work in -betterC in Phobos. The only exception to that rule are things like std.traits which only operate at CTFE and should have no differing behavior based upon what flags are passed.

We can't add things to Phobos because of leadership. In the last 10 years we have only added allocators and loggers to experimental, and only one of them was complete enough to come out of experimental. It has nothing at all to do with some flag why we can't put things in. It has always been a nightmare.