> Almost all issues are fixed by the same two people who develop Red.

Let's look at the reality by taking all the fix commits (prefixed with "FIX:") on red/red repo in the last 6 months and grouping them by author:

qtxie : 97
dockimbel : 39
bitbegin : 21
endo64 : 6
Rudolf : 6
Toomas : 4
greggirwin : 3
semseddin : 3
FLuX LoOP : 2
Vladimir : 2
x8x : 2
PeterWAWood : 1

qtxie and dockimbel are the two main contributors to the repo, they weight a total of 139 commits, while the others together total 50 commits. This gives the following ratios:

main ones : 73%
others : 27%

So more than a quarter of the last 6 months fixes are made by other than the two main contributors. So much for the exaggerated claim...

> Perhaps it's due to the fact that about zero percent of Red code is documented?

So comments don't count as documentation now? See my other replies for the comment stats.

> Or that "Code written by experienced users (and Red codebase in particular) is a hard nut to crack"?

10 different non-main contributors provided 27% of all the fixes in the last six months. They must be incredibly smart or, maybe mind readers in order to achieve that, right?

Let me propose another explanation: maybe the source code is not that difficult to understand, as you desperately try to misrepresent it in this whole thread? Maybe, with the help of the rest of the community, contributors can figure it out, even with low amount of documentation?

Maybe your all rambling here is just is because you wanted to contribute, but expected a "first-class" treatement, didn't find a full documentation offered to you on a golden plate, so went on a bashing/trolling session here on HN, in a pathetic attempt to discredit our work? That sounds as a likely explanation of your passive-aggressive tone, dishonesty and wilful ignorance in your posts here.

> It's a one-line fix. So, surely, it could be fixed by someone else but the author of the language?

Lol...that's hilarious. So the author of the language is forbidden from making fixes to his own creation, like a oneline-fix if he wants to? No kidding! The way that specific ticket was reported could have let think that the root cause could have been a deep issue in the reactive framework. So, while screening the tickets, as the author and maintainer of the reactive framework code, I identified this ticket as for me to explore, then ran the code to reproduce the problem annoying the reporter, and immediatly identified an harmless excessively verbose output on reactions processing errors. At this point, stepping into the code to make a one-line fix was the right thing to do, as I already spent time on investigating it.

> 336 lines of no significant comments other than trivia for the author himself.

How dishonest again... What you call "trivia for the author himself" are actually very important comments, as they are good clues for some more complex parts of the code. So now, even when you find comments in the code, you dismiss them as "not significant" and "for the author himself"... Moreover, you don't mention the 20 docstrings that document the public functions interface in that file, nor the full reference documentation [1], that cover all the features implemented in that file...

> "New line flags not cleared" whose fix is just a few lines? Oh, it's in a 3000-line file with no comments

"no comments"? I count 125 lines of comments there...more dishonesty. This file is the recipient for the low-level part of about 100 "native" functions (`native!` datatype at user level). All those functions are independent from each other. Their size ranges from 2 to 90 lines, with a significant number of small trampoline functions, and the code there is very explicit. Each native's interface is fully described with docstrings in [2]. If there is some significant extra commenting efforts to do in the codebase, it's really not in this file.

> And since very very few of those lines are covered by any tests (even for issues reported and fixed)

Proven wrong in details in other replies.

> how is anyone except the two authors can ever fix those issues or contribute?

Demonstrated at the beginning of this post.

> If "Code written by experienced users (and Red codebase in particular) is a hard nut to crack", how can you expect people to believe in it's "simplicity and fun"?

That's a non-sequitur. A complex system can have a simple user interface. In our case, most of the codebase in written in Red/System, for system programming purpose. System programming is far from simple or fun for most people, yet that has no bearing on Red, which lives at a higher abstraction level, and that users are enjoying for its "simplicity and fun". Can Python be simple to use, even if it's implemented in complex C code?

[1] https://doc.red-lang.org/en/reactivity.html

[2] https://github.com/red/red/blob/master/environment/natives.r...