[Bug] wiki only partly updates content changes

[toby63]

I noticed that the timeframe between changes in the wiki and applying them in the public version seems to be very long.
To long in my oppinion.

@Krzmbrzl described the problem (in: mumble-voip/mumble#4145 (comment)):

We're having some caching issues with the wiki that leads to changes not being overtaken for everyone but the author of these changes for some time...

This applies to an entry he edited 12 days ago and it is still not upstream.
https://wiki.mumble.info/index.php?title=Installing_Mumble&curid=1313&diff=10209&oldid=10202

Could you describe in more detail what the problem is?
Or is this intended?

---

Potencial Todo:

• check logs for conspicuities
• check version of wiki software (including database, OS etc.) and maybe update
• (optional) reset the wiki (while keeping the content of course)
• clarify whether there is a manual approval for content changes or not
• clarify if and what timeframes are set for content updates etc.

[Krzmbrzl]

I doubt that this is intended. I agree that it does indeed take way too long to update...

On the bright side though our plan is to drop the wiki anyways and migrate the docs to our website directly (and the Dev related stuff goes to GitHub).

[toby63]

On the bright side though our plan is to drop the wiki anyways and migrate the docs to our website directly (and the Dev related stuff goes to GitHub).

Hmm...it's your decision of course, but it will be even harder for people to add and edit stuff then.
Because not everyone wants to create forks, commits and pull requests.

I would take an approach where you have an (interactive) wiki, but you can also easily convert stuff from the wiki to the website.
So you could pick the parts you think are very good.
Don't know though, if something like that is existing.

[Kissaki]

I would expect content to only be outdated for up to an hour, or few hours. If it is longer that sounds like an issue to be. Not intentional or accepted.

[Krzmbrzl]

Because not everyone wants to create forks, commits and pull requests.

Well Markdown files can be easily edited in the GitHub web-interface and that way people won't even get to know that they're actually working with forks :D

I would take an approach where you have an (interactive) wiki, but you can also easily convert stuff from the wiki to the website.
So you could pick the parts you think are very good.
Don't know though, if something like that is existing.

Nice idea, but I don't think this is going to happen. We already don't have the man-power to manage all tasks properly and that would add significant overhead to the list.

I agree though that we should make (at least) the "wiki" part of the website's repo as accessible as possible ☝️

[toby63]

On Topic:
I just noticed a curiosity:

• my new page about audio is public
• but other changes are still not public, see for example: https://wiki.mumble.info/wiki/Installing_Mumble#Debian

Off-Topic:

Well Markdown files can be easily edited in the GitHub web-interface and that way people won't even get to know that they're actually working with forks :D

I did not think about that, but still it can be more complicated.
In a wiki you have an easily readable and comprehensive changelog for each page, where you can simply click "undo" etc..
And also changes are applied instantly, though they might not be public (depends on settings).
On github you see dozens (or even hundreds) of unsorted pull requests.
(that said I don't know, maybe you have some fancy features to manage that; but still for others it can be confusing (because they maybe overlook that (and what) another user has already added (with an (open) pull request)))
I would still advice to keep the wiki (if it is working correctly again some day).

[Krzmbrzl]

On github you see dozens (or even hundreds) of unsorted pull requests.

Not true. You'll have a per-file based history as well. You can even see a per-line based history within a file.

[toby63]

On Topic:
Something is wrong with your wiki.
Now I noticed that some changes are applied, but not visible in the history of the page and vice versa.
Example 1:
https://wiki.mumble.info/wiki/Murmur.ini
Now includes my changes from here.
But does not show it in page history.
Update: It gets weirder, when I click show in the history, my changes are shown...

Example 2:
https://wiki.mumble.info/wiki/3rd_Party_Applications
Does not include an entry about "Wahay" but history shows that it is included:
https://wiki.mumble.info/index.php?title=3rd_Party_Applications&action=history
Cotopaxi : (→‎Clients: Added Wahay)

I would like to have a clear answer to one question:
Are the changes approved by someone before becoming visible?
This is the easiest explanation for me, why some changes are visible and other changes (that are older) are still not visible.
Otherwise there is a more or less serious technical problem.

---

Off-Topic:

Not true. You'll have a per-file based history as well. You can even see a per-line based history within a file.

I guess you missunderstand, I am not referring to already merged changes or changes inside one pull request.
It is known that git was build for that purpose.
I am referring to non-merged pull requests.
A comparison:

1. If you use a wiki, you see all the changes (even the ones that are not "merged") perfectly listed, so everyone can see what others already changed.
2. If you use github, you see all the (potencial) changes (from different users) just as unsorted pullrequests (as long as they are not merged), so you would have to search explicitely for things, to know whether someone already proposed the changes you want to write.

Maybe I am also wrong about this and there is a fancy method in github or git, but then I advice you to point users to it, because otherwise they will have the same problem I just described.