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!
slimsag 1269 days 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.
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.
jameslk 1269 days 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 1269 days 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 1269 days 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 1269 days 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 1268 days ago [-]
Or, you know, because it’s a legitimate concern that readers on HN value higher than the MDN maintainers.
tekromancr 1268 days ago [-]
Having used this site for a long, long time. No, almost never.
earthboundkid 1268 days ago [-]
The friction is lower because I already have a GitHub account but I don’t have an MDN account.
Cthulhu_ 1268 days ago [-]
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.
devwastaken 1268 days ago [-]
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.
hombre_fatal 1269 days 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.
blitblitblit 1269 days 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 1269 days ago [-]
> They also shutdown Firefox Send.
IIRC it was being abused and there was no way to combat that
thesimon 1269 days 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 1269 days 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 1269 days 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.
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 1269 days 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 1268 days 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 1268 days 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.
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.
It seems people just don't like to hear the truth.
Kaze404 1269 days 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
Not that I think this is the right move by Github, but you can create PRs from external tools. I do that from Magit+Forge all the time.
1269 days ago [-]
JeremyBanks 1269 days ago [-]
What is UXP, and how is it affected by GitHub's decision to use WebComponents in their frontend?
syshum 1269 days 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
zelly 1268 days 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_ 1268 days 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).
tracker1 1268 days 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.
1269 days ago [-]
julienb_sea 1269 days 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.
sergeykish 1268 days ago [-]
Can we have both PR and WYSIWYG? Login with github, Edit page, click button to submit PR with your changes.
Cthulhu_ 1268 days 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 1268 days 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.
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.
jannes 1269 days ago [-]
It is going to be the 5th iteration of CMS/wiki software. Hopefully this is the right one.
1. Netscape DevEdge
2. MediaWiki
3. Deki Wiki (renamed to MindTouch, closed source since 2013)
And the problem is that each time the software changes, attributions are lost. I used to be active contributor to MDN with thousands of contributions. Countless hours of volunteer work.
When the platform changed and my attributions were lost, I stopped contributing. I had no street cred anymore. I was angry.
The switch to GitHub means the same problem once again. Nice way to alienate your community, MDN. Good luck with that.
simonw 1269 days ago [-]
It should be possible to migrate to GitHub without losing attribution. I've seen scripts in the past that build up a Git repository from scratch, back-dating contributions and crediting them to the author.
No idea if MDN are planning to do that though.
TedDoesntTalk 1269 days ago [-]
They never did that in the past. Why start now? Entire articles I wrote from scratch... the attributed author is not me, it’s some bot.
lifthrasiir 1269 days ago [-]
Impossible unless you have a thorough map from MDN accounts to Github accounts in advance (because once published the repo can't really change much, especially in this case).
notriddle 1268 days ago [-]
You don't need a map from MDN accounts to GitHub accounts. You just need email addresses.
simonw 1268 days ago [-]
You can use email addresses, but you can also append a profile page URL to the commit message.
patrec 1268 days ago [-]
Since you probably spent hundreds of hours on this, and they are apparently in violation of the license under which you contributed this work, maybe get a lawyer and send them a letter asking for your attribution to be re-instated or removal of all the mis-attributed material?
I mean Mozilla earns hundreds of millions a year and pays its CEO several millions a year, they could have well afforded to not violate your rights by spending a few dev days on writing a proper importer scripts.
pjmlp 1269 days ago [-]
But imagine how much their CV will improve!
wffurr 1269 days ago [-]
Oh no, my internet points!
Jtsummers 1269 days ago [-]
Volunteer work like that that results in visible, attributable output can become part of your resume/portfolio. You can point people to it and say, "Here are a set of articles representative of my work." Much like open source contributions (if you're not the primary maintainer of anything open source).
nextaccountic 1269 days ago [-]
Those are unpaid volunteers. If Mozilla robs them attribution for work (and yes this is work), then what's left?
Specially now that they fired every single paid worker.
Aeolun 1268 days ago [-]
> Those are unpaid volunteers. If Mozilla robs them attribution for work (and yes this is work), then what's left?
Warm fuzzy feelings? The knowledge that people read your article thousands of times every day?
Honestly, while I agree that it’s a bit sad to lose the attribution, I find it hard to be sympathetic with people who get salty over losing internet points.
aiisjustanif 1268 days ago [-]
That’s so disingenuous.
It’s a knowledge base. It’s well designed documentation. Something that many folks in IT lack at times. Showing people you can properly document knowledge in a collaborative way helps you get hired.
animal_spirits 1269 days ago [-]
Mozilla never promised them any pay in the first place
icebraining 1269 days ago [-]
It did promise to attribute the contributions, since they are licensed under CC BY-SA.
aiisjustanif 1268 days ago [-]
It’s not about payment it’s about legal open source practices that help foster and protect the community.
pygy_ 1269 days ago [-]
The ability to write good tech documentation is a valuable skill. I understand the GP was upset when they lost an easy way to signal they have it to potential employers.
Godel_unicode 1269 days ago [-]
It's mean to make fun of people for caring about things. If people are proud of work they've done, why shouldn't they be upset when they get no credit?
pedroma 1269 days ago [-]
I assume they could've put it on their resume and gotten something from that. Now it's just baseless claims.
Aeolun 1268 days ago [-]
If your potential employer is so skeptical of you that they don’t trust you when you tell them you wrote certain articles on MDN, they’re not likely to hire you in the first place.
aiisjustanif 1268 days ago [-]
If you reference work you do in your own time, I will go look at it. It’s unfair that MDN doesn’t easily make note that their contributions may have been lost to the ether.
wffurr 1269 days ago [-]
Oh no, my internet points!
andrewmcwatters 1269 days ago [-]
I don't mean for this to come off rude, but at some point you have to learn that spending time in life on things you don't control can have extremely negative costs.
How can you be angry? MDN isn't yours. Do they owe you something? It's volunteer work. You're not owed anything. You should consider attribution a privilege.
crazygringo 1269 days ago [-]
I don't mean for this to come off rude, but how can you be so cold? How can you lack so much empathy? At some point you have to learn that things matter to people.
Volunteer projects rely on an unspoken contract that symbolic recognition, awarded fairly, is a real motivation. And if a project wants to succeed, it needs to take that seriously.
Does the project owe its contributors anything? Legally, no. But if it wants to survive and keep contributors, then it had better damn well work hard to recognize them. The project isn't owed anything. The project should consider its free, voluntary member contributions a privilege.
Understand now?
cxr 1269 days ago [-]
> Does the project owe its contributors anything? Legally, no.
Uh, what? Legally, yes.
Why are so many people (see sibling below: "Perhaps legally, in this case, they're owed nothing") just rolling with the suggestion that this is a grey moral issue and not a legal one? It's more than a moral issue. This is Creative Commons content. Mozilla doesn't acquire ownership of project contributors' work...
Once again, we have another Mozilla-related thread where we find two "sides" of an issue, with both offering takes that reveal that neither has any idea what they're talking about. What is it about Mozilla that attracts this sort of thing?
crazygringo 1269 days ago [-]
I think it's completely clear from context that the references are to the project as a human organization, not its content. Obviously recognition is given by organizers... not by Creative Commons-licensed content, ha! Unless text has become sentient now. :)
But I don't know why you're then choosing to baselessly insult people who discuss things about Mozilla...? Call me crazy, but I don't think that's a helpful or constructive attitude here...
cxr 1269 days ago [-]
> baselessly insult people who discuss things about Mozilla...?
It's neither baseless nor is it an attitude that is not "helpful"—I laid out exactly what the basis for the comment is, which comes almost directly from Frank Hecker's post a couple months ago after the most recent layoffs:
> Incidentally, doing a Twitter search on ”Mozilla” gives a good feel for public perception of Mozilla among technologists, but unfortunately most of the people commenting have no real idea what they’re talking about.
On the other hand posting false or simply misleading information, whether intentional or unintentional, is unhelpful. And if it's unintentional, there are a few different ways to respond when someone points it out. One way is to feel insulted and post an emotional response. Another is something like, "Oops, my mistake. I wasn't really thinking about that when I wrote what I did, but on second thought: good point!"
I don't really know what your first two sentences about human organizations and context are supposed to mean. Mozilla does have a legal obligation to abide by the license terms—in contrast to what you wrote—and that's pretty much that.
crazygringo 1269 days ago [-]
> I don't really know what your first two sentences about human organizations and context are supposed to mean.
They're mean that you have completely misinterpreted the conversation, and apparently continue to do so.
The discussion started about moral responsibility. You're the only one confusing it with legal responsibility. And that's pretty much that.
cxr 1269 days ago [-]
You're right, it did start that way. And then the matter of legal responsibility was brought up; one person even posed the question, "Does the project owe its contributors anything?", and gave a direct and unequivocal response: "Legally, no." (Side note: that person was you.) And to say that is to say something that is simply not true—as untrue as any statement now about my being confused about whether legal responsibility was being discussed.
You can't rewrite history. (And we shouldn't have to replay all this. It's still all there to see...)
crazygringo 1268 days ago [-]
I don't know why you're so willfully misreading this.
The project doesn't owe the contributors anything legally in terms of recognition (or payment, etc.) which was the subject being discussed. That's quite obvious from the context.
Nobody ever brought up legal ownership of content at all -- that's 100% your misinterpretation.
It's kind of amazing how you misunderstand comments and then go on to insult others for supposedly misunderstanding comments... and then proceed to then do it all over a second time! Amusingly ironic. Better luck in the future, my friend... ;)
cxr 1268 days ago [-]
Sorry, that's not going to work. The comment you responded to outright said these things:
- "MDN isn't yours."
- "Do they owe you something?'
- "You're not owed anything."
... and your response? "Legally, no"—but of course the problem with that response, again, is that legally, yes; they do owe something.
So try rewriting the context and all the rhetorical gerrymandering you want, but it doesn't change that the fact that (a) there was a discussion in terms of legal responsibilities and (b) in that discussion about those responsibilities, your comments were incorrect. Being wrong because of a slip-up is fine—and it wasn't even wholly your slip-up; you were yes-anding someone else's comment. But this scrambling now to double down after it's pointed out and the subsequent projection—particularly in your last paragraph here—is more than a little annoying to encounter.
> The project doesn't owe the contributors anything legally in terms of recognition
... except they do, for the reasons already stated. Maybe there's some attempt at sleight of hand in your choice of the word "recognition" here (i.e., as distinct from "attribution", but even then, it's not clear whether any argument there, if there is one, would even hold up)—but it's not really important. Because "attribution" is the word that was used, attribution is what the BY part of CC-BY-SA stands for, and attribution is what's required by that license—yes, legally.
It's pretty bewildering that you think you have an argument here.
TedDoesntTalk 1268 days ago [-]
It doesn’t matter. License violations of different kinds are broken all the time and go unenforced due to cost, time, and energy.
MaulingMonkey 1269 days ago [-]
> Why are so many people (see sibling below: "Perhaps legally, in this case, they're owed nothing") just rolling with the suggestion that this is a grey moral issue and not a legal one?
I mean, I dedicated an entire paragraph above that comment to pointing out moral possible legal problems, and used "perhaps" as an explicit indicator of uncertainty and doubt. The moral issue isn't particularly grey. The legal one...
There are various attributions for "Mozilla Contributors". Does that technically suffice under either the license terms or in juristictions which recognize authors rights? (What juristiction(s) apply - hosting provider, Mozilla's headquarters, or perhaps the original authors?) Do they perhaps more explicitly attribute the original authors elsewhere? Certainly stripping names from an explicit copyright header would almost certainly be a license violation, but does flattening VCS history in the manner also count as one? Did CC licensing terms apply at the time of previous CMS conversions? Were there perhaps contributor agreements and/or clickwrap licensing agreements previously which would've made this legal? Are there more buried attributions which might technically meet the burden of attribution while still being done poorly enough to feel slighted? Perhaps in some juristictions but not in others?
Can you answer all that with enough certainty as to assert that you "have any idea what you're talking about"?
> What is it about Mozilla that attracts this sort of thing?
Both sides offering takes that reveal that neither has any idea what they're talking about is far from unique to threads involving Mozilla. I dare say it's not even unique to the internet.
cxr 1269 days ago [-]
> The moral issue isn't particularly grey. The legal one...
Also not grey—same as before.
> Can you answer all that with enough certainty as to assert that you "have any idea what you're talking about"?
Hey there. I'm a former Mozillian. I was a heavy contributor to Devmo in its early days (2006–2008). A bunch of that content is mine. It's not Mozilla's, and I know on what terms I made it available. So to answer your question quoted above (a) yes, in fact, I do know what I'm talking about, and (b) I don't have to be able to give an answer for every slot in your contrived matrix; it suffices if I'm able to say, "hey, you can't do that with the pieces that belong to me". And that's something that I can say—with certainty.
andrewmcwatters 1268 days ago [-]
Because that’s not how the world works. This is evident by living in it. Otherwise, this wouldn’t have happened.
What’s happens in the real world is that you abide by contractual agreements and if a party breaks the agreement, you sue them for breach of contract. This also requires that you can sue them for breach of contract. Otherwise, you can kick dirt.
Understand now?
TedDoesntTalk 1268 days ago [-]
This is how Wikipedia attracts and retains volunteers.
cxr 1269 days ago [-]
> MDN isn't yours. Do they owe you something?
Yeah, they do owe something: they owe the attribution which is a condition of the Creative Commons license which is what license the content is available to Mozilla (and everyone else) under.
> You should consider attribution a privilege.
Absolutely not. That's not how copyright works. What a deluded, entitled take.
andylynch 1269 days ago [-]
It’s absolutely a right, and recognised in the Berne convention, although unfortunately not well protected in US law compared to other states.
setr 1269 days ago [-]
That's an absurd take on it... MDN owes this guy nothing, and this guy owes MDN nothing. But attribution, and the volunteer labor, are not part of any financial transaction, so the question of who formally owes who what is entirely irrelevant
But from the social contract, attribution is a perfectly fair expectation for this kind of work -- especially because at the time of, and even going forward, attribution was given. It may not have been codified as a public contract, but the relationship was, and is, quite clear.
And the breaking of that relationship for fairly arbitrary reasons (it couldn't be imported/converted?) is a pretty damn good reason to be annoyed -- hell, what other reason would you consider valid? If it was financial rather than social, you don't get angry, you get even (lawsuit).
Now I'm getting annoyed as I write this; its not a fucking privilege to have been given the honor of doing volunteer labor, and its not a fucking privilege to be given attribution for it -- it's like the most basic free compensation you can give for free work. It's a norm across the board
MaulingMonkey 1269 days ago [-]
Attribution is important enough that several software licenses amount to little more than "attribute the original authors and don't sue us." Attribution is important enough that a right of attribution is incorporated into some countries copyright law as "authors rights".
Perhaps legally, in this case, they're owed nothing - but it's not unreasonable to consider stripping said attributions to be a dick move, even when legal. Maybe unsuprising, but a dick move nonetheless.
icebraining 1269 days ago [-]
In fact, it's part of the license they tell you that the contributions are made under (CC BY-SA), hence it's not even legal.
bawolff 1269 days ago [-]
In some countries you can't even sign away the right to attribution (ianal), so depending on where the contributor resides they might legally owe them that.
cdubzzz 1269 days ago [-]
This seems like an odd argument. One can be angry about... well anything. Not just things owed or not owed.
GP is venting some anger here at a relevant moment and the perspective is obviously valuable.
bawolff 1269 days ago [-]
> Do they owe you something
Mozilla is allegedly an open source project, so yes they owe you things based on free software principles, such as attribution and right to fork.
toyg 1269 days ago [-]
The opensource ecosystem is built on a very thin veneer of perceived fairness: labor is free in the hope that it will bring you reputation (which you can leverage into actual remuneration). If you remove one side of the equation (no matter how hopeful or hypothetical that might have been in practice), the setup appears entirely exploitative, and people get angry.
feanaro 1269 days ago [-]
If he was a contributor, MDN is partly his, in the sense that it can even be anyone's.
irrational 1269 days ago [-]
Wow, DevEdge. Now that takes me back. I hadn't thought about DevEdge in ages.
morpheuskafka 1269 days ago [-]
> Better community building: At the moment, MDN content edits are published instantly, and then reverted if they are not suitable. This is really bad for community relations. With a PR model, we can review edits and provide feedback, actually having conversations with contributors, building relationships with them, and helping them learn.
This is a longstanding debate in wiki/collaboratively written content, but it it interesting to note that Wikipedia and the other WMF projects have been pretty successful with the anyone can edit, revert or fix after. The review first model is used on specific pages, where it is called pending changes protection, although this is not really like a PR in that there is no comment functionality, and the standard for acceptance is lower--I don't remember the exact wording but it is closer to "this is not vandalism/not obviously wrong" rather than "I personally endorse this" much less "this is the community consensus." These edits have no special endorsement once approved and can still be changed by other editors freely. One benefit of the PR model is finality, once an issue/PR is decided no one else is supposed to open another one with virtually the same change. Wikipedia sort of has that via article talk pages, but there is of course no centralized "maintainer" to adjudicate each and every controversy. Also, many editors just don't check or even understand them.
chaorace 1269 days ago [-]
I think the wiki approach works best for very diverse references, where there is no such thing as a "good enough" maintainer. You can't do Wikipedia like this, because nobody is an expert in all of human knowledge.
On the other hand, MDN is probably sufficiently narrow in scope that a team of subject matter experts can competently manage contributions in a timely manner. Of course, by "narrow" I do mean basically every technology currently in use on the web, so... guess we'll see how realistic that is!
runarberg 1269 days ago [-]
In short, what you are saying is: There is a fundamental difference between an encyclopedia and technical documentation which warrants a different approach to contributions.
class4behavior 1269 days ago [-]
I don't think you need to "really" change your approach when it comes to wikis.
The more quality control you need the more often you just let the contributor prove themselves first. Meaning, you don't automatically approve their submissions, but you don't completely prevent them from writing either, at least for as much as your community have the resources to review.
hombre_fatal 1269 days ago [-]
Being able to have defense/discussion about your documentation edit is something sorely lacking on wiki platforms that you get in pull requests.
Frankly, I always felt the wiki model pretty much a show-stopper to making any real edits with no good UI for commit review and a good UI for having a granular discussion about your changes. Instead the UX is to burn a lot of time getting a large change through a bunch of potential reversion cycles while trying to communicate through talk page(s). It's a hoop that selects for die hards.
kevingadd 1269 days ago [-]
I think there's an argument to be made that the impact of temporary errors in an MDN page is more significant than temporary accuracy errors on someone's Wikipedia article. If a developer goes off incorrect information on MDN it can waste days-to-weeks of development effort and potentially lead to defective software in end-users' hands.
To be fair, maybe people should view MDN skeptically just like they do Wikipedia. But I think it's valuable for it to be a reliable source and review-first is a good way to maintain that.
codetrotter 1269 days ago [-]
I don’t think I would agree. There are so many many different topics on Wikipedia. I think in all likelihood there is an enormously bigger amount of topics on Wikipedia that could lead to far bigger problems than some days of time wasted for a software developer, if the pages were to contain seriously bad information.
madeofpalk 1269 days ago [-]
This model - storing markdown files in a git(hub) repo and editing them on Github is getting more and more popular. It would be great to see Github add a more rich markdown/frontmatter editor to their interface to accomodate this.
pietrovismara 1269 days ago [-]
For what I understood it's going to be raw HTML, not markdown.
I was thinking of a more featureful markdown-based rich text editor, like you might see in a proper CMS.
pianoben 1269 days ago [-]
Reading between the lines, it seems obvious that Mozilla wishes to stop funding localization.
Translations aren't even that expensive, especially relative to the cost of producing the docs in the first place. It hurts me to see MDN so starved of resources that they can't pay for even that small piece.
MDN has been key to so many people's technical education. High-quality web documentation is an essential resource for those looking to elevate themselves into a technical career these days.
Much of the world (20%, according to their own research) is set to lose access to this vital body of knowledge.
emilecantin 1269 days ago [-]
From TFA:
> Note: In addition, the text of the UI components and header menu will be in English only, going forward. They will not be translated, at least not initially.
But that's the easiest part! I understand the part about translations becoming stale, and how it's hard to manage, but honestly, translating a UI isn't that hard.
I think a good recipe to get better translations is:
- Don't treat it as an aftertought. Co-locate the en-US assets with the translated versions, that way your contributors actually see that there are other languages to support. Each page on the MDN website should be a folder containing a file for each language.
- If a translation is out-of-date, link to these more recent languages, and offer an auto-translated version in the meantime. Importantly, let the user switch between the automatic translation and the manual one. Also, make it obvious how they can contribute.
firexcy 1267 days ago [-]
Idk, but ESL speaker as I myself is, I don’t think localizations are that important for technical writings, where few grammar or rhetoric is concerned, and technical terms can simply be seen as “tokens” that can be represented in any language as long as you can identify their “shapes.” Therefore, if you are among the targeted reader group, that the documentation is not in your mother tongue is unlikely to discourage you from reading it. On the other hand, if you are not comfortable with reading technical descriptions generally, having a localized version will not help much either.
GoblinSlayer 1269 days ago [-]
If the text is in github, you can download it, backup, make an iso and share on piratebay, it won't be lost.
pianoben 1269 days ago [-]
The concern I'm trying to express is that the translations of this content will grow increasingly stale as the original articles are updated, and will be missing entirely for new articles. People who don't speak or read one of the top 12 languages will just be out of luck, unless some generous soul decides to do that substantial amount of work for free.
afiori 1268 days ago [-]
As far as I understand Mozilla's point is that this is already happening. I agree that stuff like the UI should still be localized manually.
dmos62 1269 days ago [-]
We shouldn't discount volunteer translations. Won't the new platform support that?
pavon 1269 days ago [-]
I think that storing the localized content in separate flat HTML files makes it very difficult to maintain translations, as the article points out.
Ideally, you would have a master document in which some parts are shared across all translations (like the layout, the actual terms in the spec, browser compatibility information, etc), while other parts were localizable (like the field descriptions). Then when content was added/changed, it would be clear which parts of the translations needed updating, and you could either flag them as such for volunteers, or use machine translation as a stop-gap, or both.
With the architecture they described, however, your options are either to make the translations completely independent or to make translations completely machine translated, neither of which is a good solution.
Cthulhu_ 1268 days ago [-]
It's quite telling already that they basically admit that mixing markup and content as tightly as that is problematic.
I mean I don't think it's actually that big of a deal as long as they stick to basic HTML markup (paragraphs, bold/italics, etc), but you're already running into problems when you add links.
Not having multi-language support as a first-class citizen is a step backwards IMO. Especially considering the world is still getting connected at an enormous rate.
afiori 1268 days ago [-]
Multi-language support has the inherent problem that is requires effort linearly in the number of languages. Wearing a hopeful hat this new architecture would only require an effort "linear" to the error rate of the machine translations.
Personally I had some very good experiences with some translators, and it could work even better if Mozilla manages to tune and train them properly. (Like making so that manual fixes improve the algorithm)
pianoben 1269 days ago [-]
I don't doubt that the Github-based CMS will allow for community-provided translations. I _do_ doubt that we'll see anything like the current set of languages covered at anything like the current levels of breadth and quality.
Like I said in another comment, approximately nobody translates technical documentation for fun.
bawolff 1269 days ago [-]
A surprising amount of mediawiki documentation is translated by volunteers (i cant speak to the quality as i dont speak nonenglish, realistically the english source material isnt that great) but volunteers do translate things
rhizome 1268 days ago [-]
Perhaps interestingly, I had a frustration in the other direction just last night:
Notice that the English page seems obviously translated by a non-native speaker, which has some implications not favorable to Mozilla's behavior here, specifically that ESL people will contribute documentation in English that native English-language speakers won't even provide for themselves.
bawolff 1268 days ago [-]
Wikipedia translations are a bit different because they are not meant to be 1:1. The translations in theory are entirely separate articles.
Did they actually fund localisations? I'm unfamiliar with their process, but this article game me an impression that it was completely community driven.
pianoben 1269 days ago [-]
Yes, absolutely. Approximately nobody translates technical documentation for fun, much less at such a high level. The article is pretty clear that the number of languages supported is a business decision.
hombre_fatal 1269 days ago [-]
Wikimedia/Wikipedia show that people do translate for fun (I do it myself on the wiki software website), so I'm not sure how you have that blindspot.
Your comment is the same as people who saw the launch of Wikipedia and wondered who could possibly write articles and find citations for fun.
Hell, who would write hundreds of thousands of wiki articles about The Elder Scrolls universe for fun? https://en.uesp.net/wiki/Main_Page
trynewideas 1268 days ago [-]
> Hell, who would write hundreds of thousands of wiki articles about The Elder Scrolls universe for fun? https://en.uesp.net/wiki/Main_Page
70k articles, not hundreds of thousands,[1] and of those 70k fewer than 1/3 are translated to any other language.
And speaking as someone who was a system and content admin for a MediaWiki-powered fiction wiki of about 15k articles... there are not many people relative to the amount of content who are actually interested in contributing anything, much less improving or maintaining what's already there. It's a very, very small core of contributors.
Toward your example, the 161 "active" users[2] (meaning any number of edits in the last 30 days) as of today on English UESP combined for 5,974 edits in that span. Of those edits, 4,779 were from 13 users. 3,039 — more than half of the last month's activity — were from the top 5 users.
On the non-English UESPs? No active users in Portuguese, one in Italian, none in Arabic.[3][4][5]
From my experience at least, it's because it's work — fun work, at times, but still work. Translating MDN content is also work. Doing _any_ documentation of _anything_ is work. Hell, I burned out on fiction documentation work before I burned out on paid work.
Some people do enjoy it! But voluntary documentation is still going to attract a small, specific core group of consistent contributors (if it attracts any at all).
So they're hoping that they can replace the people they fired with open source contributors working for free.
parhamn 1269 days ago [-]
Man these kind of views bother me so much. They’re taking one of the most (if not, most) useful documentation sources for cross platform web development that benefits them very little, and moving it to a system of open contribution so it can live past the company’s financial problems. And this is your first take?
wwarner 1269 days ago [-]
Granted, it depends on how it turns out. But my first impression is that authoritative reference documents of MDN are going to become cluttered with comments and disagreements.
newmnhn 1269 days ago [-]
MDN has never been "authoritative reference documents". It's a wiki. Anybody can edit and republish pages, change examples, do whatever. I noticed somewhere about a year ago that it was a wiki, and have made minor changes to a couple of pages since then, when something was missing an example or something.
I change, I publish, it's done. And if my change was wrong, or opinionated, or bad, it's just like that until somebody else catches it and fixes it back.
hyperrail 1269 days ago [-]
Neither Safari, Chrome/Chromium, IE, old Edge, nor new Edge have substantial HTML and CSS developer documentation on their own web sites. Their vendors - excepting Apple and the WebKit contributors - all chose to work with Mozilla instead to put their docs on MDN: https://blogs.windows.com/msedgedev/2017/10/18/documenting-w...
It seems to me that as far as the browser makers are concerned, MDN is as close to authoritative as you can get without going to the standards documents themselves - and the standards don't give you browser compatibility matrices or make any note of browser-specific quirks.
MDN may be a wiki, but it certainly isn't treated like one by the people who are most interested in it being accurate and up to date.
newmnhn 1269 days ago [-]
I suppose I was reacting to this:
"Authoritative reference documents of MDN are going to become cluttered with comments and disagreements"
Which suggests previously authoritative docs are becoming less so due to being editable. I'm just pointing out they are and always have been subject to edits from the public. If anything the PR process will likely increase the reliability of the info because there would be a chance to do some vetting of changes.
I totally agree that MDN is as close to authoritative as you can get, but it's one (important) step away.
Godel_unicode 1269 days ago [-]
I think people put authoritative sources on too much of a pedestal because it's possible for someone to naively or maliciously edit wikis. People who write official docs are also frequently wrong, and the editing and review cycle there is far slower!
Every recent review I've seen of Wikipedia vs arbitrary big-a Authoritative sources has said that both have issues and overall Wikipedia is better.
Silhouette 1269 days ago [-]
I hope they don't suffer the same type of problem that caniuse has had since incorporating the MDN data. In that case, source data sets that were each well-regarded and, particularly in caniuse's case, well-curated on their own became overwhelming and harder to use than before once combined. The slightly different styles for each source and the partial duplication often seem to obscure the information I'm really trying to get to in the search results now. If MDN is now going to be community-led, I hope they manage to find some arrangement where there is still decent curation and not a Wikipedia/SO-style free for all followed by heavy-handed mod over-reaction.
detaro 1269 days ago [-]
Why is it now more likely to become cluttered than before?
nialv7 1269 days ago [-]
I think you are both right. This is good for the future of MDN, but OTOH cutting cost is likely to be what motivated Mozilla to make this change.
afiori 1268 days ago [-]
They had already cut cost, I would phrase it as this change being now even more necessary.
ironmagma 1269 days ago [-]
With corporations, the cynical view is most likely to be the correct view. And I wouldn’t say MDN does very little for Mozilla; it’s the main part of their brand in developers’ mind share. If they want to have a browser without developers who like it, that’s their choice, but it won’t really work out well business wise.
DC-3 1269 days ago [-]
As far as I can see, Mozilla have no reason to be losing money other than their own mismanagement.
roblabla 1269 days ago [-]
This is an article about MDN, not Mozilla. How exactly does MDN bring money? Do you suggest MDN should be a revenue source? Or do you expect Mozilla to maintain the MDN for free eternally just because?
This is seriously entitled. Mozilla gave us an amazing resource, entirely for free. This attitude isn't right, it's toxic and harmful.
Mozilla is in a spot of difficulty, and instead of taking a resource that is operating entirely at a loss down, they're taking the engineering steps to ensure thez resource can outlive them.
That their mismanagement caused them the difficulty is entirely irrelevant here. It could have happened in a myriad of other ways. We should be praising Mozilla and the MDN tech team for the steps they're taking in making sure the MDN can live on.
eznzt 1269 days ago [-]
It's stuff like MDN that attracts donations.
johnfn 1269 days ago [-]
Fun fact: I have an open source repo with millions of downloads, tens of thousands of active users, and, for at least a year, a prominently displayed donate button. How much in donations do you think it took in over its lifetime?
Hint: it's less than $200.
Donations don't really work.
weaksauce 1269 days ago [-]
Thanks for the vim plugin for vscode! It's quite useful and usable. fwiw i don't think you get many donations because it looks like an official microsoft backed vscode plugin so why would people throw money at microsoft. that said, i do think you are correct in that people in general do not donate to open source individually that much.
sroussey 1269 days ago [-]
We didn’t have many for Firebug either, though we appreciated those we got and funneled them to new contributors living outside the States where it made a difference.
rhizome 1268 days ago [-]
>for at least a year, a prominently displayed donate button.
Just to be sure, are you referring to the "BuyMeCoffee" button on the GitHub page for the extension (https://github.com/VSCodeVim/Vim)?
johnfn 1268 days ago [-]
Nah, we used to have a more prominent link. It's been removed since I stopped developing on the extension.
tracker1 1268 days ago [-]
At the bottom of a long scroll isn't something I'd consider prominent. I'd probably change it to simply "Donate" as a button, and put it with the badges at the top. Red, purple or orange as a contrasting color from the blue and green badges.
cambalache 1269 days ago [-]
Which one is it? Maybe you will win a handful of donations here.
> Or do you expect Mozilla to maintain the MDN for free eternally just because?
That's what I expect of a non-profit organization dedicated to maintaining one of the last two remaining major browser engines, yes.
afiori 1268 days ago [-]
I didn't know that becoming non-profit meant that money is free :)
ori_b 1269 days ago [-]
What are their revenue streams?
Now that antitrust is happening anyways, Google's main reason for shoveling money at them is going away.
contravariant 1269 days ago [-]
Well, the way I see it it was the financial problems who personally made the decision, so that complicated things somewhat.
airstrike 1269 days ago [-]
If the alternative is to close shop and let it die entirely, I don't have an issue with it
It's not like they were extremely profitable and fired people to squeeze an extra buck
Laying off people isn't inherently evil
thayne 1269 days ago [-]
I have more of a problem with who they laid off than the fact that they laid people off. I'm probably biased as an engineer, but IMO the people who actually create your products should be the last ones to be laid off, not the first. And if the company is struggling, highly paid execs should take a pay cut before you start laying off lower-paid engineers.
ruined 1269 days ago [-]
hey, firing people is hard work.
weego 1269 days ago [-]
It's more the clear mismanagement of their finances on ill-considered products outside of their core offering that never go anywhere. Some of them appear to be nothing more than vanity projects that subsequently disappear having got no traction at all.
tracker1 1268 days ago [-]
I still think they are/were in a great position to offer what is now office365 and google docs earlier on, with a position to offer both dedicated and cloud software options.
They had electron effectively a decade before electron with XULrunner and let it die on the vine.
There were opportunities for developer mindshare and for services adjacent to those tools they were already building... that they didn't do more for getting Thunderbird more competitive to Outlook to offering a better breed of messenger platform.
No, their management sat on fat cash, with fat paychecks and ill-conceived projects that lead to little in terms of mindshare or income longevity.
airstrike 1269 days ago [-]
Managing is inherently risky –– we shouldn't expect managers to make no mistakes while at the same time expecting them to keep workers around in an unprofitable business would only serve to further harm the business
Sure, one can rant all one wants about management's lack of business acumen, but that's completely separate from the issue of the layoffs
preommr 1269 days ago [-]
I read it more as they cleaned up the contribution process so that it's easier for people to participate.
But if what you said does happen, then RIP. It's not going to be the same - everyone is too busy writing medium articles to sell their course on udemy to make real contributions for free.
There were a lot of useful guides showing practical applications of features beyond just listing the api spec.
But I guess it'll still be useful as a more approachable wiki to api standards rather than having to go to w3schools (yuck) or the horrible ui of w3c.
trynewideas 1269 days ago [-]
Nevermind that work on Yari started at least a year prior to the layoffs in question. https://github.com/mdn/yari
gostsamo 1269 days ago [-]
So, you want to use it for free, but whoever makes it to be paid by someone else?
luhn 1269 days ago [-]
I'm a bit confused on the diagram for the new architecture: What's the purpose of the Lambda function? I don't see them explain that anywhere.
justinlilly 1269 days ago [-]
For the arrow coming from github to the cdn, I would bet that's a deployment where the existing docs site gets deployed as a lambda. From there, CDN calls that aren't cached go to the lambda which are then served up.
anuila 1269 days ago [-]
If that’s the case, why not just use GitHub Actions? It’s more integrated and requires no setup.
madacol 1269 days ago [-]
Sure, that's one of a hundred ways to deploy it.
But they don't say if they're using that approach or any other
afiori 1268 days ago [-]
They are probably more interested in cost rather than setup.
davidweatherall 1269 days ago [-]
I would assume the lambda is to invalidate / update the cache on the pages that are being changed as new commits are merged in.
julianlam 1269 days ago [-]
First impressions:
PR model via GitHub, good.
That new platform schema diagram for Yari, looks complicated.
rsstack 1269 days ago [-]
It's about the level of abstraction. Kuma's "Kubernetes Cluster" is very complicated but it serves no purpose to include its details in a blog post that describes Yari. Yari's diagram is more detailed than Kuma's, while Yari itself is simpler than Kuma.
franga2000 1269 days ago [-]
Probably looks complicated because of the names of all the services. In a nutshell, the data lives on GitHub, gets automatically compiled into HTML and sent to a web server. They have basically taken the rendering out of the app server and into a CI task that does it all in advance.
tracker1 1268 days ago [-]
Agreed... I'm not sure what of value is really left for non-contributing users on the site.
This is a similar tactic that MS has been using towards their documentation as well, so it's not so bad and for those most likely to contribute to technical documentation like this, the overlap with Github is significant enough.
Santosh83 1269 days ago [-]
Good to know that the MDN team are still working on the platform and even evolving it (hopefully for the better), despite severe layoffs.
What about the content part of it? Is it the hope that the move to GitHub and PR model will encourage broader community contribution and thus make up for the sad lack of dedicated content writers?
oDot 1269 days ago [-]
I am a big fan of jamstack. For a lot of my client's use cases it allows me to save them a lot of money and headaches while delivering a better product, especially with a headless CMS like Netlify CMS
whalesalad 1269 days ago [-]
I still don't fully grok the term. Is it a loose/blanket term sorta like 'devops' or is it a more literal prescription of actual requirements and practices?
jorams 1269 days ago [-]
A big problem is that the "Jamstack" branding and the website make it deliberately unclear that "JAM" is an acronym. I can't even find it expanded on the site. Instead it contains relatively verbose explanations that never become clearer than the actual words they so desperately avoid.
It's Javascript, API, Markup. Put "pre-rendered" before "Markup" and you understand everything.
Maybe they do this because they really want to push the fact that you can serve the J and M from a CDN?
It's in a similar category as "LAMP stack" or "MEAN stack", but more vague on details: JAM = Javascript + APIs + Markup. APIs tend to perform the role of a CMS (sometimes called "headless CMS"), and Markup tends to refer to declarative templating languages rather than code. The final output is compiled into static HTML+CSS+JS, which is obviously highly performant, compared to dynamically generated PHP/RoR/etc.
zerocrates 1269 days ago [-]
I can get that a significant part of it is just "static HTML," what I don't quite get is what makes it different than just static site generation. I guess that would be the "A" part...
detaro 1269 days ago [-]
Marketing pretty much. Some vague cloud of "uses serverless to generate", "pushes static files to a CDN through an API", but if you drill down none of that is key to it. I.e. you'll find advocates state that if a site uses a static site generator or Netlify it's JAMStack.
Vinnl 1268 days ago [-]
It mostly concerns how often content is updated.
Real-time: dynamically generated on the server-side. (e.g. injecting the current user's username)
Occasionally: Jamstack (e.g. rebuilding a static site every time a contributors adds a blog post via the CMS)
Rarely: manual updates (e.g. manually deploying a new version of a small-town restaurant's website when the menu changes)
madeofpalk 1268 days ago [-]
no, that's it. jamstack - static site generator, but javascript
whalesalad 1269 days ago [-]
Yea... SPA == same thing imho.
steveklabnik 1269 days ago [-]
More "REST" than "JSON". There's no Jamstack spec, no checkboxes to get your Jamstack compliance score. It is a description of a particular set of patterns and practices.
drawkbox 1269 days ago [-]
Jamstack is essentially a client/cloud model. Instead of client/server/db it is client with CDN and apis/microservices.
Jamstack is static sites/headless CMS, CDN for content/storage/speed, microservices/apis for data/auth/etc focused on speed, pre-rendering, and decoupling for easier swappable parts rather than monolith. [1]
tl;dr its basically just static html/js/css sitting in an s3 bucket, rather than having an active server (that you code/manage yourself).
It pushes the page rendering from runtime to build time.
moron4hire 1269 days ago [-]
I don't know. Moving from a Wiki model to a GitHub PR model actually sounds worse for users. They talk about, "building a relationship with contributors". This could also be called, "building a lot of friction for contributors".
With a Wiki, even non-technical users can contribute, because the editing tools are all built in.
But with the PR model, now contributors need to understand HTML, CSS, Git, and GitHub PRs. I've been on GitHub for something like 10 years and I still have trouble figuring out PR workflows.
Making simple edits like grammar or punctuation fixes become significantly more effort in performing the submission than in performing the edit itself.
Wanting to have control over the submission process to prevent drive-by vandalism is certainly important. But that should be managed with role-based authentication and new users needing to have their edits approved by a moderator or by votes from long-term users in good standing. Once again, this sounds like the same old Mozilla line of "doing the right thing for the current user experience is too hard for our developers, so we're going to move the goalpost instead."
Compared to MSDN, MDN isn't as broad, but goes a lot deeper on topics, and has much better examples. Does Microsoft wring its hands over how much running MSDN costs, to the point of considering giving it up entirely? I don't think they do. I think they know that it's important to keep developers on-platform, in-ecosystem, and they do that by offering a comprehensive learning resource.
MDN is the best online resource for learning about Web technologies. I think a large part of that is because of the relatively low friction to edit. It not making Mozilla any money is completely their own fault. They could have taken that a step further and started offering training services and events. It stretches belief that you could have such a popular resource and can't figure out some sort of monetization strategy related to it. But, I guess, that's another of the same, old Mozilla lines.
afiori 1268 days ago [-]
> Does Microsoft wring its hands over how much running MSDN costs
Microsoft revenue stream is slightly more reliable than Mozilla's reliance on Google.
gambler 1269 days ago [-]
>We are replacing the current MDN Wiki platform with a JAMStack approach, which publishes the content managed in a GitHub repo.
So... Ceding control over content to GitHub. Ceding control over uptime to Amazon. (Both done by a company that paints itself as pro-people, pro-privacy, etc.)
>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.
The fact that this is presented as some sort of improvement is pure farce.
nine_k 1269 days ago [-]
Frankly, vandalizing a page becomes harder.
The job of people who would have to check and approve the PRs becomes harder, too.
icebraining 1269 days ago [-]
The current Wiki is already hosted on AWS.
duxup 1269 days ago [-]
"If you want to be notified when the new system is ready for testing, please let us know using this form."
----
"You need permission
This form can only be viewed by users in the owner's organization."
> Microsoft is joining Google, the W3C, and Samsung to make Mozilla’s MDN Web Docs as the single place for web API reference.
Now that Microsoft is on Chromium, and THAT is also documented in MDN, and Google and Microsoft both own public cloud providers.. I feel like this move is more a step in the evolution of MDN rather than Mozilla simply sending it out to pasture.
afiori 1268 days ago [-]
This also match the focus on mass edits and tooling in the article
johnchristopher 1269 days ago [-]
Is there any way to back the actual MDN ?
Will the quizzes disappear in the near future ? I was planning on brushing up my html/css/js skills and I was planning on doing it through MDN.
z3t4 1268 days ago [-]
I'm working on an editor that lets you clone any repository - which uses a static site generator or the like to render static pages - where my editor lets you edit in WYSIWYG (fully rendered - what you see is what you get) - while producing clean diff's in plain HTML (or markdown), I would love to add support for editing MDN articles.
rndgermandude 1269 days ago [-]
Am I the only one put off by the AWS (S3+Lambda) lock-in they seem to be creating for themselves?
rsstack 1269 days ago [-]
It should only take a couple of days to switch those to a different cloud provider. When building a Jamstack website there is only very thin logic in the Lambda itself, and S3 is only used as managed file storage.
lawwantsin17 1269 days ago [-]
This is the same hand waving everyone does. There is lock in. To be sure, with developing any system.
striking 1269 days ago [-]
S3 is just files and Lambda is just FaaS, you can host your own open source versions of these tools and not encounter an issue.
This would be a more solid argument if they were using a lot of AWS features together, but you could replace this with Minio and FastCGI if you really wanted to.
fallat 1269 days ago [-]
and GitHub...
adrianmalacoda 1269 days ago [-]
Are they locked into github (using their proprietary APIs) or just using it as a git backend (using standard git tooling)? It's not clear from the article.
stu2b50 1269 days ago [-]
I'm pretty confident they're going to handle PRs via the github interface. I don't think they'd get many contributions if you had to email patches in.
rndgermandude 1269 days ago [-]
right, tho the github lock-in is probably gonna be the least worse if they mostly rely on git itself (GH issues and PRs can be migrated to other providers or self-hosted a lot more easily than uncoupling yourself from AWS APIs and services).
GoblinSlayer 1269 days ago [-]
And kubernetes, and react, and mysql. How to add something apple to the mix?
riquito 1269 days ago [-]
(about the comments I see here) This rethoric method of mentioning just the bad/debatable parts and completely ignore the benefits is toxic. It disregard any compromise, as if we could always achieve the ideal solution
hellokaushik 1269 days ago [-]
Nice
holaamigo 1269 days ago [-]
OK
xg15 1269 days ago [-]
So when "retire" or "sunset" isn't enough euphemism yet, we now have "evolve"...
anuila 1269 days ago [-]
What are you talking about? MDN is not being retired nor sunset. They’re only changing the underlying technology. It’s completely fair game.
dmitriid 1269 days ago [-]
> Simplified back-end platform
Shows two flowcharts, of which the new one is arguably more complex.
LockAndLol 1269 days ago [-]
While one org that's serious about privacy moves to Gitlab and selfhosts everything (wikimedia), another one decides to embrace Github, Google and Amazon. Why Mozilla... why?
Rendered at 10:53:31 GMT+0000 (Coordinated Universal Time) with Vercel.
> "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!
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
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.
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.
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.
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?
IIRC it was being abused and there was no way to combat that
If I think of serving user-generated/uploaded content, malware and copyright violations come directly to my mind.
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://github.com/cli/cli
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=19664509
https://news.ycombinator.com/item?id=18486124
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.
[1]: https://caniuse.com/?search=components
[2]: https://en.wikipedia.org/wiki/Pale_Moon_(web_browser)#Releas...
Not that I think this is the right move by Github, but you can create PRs from external tools. I do that from Magit+Forge all the time.
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
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.
MDN won't become better if there's more contributors and activity (churn).
Did they confirm you have to write raw HTML? Markdown seems vastly more likely to me.
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.
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/referen...
This is a strange thing to gripe about.
1. Netscape DevEdge
2. MediaWiki
3. Deki Wiki (renamed to MindTouch, closed source since 2013)
4. Kuma
5. Yari
There's a nice history here: https://developer.mozilla.org/en-US/docs/MDN_at_ten/History_...
When the platform changed and my attributions were lost, I stopped contributing. I had no street cred anymore. I was angry.
The switch to GitHub means the same problem once again. Nice way to alienate your community, MDN. Good luck with that.
No idea if MDN are planning to do that though.
I mean Mozilla earns hundreds of millions a year and pays its CEO several millions a year, they could have well afforded to not violate your rights by spending a few dev days on writing a proper importer scripts.
Specially now that they fired every single paid worker.
Warm fuzzy feelings? The knowledge that people read your article thousands of times every day?
Honestly, while I agree that it’s a bit sad to lose the attribution, I find it hard to be sympathetic with people who get salty over losing internet points.
It’s a knowledge base. It’s well designed documentation. Something that many folks in IT lack at times. Showing people you can properly document knowledge in a collaborative way helps you get hired.
How can you be angry? MDN isn't yours. Do they owe you something? It's volunteer work. You're not owed anything. You should consider attribution a privilege.
Volunteer projects rely on an unspoken contract that symbolic recognition, awarded fairly, is a real motivation. And if a project wants to succeed, it needs to take that seriously.
Does the project owe its contributors anything? Legally, no. But if it wants to survive and keep contributors, then it had better damn well work hard to recognize them. The project isn't owed anything. The project should consider its free, voluntary member contributions a privilege.
Understand now?
Uh, what? Legally, yes.
Why are so many people (see sibling below: "Perhaps legally, in this case, they're owed nothing") just rolling with the suggestion that this is a grey moral issue and not a legal one? It's more than a moral issue. This is Creative Commons content. Mozilla doesn't acquire ownership of project contributors' work...
Once again, we have another Mozilla-related thread where we find two "sides" of an issue, with both offering takes that reveal that neither has any idea what they're talking about. What is it about Mozilla that attracts this sort of thing?
But I don't know why you're then choosing to baselessly insult people who discuss things about Mozilla...? Call me crazy, but I don't think that's a helpful or constructive attitude here...
It's neither baseless nor is it an attitude that is not "helpful"—I laid out exactly what the basis for the comment is, which comes almost directly from Frank Hecker's post a couple months ago after the most recent layoffs:
> Incidentally, doing a Twitter search on ”Mozilla” gives a good feel for public perception of Mozilla among technologists, but unfortunately most of the people commenting have no real idea what they’re talking about.
https://civilityandtruth.com/2020/08/13/mozillas-uncertain-f...
On the other hand posting false or simply misleading information, whether intentional or unintentional, is unhelpful. And if it's unintentional, there are a few different ways to respond when someone points it out. One way is to feel insulted and post an emotional response. Another is something like, "Oops, my mistake. I wasn't really thinking about that when I wrote what I did, but on second thought: good point!"
I don't really know what your first two sentences about human organizations and context are supposed to mean. Mozilla does have a legal obligation to abide by the license terms—in contrast to what you wrote—and that's pretty much that.
They're mean that you have completely misinterpreted the conversation, and apparently continue to do so.
The discussion started about moral responsibility. You're the only one confusing it with legal responsibility. And that's pretty much that.
You can't rewrite history. (And we shouldn't have to replay all this. It's still all there to see...)
The project doesn't owe the contributors anything legally in terms of recognition (or payment, etc.) which was the subject being discussed. That's quite obvious from the context.
Nobody ever brought up legal ownership of content at all -- that's 100% your misinterpretation.
It's kind of amazing how you misunderstand comments and then go on to insult others for supposedly misunderstanding comments... and then proceed to then do it all over a second time! Amusingly ironic. Better luck in the future, my friend... ;)
- "MDN isn't yours."
- "Do they owe you something?'
- "You're not owed anything."
... and your response? "Legally, no"—but of course the problem with that response, again, is that legally, yes; they do owe something.
So try rewriting the context and all the rhetorical gerrymandering you want, but it doesn't change that the fact that (a) there was a discussion in terms of legal responsibilities and (b) in that discussion about those responsibilities, your comments were incorrect. Being wrong because of a slip-up is fine—and it wasn't even wholly your slip-up; you were yes-anding someone else's comment. But this scrambling now to double down after it's pointed out and the subsequent projection—particularly in your last paragraph here—is more than a little annoying to encounter.
> The project doesn't owe the contributors anything legally in terms of recognition
... except they do, for the reasons already stated. Maybe there's some attempt at sleight of hand in your choice of the word "recognition" here (i.e., as distinct from "attribution", but even then, it's not clear whether any argument there, if there is one, would even hold up)—but it's not really important. Because "attribution" is the word that was used, attribution is what the BY part of CC-BY-SA stands for, and attribution is what's required by that license—yes, legally.
It's pretty bewildering that you think you have an argument here.
I mean, I dedicated an entire paragraph above that comment to pointing out moral possible legal problems, and used "perhaps" as an explicit indicator of uncertainty and doubt. The moral issue isn't particularly grey. The legal one...
There are various attributions for "Mozilla Contributors". Does that technically suffice under either the license terms or in juristictions which recognize authors rights? (What juristiction(s) apply - hosting provider, Mozilla's headquarters, or perhaps the original authors?) Do they perhaps more explicitly attribute the original authors elsewhere? Certainly stripping names from an explicit copyright header would almost certainly be a license violation, but does flattening VCS history in the manner also count as one? Did CC licensing terms apply at the time of previous CMS conversions? Were there perhaps contributor agreements and/or clickwrap licensing agreements previously which would've made this legal? Are there more buried attributions which might technically meet the burden of attribution while still being done poorly enough to feel slighted? Perhaps in some juristictions but not in others?
Can you answer all that with enough certainty as to assert that you "have any idea what you're talking about"?
> What is it about Mozilla that attracts this sort of thing?
Both sides offering takes that reveal that neither has any idea what they're talking about is far from unique to threads involving Mozilla. I dare say it's not even unique to the internet.
Also not grey—same as before.
> Can you answer all that with enough certainty as to assert that you "have any idea what you're talking about"?
Hey there. I'm a former Mozillian. I was a heavy contributor to Devmo in its early days (2006–2008). A bunch of that content is mine. It's not Mozilla's, and I know on what terms I made it available. So to answer your question quoted above (a) yes, in fact, I do know what I'm talking about, and (b) I don't have to be able to give an answer for every slot in your contrived matrix; it suffices if I'm able to say, "hey, you can't do that with the pieces that belong to me". And that's something that I can say—with certainty.
What’s happens in the real world is that you abide by contractual agreements and if a party breaks the agreement, you sue them for breach of contract. This also requires that you can sue them for breach of contract. Otherwise, you can kick dirt.
Understand now?
Yeah, they do owe something: they owe the attribution which is a condition of the Creative Commons license which is what license the content is available to Mozilla (and everyone else) under.
> You should consider attribution a privilege.
Absolutely not. That's not how copyright works. What a deluded, entitled take.
But from the social contract, attribution is a perfectly fair expectation for this kind of work -- especially because at the time of, and even going forward, attribution was given. It may not have been codified as a public contract, but the relationship was, and is, quite clear.
And the breaking of that relationship for fairly arbitrary reasons (it couldn't be imported/converted?) is a pretty damn good reason to be annoyed -- hell, what other reason would you consider valid? If it was financial rather than social, you don't get angry, you get even (lawsuit).
Now I'm getting annoyed as I write this; its not a fucking privilege to have been given the honor of doing volunteer labor, and its not a fucking privilege to be given attribution for it -- it's like the most basic free compensation you can give for free work. It's a norm across the board
Perhaps legally, in this case, they're owed nothing - but it's not unreasonable to consider stripping said attributions to be a dick move, even when legal. Maybe unsuprising, but a dick move nonetheless.
GP is venting some anger here at a relevant moment and the perspective is obviously valuable.
Mozilla is allegedly an open source project, so yes they owe you things based on free software principles, such as attribution and right to fork.
This is a longstanding debate in wiki/collaboratively written content, but it it interesting to note that Wikipedia and the other WMF projects have been pretty successful with the anyone can edit, revert or fix after. The review first model is used on specific pages, where it is called pending changes protection, although this is not really like a PR in that there is no comment functionality, and the standard for acceptance is lower--I don't remember the exact wording but it is closer to "this is not vandalism/not obviously wrong" rather than "I personally endorse this" much less "this is the community consensus." These edits have no special endorsement once approved and can still be changed by other editors freely. One benefit of the PR model is finality, once an issue/PR is decided no one else is supposed to open another one with virtually the same change. Wikipedia sort of has that via article talk pages, but there is of course no centralized "maintainer" to adjudicate each and every controversy. Also, many editors just don't check or even understand them.
On the other hand, MDN is probably sufficiently narrow in scope that a team of subject matter experts can competently manage contributions in a timely manner. Of course, by "narrow" I do mean basically every technology currently in use on the web, so... guess we'll see how realistic that is!
The more quality control you need the more often you just let the contributor prove themselves first. Meaning, you don't automatically approve their submissions, but you don't completely prevent them from writing either, at least for as much as your community have the resources to review.
Frankly, I always felt the wiki model pretty much a show-stopper to making any real edits with no good UI for commit review and a good UI for having a granular discussion about your changes. Instead the UX is to burn a lot of time getting a large change through a bunch of potential reversion cycles while trying to communicate through talk page(s). It's a hoop that selects for die hards.
To be fair, maybe people should view MDN skeptically just like they do Wikipedia. But I think it's valuable for it to be a reliable source and review-first is a good way to maintain that.
Translations aren't even that expensive, especially relative to the cost of producing the docs in the first place. It hurts me to see MDN so starved of resources that they can't pay for even that small piece.
MDN has been key to so many people's technical education. High-quality web documentation is an essential resource for those looking to elevate themselves into a technical career these days.
Much of the world (20%, according to their own research) is set to lose access to this vital body of knowledge.
> Note: In addition, the text of the UI components and header menu will be in English only, going forward. They will not be translated, at least not initially.
But that's the easiest part! I understand the part about translations becoming stale, and how it's hard to manage, but honestly, translating a UI isn't that hard.
I think a good recipe to get better translations is:
- Don't treat it as an aftertought. Co-locate the en-US assets with the translated versions, that way your contributors actually see that there are other languages to support. Each page on the MDN website should be a folder containing a file for each language.
- If a translation is out-of-date, link to these more recent languages, and offer an auto-translated version in the meantime. Importantly, let the user switch between the automatic translation and the manual one. Also, make it obvious how they can contribute.
Ideally, you would have a master document in which some parts are shared across all translations (like the layout, the actual terms in the spec, browser compatibility information, etc), while other parts were localizable (like the field descriptions). Then when content was added/changed, it would be clear which parts of the translations needed updating, and you could either flag them as such for volunteers, or use machine translation as a stop-gap, or both.
With the architecture they described, however, your options are either to make the translations completely independent or to make translations completely machine translated, neither of which is a good solution.
I mean I don't think it's actually that big of a deal as long as they stick to basic HTML markup (paragraphs, bold/italics, etc), but you're already running into problems when you add links.
Not having multi-language support as a first-class citizen is a step backwards IMO. Especially considering the world is still getting connected at an enormous rate.
Personally I had some very good experiences with some translators, and it could work even better if Mozilla manages to tune and train them properly. (Like making so that manual fixes improve the algorithm)
Like I said in another comment, approximately nobody translates technical documentation for fun.
https://en.wikipedia.org/wiki/Province_of_Soria
https://es.wikipedia.org/wiki/Provincia_de_Soria
Notice that the English page seems obviously translated by a non-native speaker, which has some implications not favorable to Mozilla's behavior here, specifically that ESL people will contribute documentation in English that native English-language speakers won't even provide for themselves.
I was thinking more like https://www.mediawiki.org/wiki/Download vs https://www.mediawiki.org/wiki/Download/es
Your comment is the same as people who saw the launch of Wikipedia and wondered who could possibly write articles and find citations for fun.
Hell, who would write hundreds of thousands of wiki articles about The Elder Scrolls universe for fun? https://en.uesp.net/wiki/Main_Page
70k articles, not hundreds of thousands,[1] and of those 70k fewer than 1/3 are translated to any other language.
And speaking as someone who was a system and content admin for a MediaWiki-powered fiction wiki of about 15k articles... there are not many people relative to the amount of content who are actually interested in contributing anything, much less improving or maintaining what's already there. It's a very, very small core of contributors.
Toward your example, the 161 "active" users[2] (meaning any number of edits in the last 30 days) as of today on English UESP combined for 5,974 edits in that span. Of those edits, 4,779 were from 13 users. 3,039 — more than half of the last month's activity — were from the top 5 users.
On the non-English UESPs? No active users in Portuguese, one in Italian, none in Arabic.[3][4][5]
From my experience at least, it's because it's work — fun work, at times, but still work. Translating MDN content is also work. Doing _any_ documentation of _anything_ is work. Hell, I burned out on fiction documentation work before I burned out on paid work.
Some people do enjoy it! But voluntary documentation is still going to attract a small, specific core group of consistent contributors (if it attracts any at all).
[1] https://en.uesp.net/wiki/Special:Statistics
[2] https://en.uesp.net/w/index.php?title=Special:ActiveUsers&of...
[3] https://pt.uesp.net/wiki/Especial:Utilizadores_activos
[4] https://it.uesp.net/wiki/Speciale:UtentiAttivi
[5] https://ar.uesp.net/wiki/%D8%AE%D8%A7%D8%B5:%D9%85%D8%B3%D8%...
I change, I publish, it's done. And if my change was wrong, or opinionated, or bad, it's just like that until somebody else catches it and fixes it back.
It seems to me that as far as the browser makers are concerned, MDN is as close to authoritative as you can get without going to the standards documents themselves - and the standards don't give you browser compatibility matrices or make any note of browser-specific quirks.
MDN may be a wiki, but it certainly isn't treated like one by the people who are most interested in it being accurate and up to date.
"Authoritative reference documents of MDN are going to become cluttered with comments and disagreements"
Which suggests previously authoritative docs are becoming less so due to being editable. I'm just pointing out they are and always have been subject to edits from the public. If anything the PR process will likely increase the reliability of the info because there would be a chance to do some vetting of changes.
I totally agree that MDN is as close to authoritative as you can get, but it's one (important) step away.
Every recent review I've seen of Wikipedia vs arbitrary big-a Authoritative sources has said that both have issues and overall Wikipedia is better.
This is seriously entitled. Mozilla gave us an amazing resource, entirely for free. This attitude isn't right, it's toxic and harmful.
Mozilla is in a spot of difficulty, and instead of taking a resource that is operating entirely at a loss down, they're taking the engineering steps to ensure thez resource can outlive them.
That their mismanagement caused them the difficulty is entirely irrelevant here. It could have happened in a myriad of other ways. We should be praising Mozilla and the MDN tech team for the steps they're taking in making sure the MDN can live on.
Hint: it's less than $200.
Donations don't really work.
Just to be sure, are you referring to the "BuyMeCoffee" button on the GitHub page for the extension (https://github.com/VSCodeVim/Vim)?
That's what I expect of a non-profit organization dedicated to maintaining one of the last two remaining major browser engines, yes.
Now that antitrust is happening anyways, Google's main reason for shoveling money at them is going away.
It's not like they were extremely profitable and fired people to squeeze an extra buck
Laying off people isn't inherently evil
They had electron effectively a decade before electron with XULrunner and let it die on the vine.
There were opportunities for developer mindshare and for services adjacent to those tools they were already building... that they didn't do more for getting Thunderbird more competitive to Outlook to offering a better breed of messenger platform.
No, their management sat on fat cash, with fat paychecks and ill-conceived projects that lead to little in terms of mindshare or income longevity.
Sure, one can rant all one wants about management's lack of business acumen, but that's completely separate from the issue of the layoffs
But if what you said does happen, then RIP. It's not going to be the same - everyone is too busy writing medium articles to sell their course on udemy to make real contributions for free.
There were a lot of useful guides showing practical applications of features beyond just listing the api spec.
But I guess it'll still be useful as a more approachable wiki to api standards rather than having to go to w3schools (yuck) or the horrible ui of w3c.
PR model via GitHub, good.
That new platform schema diagram for Yari, looks complicated.
This is a similar tactic that MS has been using towards their documentation as well, so it's not so bad and for those most likely to contribute to technical documentation like this, the overlap with Github is significant enough.
What about the content part of it? Is it the hope that the move to GitHub and PR model will encourage broader community contribution and thus make up for the sad lack of dedicated content writers?
It's Javascript, API, Markup. Put "pre-rendered" before "Markup" and you understand everything.
Maybe they do this because they really want to push the fact that you can serve the J and M from a CDN?
Real-time: dynamically generated on the server-side. (e.g. injecting the current user's username)
Occasionally: Jamstack (e.g. rebuilding a static site every time a contributors adds a blog post via the CMS)
Rarely: manual updates (e.g. manually deploying a new version of a small-town restaurant's website when the menu changes)
Jamstack is static sites/headless CMS, CDN for content/storage/speed, microservices/apis for data/auth/etc focused on speed, pre-rendering, and decoupling for easier swappable parts rather than monolith. [1]
[1] https://jamstack.org/what-is-jamstack/
It pushes the page rendering from runtime to build time.
With a Wiki, even non-technical users can contribute, because the editing tools are all built in.
But with the PR model, now contributors need to understand HTML, CSS, Git, and GitHub PRs. I've been on GitHub for something like 10 years and I still have trouble figuring out PR workflows.
Making simple edits like grammar or punctuation fixes become significantly more effort in performing the submission than in performing the edit itself.
Wanting to have control over the submission process to prevent drive-by vandalism is certainly important. But that should be managed with role-based authentication and new users needing to have their edits approved by a moderator or by votes from long-term users in good standing. Once again, this sounds like the same old Mozilla line of "doing the right thing for the current user experience is too hard for our developers, so we're going to move the goalpost instead."
Compared to MSDN, MDN isn't as broad, but goes a lot deeper on topics, and has much better examples. Does Microsoft wring its hands over how much running MSDN costs, to the point of considering giving it up entirely? I don't think they do. I think they know that it's important to keep developers on-platform, in-ecosystem, and they do that by offering a comprehensive learning resource.
MDN is the best online resource for learning about Web technologies. I think a large part of that is because of the relatively low friction to edit. It not making Mozilla any money is completely their own fault. They could have taken that a step further and started offering training services and events. It stretches belief that you could have such a popular resource and can't figure out some sort of monetization strategy related to it. But, I guess, that's another of the same, old Mozilla lines.
Microsoft revenue stream is slightly more reliable than Mozilla's reliance on Google.
So... Ceding control over content to GitHub. Ceding control over uptime to Amazon. (Both done by a company that paints itself as pro-people, pro-privacy, etc.)
>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.
The fact that this is presented as some sort of improvement is pure farce.
The job of people who would have to check and approve the PRs becomes harder, too.
----
"You need permission
This form can only be viewed by users in the owner's organization."
Guys....
> Microsoft is joining Google, the W3C, and Samsung to make Mozilla’s MDN Web Docs as the single place for web API reference.
Now that Microsoft is on Chromium, and THAT is also documented in MDN, and Google and Microsoft both own public cloud providers.. I feel like this move is more a step in the evolution of MDN rather than Mozilla simply sending it out to pasture.
Will the quizzes disappear in the near future ? I was planning on brushing up my html/css/js skills and I was planning on doing it through MDN.
This would be a more solid argument if they were using a lot of AWS features together, but you could replace this with Minio and FastCGI if you really wanted to.
Shows two flowcharts, of which the new one is arguably more complex.