Please re-enable the GitHub Wiki feature to better document long complex discussion threads

[xpseudonym]

Is your feature request related to a problem? Please describe.

There are a number of discussion threads which span years on complex topics with hundreds of posts. They tend to be given the misnomer of 'Wiki' which they are very much not - they appear similar to the 'Talk' pages that sit behind what is published on Wikipedia. Because of the complexity of the topics, depth of discussion and volume of posts they defeat the purpose for which the misnomer suggests they exist - to provide knowledge to a reader on a topic. They fail in that because reading through the discussion thread, a reader has forgotten the begining by the time they get to the end.

The problem is that a discussion thread does not fulfil the need that a Wiki fulfills and the Wiki feature has been turned off and so there is nothing to fill that need.

Describe the solution you'd like

Turn the Wiki feature back on please.

Describe alternatives you've considered

Discussion threads, see above.

Additional context

Why the Wiki feature was turned off is subject of the issue. Whatever the reason, it seems likely the decision was taken before discussion threads grew to hundreds of posts spanning a number of years. Obviously these are ongoing and open topics which were perhaps not anticipated and about which readers are looking for concise answers. Here are some early candidates:
#5439
#6817
#3487

[szaimen]

Hi, as I said the wiki feature was disabled by purpose because we don't use it in this repo.

The main docs entrypoint is maintained directly in the repo: https://github.com/nextcloud/all-in-one?tab=readme-ov-file#nextcloud-all-in-one.

However we link back to the wiki section in dicsussions: https://github.com/nextcloud/all-in-one/discussions/categories/wiki.

The main idea with that is that anyone can create and maintain articles without us having to maintain them ourselves. Additionally, it is intentional that people can respond under the articles because then related questions are also maintained in the correct thread. However usually the main article of the wiki article is in the top post so you don't actually need to read through all posts below it.

I hope this explains why we structured things in this way.

[xpseudonym]

Hi @szaimen , Might you be amenable to us creating a "podman.md" file that all of us can collaboratively edit to represent the latest "how to for podman" without needing a specific owner?

[szaimen]

You mean in this repo directly?

I am not sure if that makes sense as podman is not officially supported.

However I just invited you to the repo and gave you write access so that you should be able to edit #3487 (comment) and other posts yourself.

[xpseudonym]

I'm sorry, I find the whole discussion thread thing a complete head fcuk to be honest - I've already spent a unproductive w/e trying to work my way through it and failing. I'm not sure I understand the difference between it not making sense to have a podman.md and it making sense to have a podman discussion thread. idk.

[apparle]

@szaimen Yes it's not officially supported and I think we can put it as a large heading disclaimer stating that (example below).
There's quite a few users like myself who do use AIO via podman, and actively discover/fix/workaround issues. Rather than us sharing issues/workarounds/fixes via messages which are generally hard to discover, having a single point for podman documentation will allow us users to collaboratively edit and put documentation in one place in an up-to-date manner without requiring you to provide edit permissions on others' comments sporadically.
And it'll also let you and others in dev team gauge the status of podman in a single place, if you ever want to consider officially supporting podman.
I'd be happy to create the first version of the documentation, and sign-up to review future PRs to it.

---

⚠️ Warning: Not officially supported or maintained!!! ⚠️

• Podman is not officially supported or tested by the development team, but only maintained by community members occasionally.
• It is known to break often & silently until a community member discovers issues and works-around them if possible.
• Depending on the development of AIO features this whole path may become abandoned with no possible fixes, especially if docker & podman behaviors diverge significantly.

---

[leoniscsem]

I would like to chime in here and add my considerations. Anything that deserves the name of "knowledge base" is highly welcome, and it does not matter to me in which form this is implemented, I would happily contribute to that. The current state of affairs is an unholy mess, in German we call it "Saustall" (pigsty, pig stall). Unless I keep my own notes where to find what and which thread or issue leads to which solution it is simply not possible to keep track on what is going on.

Please let me explain why this matters to me/us: We deploy Nextcloud - among other, possibly more complex software stacks - for clients. As of now, we have deployed AIO only with two SME "friendly customers" since they are integrated in our own knowledge base and we use them as a test area, whereas everything else goes on native Nextcloud instances. Would I deploy AIO on regular client systems? Certainly not.

One of the main reasons is that I cannot point any client anywhere to look up solutions for issues in a viable amount of time. It is simply not possible to build up our own knowledge base with a reference of 3-4 issues for problem XYZ. First of all, they would tell us "you guys suck and deliver horrible services" and secondly, the Average Joe Small Business Owner would react with: "I knew it, Open Source is just trash maintained by hobby programmers, I go back to Microsoft/Google/whatever".

There are many design decisions in AIO which are mysterious to me, and not maintaining a proper Wiki is definitely one of them. I am sorry if this sounds like harsh criticism, which is not my intention, but there are some realities we have to face. If we just go back to basics such as ITIL or COBIT - a software project without proper and usable documentation is worthless.

Anything that doesn't require constantly cloning a full repo and filing PRs is doable for me, and I would happily and diligently contribute to that.

[imfbsbn]

It's unfortunate that this discussion has not received a lot of traction. Such is the nature of things with everyone plugging away in their own little kingdoms. While I certainly understand "management's" position, xpseudonym & leoniscsem make excellent points worthy of further discussion.

First off, mad props to szaimen. Nextcloud AIO is absolutely f######g amazing. As one of the (very) early adopters I've personally experienced all the hard work that has gone into it over the years. Further, as a "non-coder" "non-developer" the simple elegance of AIO stands out in an otherwise crowded field of wonky OS software.

But this idea of podman not being "officially supported" to the point of discouraging an appropriate knowledge base is not a wise decision in either the short or long term.

@xpseudonym makes excellent points that should be considered further. Specifically the incredible advancements the podman developers have made over the last few years & podman's better security, tighter integration with the OS, and quadlets.

Don't expect the situation in 2030 to be the same as it is today. Some of us are old enough to remember swapping floppy disks and starring at a green or amber CRT monitor banging away on an old IBM with 512kb of memory.

In the 1990's IT purchasing agents would often say, "No one ever got fired for buying IBM." But even the massive buying power of international corporations could not keep big blue's computer business afloat.

Today's CTOs say "No one ever got fired for using Docker."

That situation will change as well. It's only a matter of time. Actually, it's only one significant hack away.

As @leoniscsem accurately pointed out, companies - particularly American companies - will not use AIO (they want high availability and greater redundancy.) Undoubtedly NC "management" understands that. Perhaps this is a strategic decision of theirs. So be it. However while they may not realize it, it could turn out to be a "bet the company" decision.

In the future those with the greatest flexibility win.

It would behoove NC to not shun those who seek only to expand the AIO universe.