I agree. I know some people, who are good at writing, who were going to opt out of another documentation project if Git was used as the means of collaboration because they felt it was an unnecessary barrier to entry when a wiki is so much more straightforward.

In the end we did use Git for documentation (pressure from devs), and in practice the non-devs tried to stay involved but ended up letting "technical" people do all the Git and diffing stuff, so it remained a practical barrier to involvement in the documents.

People who are used to Git and development in general tend to forget that a lot of tools we take for granted, including text editors, terminals and command lines, are completely alien to non-developers and not everyone wants to learn that stuff for just one project.

I've known developers struggle with Git too (when they don't use it often, or it's only used for 1 out of 10 of their projects), so I agree it can be a fairly high barrier.

I'm assuming the intended use-case will be clicking on a shortcut to Github's integrated "Edit & do pull-request" function embedded in the MDN website pages, and write one's edit in the Github editor GUI, which isn't bad.

Anything closer to having to make a manual Github pull-request would be incredibly unergonomic for someone without an existing CLI setup for Github (ie. most developers).

I built a Wiki based on Mercurial years ago; it's not too hard to just build a web interface in front of it: it was just a thing to learn me some Ruby at the time. In many ways it's just an implementation detail, but I don't know if the MDN people are planning anything of the like (but MDN is for tech people, so I don't think it's a problem there).

The big upshot is that all the hard problems like merges and history/diffs and whatnot are solved for you by the VCS. I don't think MediaWiki allows you to "blame" anything for example; something I've often wished for. It's just a whole class of problems you don't have to think about.