Statistically speaking, this requires that we have a sufficiently large number of contributors. Otherwise, we are more likely to have a description of individual prior knowledge profiles and individual interests than a statement about the usefulness of our tools or action strategy.
Well, yes, the entire initiative is based on improvement of collaboration—collaboration between different skills and areas of interest and the adaptation of communication channels and process rules.
Well, I would say yes and no. Yes, because it offers a wide range of functions, and no, because you only need a small part of it for documentation. Unfortunately, we are currently confronting contributors with a huge, steep mountain, without it being immediately obvious that we only have to climb the first few meters on well-maintained paths, albeit currently without any signposts along the way. And we need to change the latter for contributors.
You don’t need to know anything about those to be able to contribute to docs.
I never counted it. The numbers are impressive. And yes, at first glance it is chaotic and completely opaque to anyone who has not been involved in its development over decades,. And over decades there used to exist no systematic and comprehensible documentation about all the internal working. The knowledge is in the heads of the “old hands,” and even then in idiosyncratic terms and abbreviations. ‘Newbies’ have to figure out how to get the information somehow. This is the state of affairs after two decades of “creative” development, and perhaps due to a lack of internal integration and identification. Unfortunately, we cannot solve this with Docs. This is a task that Council should tackle—and has already done so, e.g., with the Forgejo initiative. And over the last years we got a lot more internal documentation., albeit difficult to find amid all the “chaos.” The latter is basically a matter of curation, and therefore possibly also Doc’s concern.
And ultimately, it is also an expression of insufficient resources, perhaps most visible in the slow performance of pagure, bugzilla, and SSO. This repeatedly leads to individual special solutions and, initially, perhaps temporary solutions, which then develop a life of their own.
In the end, what looks chaotic at first glance has rational causes and its own structure when you take a closer look. And the situation is improving, albeit (still) in small steps.
As docs, we have to make the best of this situation pragmatically and thus also contribute to overall improvement. And we can raise awareness that what at first glance seems chaotic and perhaps daunting has its causes and its own order in the background. And it is perhaps also an inevitable unintended side effect of the intended high rate of innovation in Fedora.
Unfortunately, this ease of use comes at the price of a drastic reduction in design options and has actually become superfluous today.
DocBook and SGML (a superset of HTML), which were initially used in Fedora, have significantly more standardized design options than any Markdown or AsciiDoc language. And to ensure that you can still create reasonably attractive and readable pages, there are extensions available, although these are CMS-dependent.
A nice example is Antora, that Fedora uses. It offers a wide range of proprietary notations for various text sections, references, etc. With HTML, one could, or rather would, have all of this in a much more powerful and standardized form, i.e., independent of the CMS used. And the height of irony is that this simplified markup is then converted into HTML in a (complex) transformation process.
In the past, these simplifications were helpful in enabling inexperienced users to write posts without having to learn the relatively complex rules of HTML. Today, there are a multitude of HTML editors with varying levels of functionality available everywhere, making it irrelevant whether the text is saved in AsciiDoc, HTML or whatever. And these editors are now also available for simple text requirements such as discussion forums. This simply does not mean any additional effort for the program developers.
A tool improvement solution today should therefore focus on handling text editing with an appropriate taskbar, e.g., AsciidocFX. And either with a small extension or with an external tool, replacing the whole Git fuss with “upload,” “download,” “update,” and executing the necessary Git actions on top of that.
However, this initiative cannot achieve all of this. But perhaps some of the partial steps can be achieved or at least supported by Forgejo.