On Tue, Jan 09, 2024 at 07:32:10PM +0000, GrimMaple via Digitalmars-d wrote:
> On Tuesday, 9 January 2024 at 15:01:28 UTC, H. S. Teoh wrote:
> > It's not just the slow procesing of PRs. It's the arbitrary shutdown of contributions after months, often years, of silence, with no prior warning and no regard of the amount of work put into maintaining said PRs over that length of time. And often while totally misunderstanding what was actually done, as is being shown right at this moment with the discussion on DIP 1036e.
> 
> Though I don't have a long-standing track record of contributing to D, my futile attempts to even get anywhere were so painfull I just stopped bothering very quickly. It always sucks to get critisized, but it sucks extra when you're not even told what to do with this criticism.

Well, I *do* have a long track record of contributing to D. I've had not a small number of PRs merged into Phobos and a few in DMD.  I was even given commit access to Phobos (and still have it, though I haven't used it in years) and for a time put a lot of effort into reviewing and merging PRs.

It's not so much the criticism that's the problem -- in any technical project criticism is good and necessary for high quality work, as long as the criticism is justified.  It's not even the slow processing of PRs: as an "insider", I see (or at least, used to see -- I haven't been involved long enough that my information is probably outdated) the other side of the situation.  As a volunteer offering my precious little free time to help D, I simply don't have the time/energy to review big complex PRs. Neither do I have the confidence to review PRs involving areas that I'm not an expert in, such as numerical algorithms. As such, I tend to avoid reviewing PRs that either (1) require too much time/effort, and (2) outside my area of expertise.  I'm sure I'm not the only one who feels this way among the Phobos committers.  So the total effect of this is that large PRs get neglected in the queue, along with PRs that contain controversial changes (as a volunteer, I obviously do not want to waste time merging a PR only to have Walter or Andrei revert it later) or technicalities requiring very specific expertise that only one or two (or sometimes zero) people have.

All of this stems from a shortage of manpower, but that in itself is solvable and isn't the core of the problem -- you just draw more willing contributors and sooner or later one of them will have the needed skills to do the job. Or you gain enough manpower to offload the routine maintenance tasks.

The troubles begin when you're losing more contributors than you're gaining them.  And losing them because of things like somebody in high standing appearing out of nowhere and dropping on you like a ton of bricks because you didn't meet requirements A, B, C, D, none of which were communicated to you prior to your involvement.  Worse, when said person fails to elucidate just what exactly A, B, C, D are beyond some vague, non-actionable hand-waving.  And arbitrarily reverting work you've poured hours into, even though prior to that they were unresponsive when asked for feedback and did not make it clear exactly what was expected of you.  And to add salt to the wound, when you've poured even more countless hours into fixing up your PR to meet the requested changes, only to have the reviewer go MIA (or only give one word responses) for months on end, and then come back later to say no, it's still not good enough, here are additional requirements E, F, G -- none of which were mentioned as issues before.  And to top it all off, when the person rejecting the work does not fully understand what has been done, and clearly has not bothered to try to understand it (because if they did, they wouldn't say the things they did or continue to repeat wrong claims which have already been debunked, often multiple times).

In a commercial enterprise where people are paid to do the work and have to listen to you no matter what, such an approach may not have been as disastrous. (Well OK, people will quit, but at least some would stay just because of the money.)  But when you're dealing with volunteers burning up their free time in hopes of contributing to what they feel is a worthy cause, is it any surprise that people rapidly lose interest in contributing further?

And when even longstanding contributors after years of involvement decide to call it quits, and when this happens not once or twice, but in a continual, recurring pattern throughout the history of D, then you really gotta wonder just *what* is going on.


> Most of the time, D community seems to try and look like it cares about the end user, but in reality (this thread is a confirmation) it's just pointless bantering about something that the end user doesn't care about. More importantly, this pointless bantering is used as an escape goat to shut down changes that DLF doesn't want/like, yet DLF itself never bothers with breakage if it implements some kewl new feature that nobody asked for.
[...]

I wouldn't go that far to say that the DLF doesn't care about the end user.  I'm sure they do, as most of them are users themselves.  The problem is more with the perfectionist ideal of letting the perfect be the enemy of the good.  Contributions that are not 100% perfect are rejected, even when they're already good enough for the majority of use cases. Rather than have a solution that's good enough for the time being, we would rather not have any solution at all until the ideal arrives. If it ever arrives at all.

It's that, plus the problems with communication. Or the lack thereof.

IOW, the core issue here isn't technical -- we have no problem with technical issues, Walter is an expert on that -- it's social.


On Tue, Jan 09, 2024 at 08:02:40PM +0000, BlueBeach via Digitalmars-d wrote:
> On Tuesday, 9 January 2024 at 19:32:10 UTC, GrimMaple wrote:
> > On Tuesday, 9 January 2024 at 15:01:28 UTC, H. S. Teoh wrote:
> > > […] More importantly, this pointless bantering is used
> > as an escape goat to shut down changes that DLF doesn't want/like, yet DLF itself never bothers with breakage if it implements some kewl new feature that nobody asked for.
> 
> There is the vision document from Mike Parker
> (https://github.com/dlang/vision-document)
> 
> I think it’s noble attempt and could be starting point for improvements. But I’m interested in your opinion.
[...]

Over the years, there have been countless such "vision documents" and other similar things.  The more time goes on, the more skeptical I have become that they have any real impact on anything.  They sound just like the typical corporate motivational "visions" that have lots of buzzwords but scanty in actual, actionable details.  You know, the kind of pep talk that your CEO would give at company-wide meetings where he would proudly announce "for this upcoming year, our company slogan will be $buzzword1, $buzzword2 and $buzzword3. We're doing awesome, and we're going to be even more awesome by leveraging $buzzword1 to $buzzword2 the $buzzword3 and achieve even higher levels of $buzzword4 which will blah blah blah ... PROFIT!".  Everybody claps their hands as the soap opera episode^W^W^Wcompany meeting comes to an end: the strawman has been defeated and everything has reset to the status quo as at the beginning of the show.  The next day will be business as usual.

I wish things were different, but our track record isn't looking very promising right now.  I'd much rather look at actual work that's being done, than such documents that we're not actually acting on.

//

Now, to be fair, LOTS of work has been done in D over the past years. Don't get me wrong, it isn't as though D has come to a standstill. There's still lots of good stuff in D, and they're still trickling in. (I wish they were pouring in, but I'll settle with a trickle.) Unfortunately, the fundamental issues like I described above remain unsolved, and from all appearances, unlikely to be solved. We excel at solving technical issues, social issues not so much.  I'm not holding my breath.


T

-- 
Кто везде - тот нигде.