This is at the root of the infamous "Blogging vs. blog setups" comic https://rakhim.org/honestly-undefined/19/.

The fact that this is true is also the entire basis for wikis. It is reasonable to find it irksome that people, perversely, refer to Git repos full of Markdown documentation as "wikis"—which they aren't. They are fully the opposite.

More people are (finally!) coming to the realization that GitHub repos full of Markdown and the edit-via-pull-request anti-pattern is not a substitute for a real wiki.

What even is a locked wiki insofar as the ways it differs from traditional (pre-wiki) content publishing pipelines? Where's the wiki part of it?

See also: wikis[1] vs anti-wikis

1. https://www.colbyrussell.com/2020/05/13/psa-wikis.html

To drive this point home:

I sometimes get people who balk at my characterization of GitHub-style anti-wikis as being inferior to, you know, actual wikis. "You can just use the GitHub UI to edit the files", they'll sometimes say.

A case study: a couple days ago, I noticed that the lone link in the current README for Jeff Zucker's solid-rest project is a 404. I made a note of it. Just now, I reset my GitLab password, logged in to solid/chat, and notified Jeff https://gitter.im/solid/chat?at=611976c009a1c273827b3bd1. Jeff's response was, "I'll change it".

This case is rich with examples of what makes unwikis so goddamn inefficient to work with. First, my thought upon finding the broken link was to take note of it (i.e. so that it can eventually be taken care of) rather than fixing it immediately, as would have been the case with a wiki. More on this in a bit. Secondly, my eventual action was still not something that directly addressed the problem—it was to notify someone else† of the problem so that it might be fixed by them, due to the unwiki nature of piles of Git-managed markdown. Thirdly, even Jeff's reflex is not to immediately change it—much like my reaction, his is to note the need for a fix himself and then to tell me he's going to change it, which he will presumably eventually do. Tons of rigamarole just to get a link fixed‡ that remains broken even after having gone through all this.

† Any attempt to point the finger at me here (i.e. coming up short from having taken the wrong action—notifying somebody rather than doing it myself) would be getting it wrong. First, the fact that I can't just make an edit without taking into account the myriad privacy issues that GitHub presents is materially relevant! Secondly, even if I had been willing to ignore that thorn (or jump through the necessary hoops to work around it) and had used the GitHub web UI as prescribed, it still would have ended up as a request for someone else to actually take action on, because I don't control the project.

‡ Any attempt to quibble here that I'm talking about changing a README and not (what GitHub considers) a wiki page gets it wrong. We're here precisely because GitHub's unwikis are a bunch of files of markdown. The experience of changing an unwiki page would be rife with the same problems as encountered here.

Contribution: make it a wiki. (An actual wiki, not GitHub-style anti-wikis.)

Nah, dude. That's not a wiki.

There are way too many dipshits who are way too happy to come out of the woodwork when this topic is brought up to try to drop an FYI wisdom nugget on you about how github.com will let you skip a few of these steps and do the edit/commit thing directly in your browser. Great job on almost entirely missing the point, morons. Let's be excruciatingly clear:

If, at any point, "submit a PR" comes up during an explanation of how to do a run-of-the-mill edit on your project's wiki, then your project does not have a wiki.