So, they say that the system is evolving, but from these parts of the article I would argue that the ease of contributing (which is the important part) is taking a massive hit:
> "you will no longer be able to click Edit on a page, make and save a change, and have it show up nearly immediately on the page. You’ll also no longer be able to do your edits in a WYSIWYG editor."
> "you won’t have a WYSIWYG to instantly see what the page looks like as you add your content, and in addition you’ll be editing raw HTML"
They had a user-friendly system previously... Now users have to learn GitHub and author raw HTML! - I would point out that not all documentation writers are developers!
I _wish_ MDN had a user-friendly contribution process. My experience has been _far_ from that. I very much welcome these changes.
In late 2017, I spent upwards of 80+ hours standardizing 80 different MDN docs pages so they used the same best-practices layout as other more popular docs pages on the MDN.[1]
Of the 85 pages I updated to have better formatting, over 18 were reverted by random contributors within 2 days with no reason or explanation in the changelog. It was _impossible_ for me to get in contact with the people reverting the changes, because they are only a username.
I tried contacting MDN maintainers on IRC, searching for those users on IRC, and came up empty handed. I was left to make a plea on the mailing list asking for those change authors to get in contact with me, only to receive no response.
I came away from the experience highly encouraged not to contribute to the MDN.
Does MDN/Kuma not support talk pages like MediaWiki? IRC and other live chat options are good for building a community, but for discussing content changes (and preserving that discussion) keeping that discussion on the wiki is really useful. It's a shame if MDN never realised that.
> They had a user-friendly system previously... Now users have to learn GitHub and author raw HTML! - I would point out that not all documentation writers are developers!
So you'll need to know HTML and how to create a Pull Request on GitHub to be able contribute to documentation about web development... I feel like if you're writing about web development topics, that doesn't seem like a high bar to pass.
Well, now balance that against the rest of the upsides they present, like the new UX not being to merely revert the changes that you spent the weekend writing.
Let's stop acting like just because we can think of one downside that we can ignore the rest of the trade-offs. Btw this is a trade-off they already mentioned in TFA rehashed by an HN comment for some reason.
Because HN commenters always feel like they know better and like to talk down on any changes even when they have no context for why the decision was made.
Is higher friction a bad thing though? This is web standards documentation, not Wikipedia; once a document is finished, it'll be a lot more static. I can imagine they've had edit wars (another commenter mentioned it), abuse, etc, whereas with a GH workflow there's a better review process involved.
Its much more than that. Have you seen how many ways there are to write html? So you have to learn their flavor on top of providing the actual information. Thats a good chunk of time that can be used elsewhere. People don't contribute to projects that have bad levels of entry and artificially difficult participation requirements.
TFA goes into why this wasn't user friendly. You haven't responded to their own justifications. You've just reposted a trade-off that the TFA acknowledges and justifies.
> Now users have to learn GitHub and author raw HTML!
Ignoring the fact Microsoft's Github has recently had DMCA insanity, a proprietary frontend, and recently enforced Webcomponents (effectively removing UXP devs who were forced to self-host Gitea just to continue working)... this seems like Mozilla is trying to outsource as much as possible from their own hosting. They also shutdown Firefox Send.
Perhaps Mozilla is having issues / unable afford their own hosting anymore?
One example would be it is not possible to even make a PR request on Github as half the GUI no longer works in non-WebComponents browers. If it were open source we could perhaps see what WebComponent feature they think is missing and implement it in the browser engine, as it is they do not have any desire to collaborate and the black box makes it all the more difficult to debug.
If you've chosen to use a web browser that's forked from an old version of Firefox and isn't aiming for compatibility with modern Web Platform Tests, you're going to encounter a lot of obstacles. The fact that you can't see the server-side code generating the failing client-side code, which you can see, seems like the least of them.
Yeah pointing to what is essentially an issue only in a mostly unmaintained version of Firefox is really disingenuous and sounds like someone complaining about something not working on IE6.
What does creating a PR even need in terms of functionality? It's effectively nothing more than a big HTML form with some inputs, something that's been around and working perfectly fine in browsers for decades.
The other comment here about how it's like complaining it does not work in IE6 is really pertinent: Yes it damn well should, because I should not need the latest technology just to do something that would've been perfectly possible with the technology of TWO DECADES AGO. It should be entirely possible to use GitHub with a text-based browser because none of its interactions require anything more than that.
It's sad that I could probably write a more accessible interface in less time and resources, and I haven't even done much in the way of web development, yet dedicated web-developers with uninhibited trendchasing mentality will fuck it up so badly with this constant need for useless breaking changes.
The PR form has a bunch of quality-of-life features that would be impossible without JavaScript. The reviewers/assignees/labels pickers are JS-based and fetch data on the fly, the Markdown editor with previews also couldn’t exist with JS. Many of those components appear in other pages, and it’s a no-brainer that GitHub wants to reuse them between pages. GitHub picked a solution for this that is supported (at least partially) by browsers with a total 94% market share [1].
Would it be possible to make a form with all those features and that works (at least with 95% of the features) with your legacy (dead) browser of choice, be it IE6 or Pale Moon? Sure, it would. But to do that, GitHub would need to spend a lot of resources, even though most GitHub users do not need those dead browsers. Those browsers don’t support many modern APIs that web apps need, or that make developers’ lives easier.
Speaking of dead software, Pale Moon dropped support for Windows XP in 2016 [2]. What happened? Why does software drop support for old runtime environments? Because nobody has the time and resources to test things on XP, and to write polyfills for features that XP does not support, or to skip some features because they don’t want XP users to get a worse browser, and because new features can make your software better for the user or more secure.
The world has moved on. Install a modern version of Firefox (or Chrome/ium if you must) and stop complaining.
Well given they laid off a Huge number of people while containing to pay their Executive HUGE salaries it seems their priorities is not on product development at all
Sadly I think we are seeing Mozilla go the way of Netscape, and I would not be surprised if they sell off all the IP to someone soon
The success of Medium has proven that lowering the barrier to write content is extremely valuable. If you're asking people to "work for free" then it should be as easy as possible and not feel like an errand. When you're inspired to write something, you just want to write it and not have the computer get in your way, or else you'll understandably give up. Wikipedia also proved this a couple decades ago.
Also rolling your own wiki is beyond stupid in this day and age. Just import all the MDN articles to MediaWiki. Making a script for this is a one-person weekend project. As I understand it though, Mozilla owns the copyright to all the content and they might shut you down for doing so.
While I acknowledge you have a point, the parameters here are different; on Medium, everyone has their own space, and low-quality work is harmless. On MDN though (and to a degree Wikipedia, although it's a lot broader), you want authoritative, high quality documentation. Quality over quantity.
MDN won't become better if there's more contributors and activity (churn).
Should probably normalize to a superset of Github-Flavored Markdown (GFM)... most contributions can be done ON github via the integrated editor btw... .md files would allow for a reasonable preview as well in the editor.
All of the devs on my team would rather maintain docs in markdown documents with pull requests versus in wiki form or in google docs. Yes the bar for contribution is slightly higher. But barely.
Did they confirm you have to write raw HTML? Markdown seems vastly more likely to me.
In theory, yes; Github is working on / has deployed a web-based version of VS Code, and VS Code has a Markdown preview (and I'm sure there may be a WYSIWIG / Markdown editor as well).
It should be doable to create a WYSIWYG editor just for the MDN pages as well, or any static site generator for that matter. Question is whether they want to invest in that; will that actually improve things, given how the MDN pages are all fairly uniform in look, feel & layout.
That's yet another option, authoring Markdown with preview.
I've thought of GitHub REST API Pull Requests [1] this requires authorizing web application though.
Another version - is there any service that allows to post changes in Pull Request body? Maybe extend GitLab? Workflow would be Edit page, Preview, copy to clipboard, open new Pull Request, paste.
I am not a fun of Markdown anymore. WYSIWYG looks like much better approach, it already there. HTML to markdown tools are not great.
Shouldn't people contributing to MDN be fairly comfortable with writing HTML? You could make the case for github and git but those aren't exactly uncommon for developers either.
> "you will no longer be able to click Edit on a page, make and save a change, and have it show up nearly immediately on the page. You’ll also no longer be able to do your edits in a WYSIWYG editor."
> "you won’t have a WYSIWYG to instantly see what the page looks like as you add your content, and in addition you’ll be editing raw HTML"
They had a user-friendly system previously... Now users have to learn GitHub and author raw HTML! - I would point out that not all documentation writers are developers!