We are forking D

[H. S. Teoh]

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

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