6 ms·

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 takin

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!

blitblitblit 6y ago
> 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?
- kardos 6y ago
  > They also shutdown Firefox Send. IIRC it was being abused and there was no way to combat that
  - thesimon 6y ago
    Although I have a hard time believing they completely overlooked it when they were designing the service. If I think of serving user-generated/uploaded content, malware and copyright violations come directly to my mind.
- tomcam 6y ago
  Not trying to be inflammatory here. What does it matter if Microsoft has a proprietary front end for Github when all the docs are in markdown?
  - blitblitblit 6y ago
    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. Github's response: "... further degradation is a likelihood. I appreciate that this is disappointing and frustrating for you..." - https://forum.palemoon.org/viewtopic.php?p=202146#p202146 https://forum.palemoon.org/viewtopic.php?p=202146#p202146
    - JeremyBanks 6y ago
      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.
      - wldcordeiro 6y ago
        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.
        boogies 6y ago
        Palemoon was last updated ~2,280 times more recently than IE6, and UXP is a Free and open platform used by more than one browser.
      - userbinator 6y ago
        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. Seriously, fuck this "modern" bullshit. https://news.ycombinator.com/item?id=23136688 https://news.ycombinator.com/item?id=23136688 https://news.ycombinator.com/item?id=19664509 https://news.ycombinator.com/item?id=19664509 https://news.ycombinator.com/item?id=18486124 https://news.ycombinator.com/item?id=18486124
- JeremyBanks 6y ago
  What is UXP, and how is it affected by GitHub's decision to use WebComponents in their frontend?
- syshum 6y ago
  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 or just make FireFox yet another Chromium Skin
slimsag 6y ago
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. [1] https://github.com/hexops/vecty/issues/136 https://github.com/hexops/vecty/issues/136
- onei 6y ago
  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.
deleted 6y ago
[deleted]
jameslk 6y ago
> 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.
- ronnier 6y ago
  The friction is higher. Now you have to deal with github and accounts and permissions and so on. Before it was a simple web form.
  - hombre_fatal 6y ago
    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.
    - wldcordeiro 6y ago
      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.
      - Aeolun 6y ago
        Or, you know, because it’s a legitimate concern that readers on HN value higher than the MDN maintainers.
        tekromancr 6y ago
        Having used this site for a long, long time. No, almost never.
julienb_sea 6y ago
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.
mattacular 6y ago
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. This is a strange thing to gripe about.
hombre_fatal 6y ago
> They had a user-friendly system previously 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.
zelly 6y ago
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.
- Cthulhu_ 6y ago
  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).
sergeykish 6y ago
Can we have both PR and WYSIWYG? Login with github, Edit page, click button to submit PR with your changes.
- Cthulhu_ 6y ago
  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.
  - sergeykish 6y ago
    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. [1] https://docs.github.com/en/free-pro-team@latest/rest/reference/pulls https://docs.github.com/en/free-pro-team@latest/rest/referen...
tracker1 6y ago
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.

blitblitblit 6y ago

> 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?

kardos 6y ago
> They also shutdown Firefox Send. IIRC it was being abused and there was no way to combat that
- thesimon 6y ago
  Although I have a hard time believing they completely overlooked it when they were designing the service. If I think of serving user-generated/uploaded content, malware and copyright violations come directly to my mind.
tomcam 6y ago
Not trying to be inflammatory here. What does it matter if Microsoft has a proprietary front end for Github when all the docs are in markdown?
- blitblitblit 6y ago
  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. Github's response: "... further degradation is a likelihood. I appreciate that this is disappointing and frustrating for you..." - https://forum.palemoon.org/viewtopic.php?p=202146#p202146 https://forum.palemoon.org/viewtopic.php?p=202146#p202146
  - JeremyBanks 6y ago
    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.
    - wldcordeiro 6y ago
      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.
      - boogies 6y ago
        Palemoon was last updated ~2,280 times more recently than IE6, and UXP is a Free and open platform used by more than one browser.
    - userbinator 6y ago
      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. Seriously, fuck this "modern" bullshit. https://news.ycombinator.com/item?id=23136688 https://news.ycombinator.com/item?id=23136688 https://news.ycombinator.com/item?id=19664509 https://news.ycombinator.com/item?id=19664509 https://news.ycombinator.com/item?id=18486124 https://news.ycombinator.com/item?id=18486124
JeremyBanks 6y ago
What is UXP, and how is it affected by GitHub's decision to use WebComponents in their frontend?
syshum 6y ago
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 or just make FireFox yet another Chromium Skin

slimsag 6y ago

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. [1] https://github.com/hexops/vecty/issues/136 https://github.com/hexops/vecty/issues/136

onei 6y ago
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.

deleted 6y ago

[deleted]

jameslk 6y ago

> 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.

ronnier 6y ago
The friction is higher. Now you have to deal with github and accounts and permissions and so on. Before it was a simple web form.
- hombre_fatal 6y ago
  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.
  - wldcordeiro 6y ago
    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.
    - Aeolun 6y ago
      Or, you know, because it’s a legitimate concern that readers on HN value higher than the MDN maintainers.
      - tekromancr 6y ago
        Having used this site for a long, long time. No, almost never.

julienb_sea 6y ago

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.

mattacular 6y ago

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. This is a strange thing to gripe about.

hombre_fatal 6y ago

> They had a user-friendly system previously 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.

zelly 6y ago

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.

Cthulhu_ 6y ago
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).

sergeykish 6y ago

Can we have both PR and WYSIWYG? Login with github, Edit page, click button to submit PR with your changes.

Cthulhu_ 6y ago
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.
- sergeykish 6y ago
  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. [1] https://docs.github.com/en/free-pro-team@latest/rest/reference/pulls https://docs.github.com/en/free-pro-team@latest/rest/referen...

tracker1 6y ago

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.