> 2/3 of issues you showed are purely formatting concerns

This is a bald-faced lie, and one can see that by following the links I provided.

A "formatting concern" is changing indentation or splitting a long declaration over several lines.

The issues I've shown, and the majority of others, are actual bugs that are fixed by altering code.

> "test.written" refers to test being written in a testing framework, "status.tested" means that the described bug was tested in multiple development environments and confirmed. So your remark is slightly off the base.

It's entirely on point. Code for the fix is written, the issue is closed. The commit is merged into master branch. No tests are added in the commit that fixes the issue.

When are exactly tests for these changes "written in a testing framework", if ever?

I could count the tests until I'm blue in the face, but the fact remains: next to no tests are written for issues that are marked as fixed, and closed. And if you view the commit history, well, it's mostly fixes, and some superfluous tests remove. No commits show any tests added (I know such commits appear sometimes, for larger features).

> hence there isn't much contributors ready to provide the code of acceptable quality.

I don't even know how to comment on this

> This is a stumble block for other contributors, which, alas, will be moved away only after 1.0 is reached.

So, not in any foreseeable future. Original plan to release 1.0 was last year AFAIR. Then that shifted to release 0.6.5 AFAIR which is still not released.

So:

- contributors aren't willing to provide code of acceptable quality for any foreseeable future

- there won't be any acceptable quality, or even such an important thing as comments, for any foreseeable future

- there will rarely be any tests for any of the issues found and fixed for any foreseeable future

See why my skepticism about Red is not unfounded?

> Reading Red code requires a prior knowledge of function's arity and evaluation rules; ambitious projects require knowledge of multiple dialects and thorough understanding of core concepts; dynamic pieces (i.e. metaprogramming) can be challenging, unless you're coming from Lisp or Forth camp.

Do not confuse Red with Lisp. Lisp (and even its expanded dialects such as Clojure) have clearly pretty much defined rules on how to read code.

No "previous experience" with Red will let you parse the "simplicity" of

OS-draw-brush-pattern DC size crop-1 crop-2 word as red-block! cmd sym = fill-pen

> another 2 cents to your "lack of contributors".

It's not "2 cents". It's yet another weak attempt at finding excuses instead of facing criticism face on.

There's a reason I gave Elixir as an example. You could view it as a one-man show, as one contributor, the author, has an overwhelming input into the project compared to all other contributors.

However, it doesn't prevent him from:

- writing acceptable code

- writing tests for the fixes he provides to issues

- writing comments in code

What this result in? Well, even the issue I referenced: it was reported and fixed, and documented not by the author, but by a different contributor. A miracle, by Red standards.

> Hope that answers your concerns, more or less.

Nope, it doesn't. It's a string of excuses, and see the concerns about the foreseeable future above.

> [1]: https://github.com/red/red/tree/master/tests

Which of the tests contain the test for the "Malignant output from react/link"?

Or, and I swear to God, I found this by pure accident trying to be snarky and digging up some old issue: your own reported issue, https://github.com/red/red/issues/3211

It was fixed, with no tests, and don't tell me it was "formatting concerns". So, which of the red/tests contain the test "being written in a testing framework"?