The conditions around the “Workstation & Spins” guide have changed a bit. Especially my own contribution will in future be limited to finalizing the Web-UI installation guide before Web-UI’s release & processing merge requests or tickets related to the Workstation & Spins guide (including the Web-UI guide). I also can maintain the major pages of this guide in terms of checking and setting outdated/false content offline if we agree on such an approach. Unfortunately, my workload in other areas has strongly increased.
Therefore, we have to adjust the approach to have something that on one hand can be published without the risk of providing misinformation, and on the other hand, also adds value for the users even without much content from our side. The problems of this guide and more generally guides around workstation & spins go beyond its boundaries. Or in short: there is a reason why we have not yet such a guide for our major edition. So the issues are “overarching”.
The draft for the new approach is pushed to staging (wait an hour after this post): https://docs.stg.fedoraproject.org/en-US/fedora-workstation-and-spins/
What does this change tackle and thus, what does it contain?
Issue 1:
Our “good first issues” on gitlab are not worth much. The target audience of this guide is rarely used to work with and on gitlab. Even if they use the guide, they are unlikely to checkout the gitlab board. However, the target audience (such as the people on ask.fp) is often not very “secure” around the institutions of Fedora and Linux in general: people avoid to engage or actively approach others if they are unsure what is expected from them and what they have to expect in response. The latter problem fosters the first, and it also fosters that the audience will seldomly end up at “how to get involved”-type pages.
However, on ask.fp, I experienced that if we let average users know about specific tasks they can do to contribute at the places we are in contact with them, especially if these tasks are related to their needs, there is a large interest to contribute. E.g., this is how we could effectively contribute to tackle the asus_ec_sensors bug in the kernel.
How to tackle issue 1 & exploit the described tendency towards collaboration:
Formatting, language improvements and comparable activities can take a lot of time in authoring Docs. But most users can do that. On the other hand, I’m quite sure most of our audience does not feel sufficiently secure to author the technical content themselves. So, in order to give an incentive what they can contribute at a place they are likely to find it, I have added the first two pages of the new install guide, which are drafts for the future Web-UI guide (these two pages are not Web-UI specific and are a type of independent “getting started” that fulfills its purpose already now). To make clear about the issue, I have added a clear CAUTION box in the beginning:
This page is maintained and its content is kept up to date. But it is considered as draft because there is still work to be done: formatting and language improvements. Feel free to contribute! You do not need to pick up any responsibility or maintenance! If you additionally want to split the page, open a ticket!
Imho, we owe the users to maintain content to ensure that nothing contained undermines their problem solving and that everything is correct and sufficiently up to date. However, having content that is not perfectly formatted cannot undermine their problem solving, and most important: it tells them exactly where they can contribute and with what! And they know in advance what is expected from them, and what they can expect.
If this works out, experienced technical authors can very effectively team up with average users who are on these pages later (content still fosters SEO, even if not perfectly formatted). This saves time for technical contributions and already adds value for the users from the beginning.
Examples: Why Fedora Linux? , Which Fedora edition, spin, or lab to download? , How to create an installation media?
→ Btw, @pboy , I already implemented your proposal for splitting the pages. You made a very good point about that. I also split some paragraphs as you suggested.
Issue 2:
The “current Docs” for “Workstation & Spins” are in fact ask.Fedora - this is what currently incorporates that role (whereas experienced users go upstream or know how to interpret and where to apply Quick Docs). Demand has clearly shown that. My interpretation from feedbacks is that there is a “traditional Docs” demand for everything up to the installed Fedora. But in other cases, the stable “constant” is ask.fp, which has proven to satisfy most of the demand of users.
I think in this respect, even if it hurts, we should not try to tackle that or to compete, and always keep in mind that Docs shall serve the users, not vice versa. If it suits the users, why try to change that: ask.fp and Docs have the same interest. So, we should avoid to compete but think on how we can identify and fill the gaps, to complement the users’ problem solving (one issue at ask.fp is that there are often more cases than available supporters can tackle, whereas on the other hand, a lot of time is wasted to tell the users what information we need to help).
How to tackle issue 2 & exploit incentives and common ground:
The guide is already from the beginning problem-oriented. However, creating many more pages is at the moment not feasible. The above approach can facilitate more over time if it works out, but I question if it will ever cover everything that would make it a “full scale guide”. Advanced users go upstream or know how to interpret Quick Guide pages (including what is up to date and what is only indicative), non-advanced users on the other hand depend on ask.fp: identify what is the upstream for a specific problem is a skill! Interpreting upstream if not intended for beginners, such as systemd, can be a skill, too!
Yet, given ask.fp’s structure, it remains hidden for many problem-oriented search queries on search engines. Further, especially less experienced users often provide not the type of information that is necessary for problem solving when opening an ask.fp ticket: this takes time from both them and supporters.
However, we can create a “catchment basin” so that users can arrive at our guide. Over time, we can increase the number of pages around problems that we can tackle directly without forwarding users to ask.fp. However, if we cannot tackle a problem, we can still create pages that let the users know about both ask.fp but also which information to provide when opening an ask.fp ticket to reduce the amount of time and posts necessary from both users and supporters → Examples: Installing Fedora & post installation , Issues around Update, upgrade & package/software management
The strong & successive alignment avoids competition with ask.fp, follows the demand we know, and maybe facilitates cooperation. I saw that our changed approach in general already facilitated some some merge requests from ask.fp seniors and others, which I really appreciate! Maybe a stronger alignment can increase that. If we additionally also fulfill indirectly (but of course not only) the role of a squid, this might also facilitate that average users start to contribute more (if complemented by the above two issue approaches).
A slight note: I mean “problem solving” in a generic way, so how people process issues & get their goal implemented, not only with regards to problems on ask.fp.
I have already adjusted the index page to incorporate the approach. Yet, I think the index page needs another revision before publishing (I had to be a bit rough yesterday). However, I think the index is already understandable.
I hope that makes sense! If anything is not comprehensible or so, let me know so that I can elaborate. Of course there is not just the “take it as it is or leave it” possibility, any idea for adjustments will be appreciated!
So, what do you think of that approach for the beginning? It is something that can be published, might facilitate contribution & collaboration (at two places), but also adds value itself from the beginning and actively helps users to solve issues/problems or to get their Fedora customized the way they want it. And we have something contained that creates incentives and can develop over time, without having obsolete content that has become misinformation (which, at the worst, can hinder the problem solving).