Removing the outdated installation guide from the public docs site.
This was suggested by Chris some time ago. At that time, I was against it. Despite our new content and structure, the old installation instructions continue to cause misunderstanding and confusion. It’s always workstation users (as far as I’ve noticed) who can’t find the information they need on the workstation doc pages and fire up the search engine they trust, and then find the version 36 instructions.
I got an impression that the docs that need to be ditched are quickly called out, but there is a lack of interest in maintaining them or asking for cross-team efforts.
It is so easy to say “get rid of that outdated pages”. But anyone who suggests removal of docs does not seem to care or repurpose the docs that are not up to date.
From a recent issue ticket about QuickDocs maintenance, there was a great idea propped up using devel-mailing list.
I like that idea. On one hand, having a general “weekly topic” that is not dedicated to any other topic allows us some meeting-like decision-making (or at least developing towards decision-making) that also creates more incentives for the remaining community to review and/or participate. On the other hand, we are more flexible compared to the “real” meeting where we have to be at the very same time at the very same place (Peter will confirm that Zodbot is not known to be a good interlocutor ).
It’s not a replacement of meetings, but I could imagine that it is complementary to make more regularly use of that, maybe even formal if it proves competitive. So to start the meeting-related discussions already here and maybe prepare the possibilities we have to agree on or align with. If I think about it, I could imagine that some topics like GitLab tickets that are marked for meetings or things like that could be already widely discussed+finished in such a “weekly topic” before the meeting (to have more time to focus during the meetings).
Originally, the formal workflow was intended to “reduce” the actual meetings primarily to decision-making, so to formalize and finalize what is discussed in prior (to avoid meetings to peter out in the limited time). Maybe this new approach could achieve more of our original goal. It seems to have developed natively, which is always a good sign… Just some thoughts
As I already indicated, I again do not know if I can participate tomorrow
I think there is nothing to add to Peter’s points. I am +1.
I still have the new install guide on my list and regularly check out the new snapshot from the Anaconda team (they do a great job with the Web-UI installer!). But it is not yet ready to create a guide for. Also, it is clear that the new Web-UI installer will still take some time before it will be part of an official release. But I think it will be realistic to merge the work on a new “marketing booklet” (the one that is to help people to get and install Fedora, distributed on events/conferences) and the install guide because we will need only simple and uncomplicated easy-to-use instructions for any audience (in many cases, we just need to refer to the “?” button, which is already super well elaborated!).
I’ll keep you updated about that. However, I have no interim solution, except referring “beginner” users who need a guide to the live installations (workstation, spins), which are fairly easy to install without much decisions, plus suggesting them to use “automatic” in partitioning.
I have not yet had time to get into the other topics
Design and usability changes/issues ACTION: hankuoffroad[m] will setup a board to dedicated list to track our design issues. (pboy, 18:58:32)
Removing the outdated installation guide from the public docs site AGREED: Docs theam decided to remove the outdated “Installation Guide” from the docs site and replace it by a placeholder page.
See above
