Not really. People say stuff like this, but what they're really talking about is their own familiarity with GitHub (in the vein of <http://lighttable.com/2014/05/16/pain-we-forgot/>).

What GitHub has going for it is that it is familiar to ("a majority of"?) working developers, and that it's better than both the competition and the Git CLI itself, but from a reality-adjusted perspective, GitHub is pretty bad, too. (Then when people like me make comments like this, others wrongly infer that it comes from a history of false starts and firsthand frustration, unable to conceive that anyone would speak up on this sort of thing if there weren't something personal at stake; no way that it could just be the result of empathy for the uninitiated.)

It's pretty tragic that we've basically killed wikis —like, actual wikis—and regressed back to directories of text files managed by version control systems originally meant for handling program source code. That people then go on to call these wikis is basically an insult to history.

52028d35999a481e7cb19b14eae3bf66cb7c9c4fe2e15b56b55f3ccadffeee1f

Interestingly, Microsoft has a product called TFS that has a great wiki implementation: it's native markdown (with github enhancements), a decent in-browser editor/viewer, and it's backed by git. Plus it has some nice features that let you refer to people with the at-symbol (@) and work items (bugs, tasks, stories, features, etc) with a hash symbol (#), and some other stuff. Github itself has some of these features; I'm not aware of anything else like it (Tiddlywiki, ignoring it's unusual runtime, may be the closest that I'm aware of).

I disagree. I think TFS is an abortion geared around project managers with dev features bolted on. The wiki is ok if you’ve never used other products and their optimizations require an understanding of TFS’ project management suite. I’ve never been able to teach non-TFSers how to use the wiki who don’t commit to learning TFS.

Yes, TFS is overall a survelleince produce for managers. However, that has nothing to do with the wiki implementation included with it, which is quite good. Don't throw the baby out with the bathwater.

I found it hard to use for the primary goal of a wiki: allow contributors to contribute. Wikis need diverse SMEs and it was hard to get SMEs to understand how it worked well enough to contribute and edit content, much less organize. Was able to do this with confluence, mediawiki, and tons of other wiki sites

I mean you could have stuff that requires prs, but you could just use the ui pretty much like a wiki.

1. Go to dev branch

2. Find file and edit it

3. Commit change

That's not "pretty much like a wiki". That's the antithesis of a wiki. You've just described what the wiki was created to replace.

That seems a little drastic, how is it the opposite of a wiki?

What are the steps to edit a wiki? Click edit page, make changes, add comment and submit. That sounds like almost the exact same steps to me.

Try actually measuring it. Fix the 404 link:

https://github.com/solid/solid-rest

(It's the only link in the file.)

Make sure you don't have your thumb on the scale.

The unwillingness to venture into territory that would make the previous claims quantifiable (and falsifiable) is noteworthy.

    $ sha256sum "./PR?-ORLY.txt" 
    52028d35999a481e7cb19b14eae3bf66cb7c9c4fe2e15b56b55f3ccadffeee1f  ./PR?-ORLY.txt
    $ cat "./PR?-ORLY.txt" 
    Did you commit to source control and submit a pull request to post this comment?

Until you need them to rewrite history because it consists of 20 "fix" and "update" commits.

Then don't need them to rewrite history? That's kind of on you and your own OCD at that point. If you are making them use a PR workflow anyway, become friends with git options like using --first-parent to shallowly traverse the DAG and let git's tools give you a clean view. (Or use GitHub's PR Squash options, if you really must rewrite history.)

Someone that does that isn't going to meaningfully rewrite the history anyway, just squash on merge.