🎉 First of all, thanks for taking the time to contribute to MDN Web Docs! 🎉
The following is a set of guidelines for contributing to the content of MDN Web Docs, which is hosted within the MDN Organization on GitHub.
Note: Just want to find a task and jump in? See Getting started on MDN for an overview of how to join, and Contributing to MDN for a filtered list of tasks.
Everyone participating in this project is expected to follow our Code of Conduct.
When contributing to the content you agree to license your contributions according to our license.
A good place to learn about general guidelines for contributing to MDN Web Docs is the Guidelines document. For example, you can find out more about MDN's writing-style guidelines via the Writing style guide.
We expect contributors to MDN to have a certain amount of prerequisite knowledge before they start working on the content. If you are new to the following topics, we'd advise you to look at the provided links to help you get up to speed:
- Web technologies: If you are new to HTML, CSS, JavaScript, etc., check out our Learn web development tutorials.
- Open source: If you've never contributed to an open source project before, have a read of Basic etiquette for open source projects.
- Git and GitHub: If you are unfamiliar with these tools, GitHub for complete beginners will get you started.
- MDN's repo structures: If you are not sure what repos to edit to make changes to the different parts of MDN's content, Where is everything on MDN? will point you towards the correct places.
No matter how you wish to contribute, you'll need
a GitHub account if you don't have one already.
If you're not familiar with git
and
GitHub
, you might find the
MDN Git and GitHub document
helpful.
There are several ways forward from this point. It's up to you. Here are some options:
- Go to https://github.com/mdn/content and just use the GitHub UI. This is the easiest approach if you just want to make a simple change to a single file, like fixing a typo.
- Install and use the GitHub Desktop
- Install and use the GitHub CLI
- Install
git
and use it from the command line. You might find these resources helpful:
If you choose an option other than the GitHub UI, you want to install
Node.js (version >=12.11) and yarn
.
These are some important things to keep in mind about the MDN content.
-
A document's main content is written in an
index.html
or anindex.md
file -- We're currently in the process of converting our content from HTML into Markdown. Pages that are in HTML have their content in a file called "index.html". Pages that are in Markdown have their content in a file called "index.md". -
Documents are folders -- Documents are always represented by a folder (e.g.,
files/en-us/web/javascript
), and that folder will contain the content of that specific document as anindex.html
orindex.md
file (e.g.,files/en-us/web/javascript/index.md
). -
Documents are hierarchical - A document folder may contain other folders, where those folders would represent child documents (e.g.,
files/en-us/web/javascript/closures/index.md
). -
Document folders may contain image files -- A document folder may also contain image files, which are referenced within that document's
index.html
orindex.md
file. -
All redirects are specified in a single file -- All of the redirects are specified within
files/en-us/_redirects.txt
, one redirect per line. Each line specifies afrom
andto
URI separated by whitespace. When you move a document, you'll need to add a redirect to this file specifying that its old URI now redirects to its new URI. Both of these tasks are done using theyarn content move
tool — see Moving one or more documents. -
Don't edit the
_redirects.txt
file manually! If both anindex.html
orindex.md
file and a redirect exist for a document, the document takes precedence and the redirect is ignored. -
A document's
index.html
orindex.md
starts with "front-matter" -- Each document'sindex.html
orindex.md
file must begin with some YAML called front-matter that defines some important information about the document:title
,slug
, andtags
(if any). Here's an example that shows the front-matter from the JavaScript landing page:--- title: JavaScript slug: Web/JavaScript tags: - JavaScript - Landing - Landing page - Learn - 'l10n:priority' ---
If you just want to make a simple change to a single file, like fixing a typo,
the GitHub UI is the simplest way to do that. For example, if you've found
a typo within the JavaScript landing page,
you can sign into GitHub, go to https://github.com/mdn/content,
navigate to the source file files/en-us/web/javascript/index.md
,
and then click on the edit (pencil) button.
Tip: Click the Source on GitHub link in the footer of any MDN page to jump to its source file on GitHub.
From there the GitHub UI will take your hand and
walk you through the rest,
like automatically creating a
fork
and branch to commit your changes to, as well as helping you reach the
ultimate goal, a pull request.
Your pull request represents the work you want to be reviewed,
hopefully approved, and then merged into the main
branch of this repository.
Note: See the pull request etiquette section for more details on creating and handling pull requests successfully.
If you're not certain of the changes that you want to make, get in touch with us first! You can chat with us or file an issue.
You may be asked to further edit files in your pull request. To open a file for editing, select the Files changed tab on the PR, scroll down to the section for the file you want to edit, and then select the "three dots" icon (at the top right of the section). Choose Edit file from the popup menu to start editing the file. After editing, your changes will result in a new commit.
If you need to do some work that requires changes to more than one file, like
moving one or more documents, the GitHub UI is not very efficient.
You'd have to make a separate pull request for every page you want to change.
Instead, you're going to have to use git
or one of the other
git
-based approaches like the
GitHub Desktop.
-
You'll want to create a fork of this repository, so you can freely experiment with branches and changes in your own copy before submitting your changes as a pull request. Let's assume your GitHub username is
octocat
. Your fork would be a copy of this repository but in your own account, sohttps://github.com/octocat/content
. -
Once you've created your fork on GitHub, you'll want to clone it locally. For example, assuming again that your GitHub username is
octocat
, you would do something like the following:cd ~/repos git clone [email protected]:octocat/content.git mdn/content
-
You'll also want to create a
remote
to the main repository (https://github.com/mdn/content), which you'll use to keep your local clone as well as your fork (https://github.com/octocat/content
) up-to-date. For these examples, we'll name itmdn
, but you can name it anything you'd like.cd ~/repos/mdn/content git remote add mdn [email protected]:mdn/content.git git remote -v
-
When you run the
git remote -v
command above, you'll see that you have two remotes:mdn
andorigin
. Theorigin
remote is the default name thatgit
has assigned to your fork (https://github.com/octocat/content
). -
Once you've created your local clone, there's no need to do that again next time you want to make a contribution. However, each time before you start a new chunk of work make sure you update your local clone. The following checks-out your local clone's
main
branch, fetches the latest content from themain
branch of themdn
repository and merges it into your localmain
branch, and finally checks out a new branch calledmy-work
(you can call it anything you'd like) for you to work within. When you're ready, you'll push yourmy-work
branch to your fork and use it to make a pull request.cd ~/repos/mdn/content git checkout main git pull mdn main git checkout -b my-work
-
Next, you'll want to start the local preview service, so you can see the changes you'll make as they would look in production. Once started, this local preview service is available at
http://localhost:5000/
within your browser.# Switch to a separate terminal. cd ~/repos/mdn/content yarn yarn start
-
When browsing a page locally, you can press the Open in your editor button to edit the associated
index.html
orindex.md
file.To specify VS Code as your preferred editor, create a file named
.env
in the root of your localcontent
directory that contains the following line:EDITOR=code
You can create the file from a terminal using
bash
or PowerShell with the commandecho 'EDITOR=code' >> .env
.EDITOR
is an environment variable. You can set it to any editor you like using the normal mechanism for your operating system/shell (i.e. you don't have to use the.env
file or VS Code). -
Make your desired changes to one or more
index.html
orindex.md
files using your preferred code editor. When thinking about your desired changes, it's important to keep the following in mind:- Make sure you've read the MDN guidelines, including the Writing style guide.
- If you're editing a Markdown file, see the guide to writing Markdown for MDN.
- Large chunks of work can be difficult to review, so try to group your changes into the smallest logical chunks that make sense, and create a separate pull request for each logical chunk.
-
Once you've made and saved your changes, open a browser, and navigate to the page(s) you've changed. For example, if you changed
files/en-us/web/javascript/index.md
, openhttp://localhost:5000/en-us/docs/web/javascript
in your browser. -
You might have noticed that at the top of each page that you preview, for example the
http://localhost:5000/en-us/docs/web/javascript
page, there is aShow flaws
button. Click on that button to see if your changes have introduced flaws on the page. You can also fix flaws on a particular page by running the command:yarn content flaws <slug>
-
Once you're happy with your changes, add and commit them to your branch, and then push the branch to your fork. Remember, the default name that
git
assigned to the remote that represents your fork isorigin
.cd ~/repos/mdn/content git add . git commit git push -u origin my-work
-
You're now ready to create a pull request.
-
Once you've created your pull request, sit back, relax, and wait for a review. You do not need to request a review. One or more reviewers will be selected for you automatically. Your pull request will have to be reviewed and eventually approved before it's merged into the
main
branch, and then later (within 48 hours) published on MDN Web Docs. Along the way, you may be asked, not only to answer questions about your work, but to make changes as well. Don't worry, that's a common and natural part of the process. See the pull request etiquette section for more details on creating and handling pull requests successfully.
Here are some important rules of etiquette to remember when working with pull requests.
-
When you submit a pull request, a number of tests are automatically run as GitHub Actions (see .github/workflows). If one or more of these tests fail, it is your responsibility to try and resolve the underlying issue(s). If you don't know how to resolve the underlying issue(s), you can ask for help. Your pull request will not be approved and merged if these tests are failing.
-
If your pull request has merge conflicts with the
main
branch (GitHub checks for this automatically and notifies you), you are responsible for resolving them. You can do this by merging themain
branch into your branch (git pull mdn main
), and then pushing the updated branch to your fork (git push
). -
An alternative strategy is
git rebase
ofmain
on your branch. This will rewrite the git history and might confuse reviewers as notifications from GitHub lead to nowhere. Your changes are replayed on top of the current main branch at that point in time. -
Each pull request should contain a single logical change, or related set of changes that make sense to submit together. If a pull request becomes too large or contains too many unrelated changes, it becomes too difficult to review, and may begin to look suspicious (it is easier to hide malicious changes in a large pull request). In such cases, the reviewer has the right to close your pull request, and ask that you submit a separate pull request for each logical set of changes that belong together.
-
If your pull request contains any kind of significant complexity (it contains technical changes, and isn't just a typo fix, grammatical improvement, or formatting/structural change), please describe why you're making the change and anything else we need to know about it.
- If the pull request is simple (it is really clear what has been changed and why, and the change is obviously a good thing), you can do this in your pull request's description.
- If the pull request is complex (the changes and the reasoning behind
them need a bit more explanation), then the requestor should file an
issue describing the intended change first, and seek discussion/approval
as needed. When the time is right to submit the PR, they should
reference the issue (or an existing issue that describes the motivation
for the change) in the PR. You can reference an existing issue
using
#
followed by the issue's ID, for example#1234
. - Pull requests should not contain large amounts of grammar updates. Seemingly insignificant changes can change the meaning of technical content, so these need a careful review. Keep in mind that MDN contains technical documentation; you should not report merely basic improvements in the grammar but only cases where the grammar is incorrect.
-
Do not re-open a pull request that a reviewer has closed.
Adding a new document is relatively straightforward, especially if you can
start by copying the index.html
or index.md
of a similar document.
There are only a few things to keep in mind:
- Documents can be authored in either Markdown or HTML. However, we're converting
the site to Markdown one section at a time, and don't want to mix authoring
formats within a section. At this point we have only converted the JavaScript
documentation. So if you are adding a new document under
files/en-us/web/javascript
, make it a Markdown file. Otherwise make it an HTML file. - Remember that a document is represented by an
index.html
orindex.md
file within its own folder. - Determine where in the document hierarchy your document belongs. For
example, if you're
creating a new CSS document for a new property
foo
, you'll want to create a new folderfiles/en-us/web/css/foo/
and itsfiles/en-us/web/css/foo/index.html
file. - Remember that a document's
index.html
orindex.md
file must start with front-matter that defines thetitle
,slug
, andtags
(if any) for the document. You might find it helpful to refer to the front-matter within a similar document'sindex.html
orindex.md
.
As we outlined above, the step-by-step process in general would be:
-
Start a fresh, up-to-date branch to work within:
cd ~/repos/mdn/content git checkout main git pull mdn main # Run "yarn" again just to ensure you've # installed the latest Yari dependency. yarn git checkout -b my-add
-
Create one or more new document folders, each with their own
index.html
orindex.md
file. -
Add and commit your new files, as well as push your new branch to your fork:
git add files/en-us/folder/you/created git commit git push -u origin my-add
-
And finally create your pull request.
Moving one or more documents, or an entire tree of documents is easy, because we've created a special command that takes care of the details for you:
yarn content move <from-slug> <to-slug> [locale]
You just have to specify the slug of the existing document that you'd like
to move (e.g., Learn/Accessibility
), as well as the slug of its new
location (e.g., Learn/A11y
), optionally followed by the locale of the
existing document (defaults to en-US
).
If the existing document that you'd like to move has child documents (i.e.
it represents a document tree), the yarn content move
command will move
the entire tree. For example, let's say you want to move the entire
/en-US/Learn/Accessibility
tree to /en-US/Learn/A11y
:
-
First, as we've outlined above, you'll start a fresh branch to work within:
cd ~/repos/mdn/content git checkout main git pull mdn main # Run "yarn" again just to ensure you've # installed the latest Yari dependency. yarn git checkout -b my-move
-
Perform the move (which will delete and modify existing files, as well as create new files):
yarn content move Learn/Accessibility Learn/A11y
-
Add and commit all of the deleted, created, and modified files, as well as push your branch to your fork:
git commit -a git push -u origin my-move
-
Now you're ready to create your pull request.
Important: yarn content move
automatically adds the necessary redirect
information to the _redirects.txt
file so that the old location will redirect
to the new one. Don't edit the _redirects.txt
file manually!
mistakes can easily creep in if you do. If you need to add a redirect without
moving a file, talk to us about it.
Deleting one or more documents, or an entire tree of documents is also easy, again because we've created a special command that takes care of the details for you:
yarn content delete <document-slug> [locale]
You just have to specify the slug of the existing document that you'd like
to delete (e.g., Learn/Accessibility
), optionally followed by the locale
of the existing document (defaults to en-US
). If the existing document
that you'd like to delete has child documents (i.e. it represents a
document tree), you must also specify the -r, --recursive
option, or
the command will fail.
Important: you need to use the delete
command to delete MDN documents. Don't
just delete their directories from the repo, as delete
also handles other
necessary changes such as updating the _wikihistory.json
file.
For example, let's say you want to delete the
entire /en-US/Learn/Accessibility
tree:
-
First, as we've outlined above, you'll start a fresh branch to work in:
cd ~/repos/mdn/content git checkout main git pull mdn main # Run "yarn" again just to ensure you've # installed the latest Yari dependency. yarn git checkout -b my-delete
-
Perform the delete:
yarn content delete Learn/Accessibility --recursive
-
Add a redirect (if needed).
-
Add and commit all of the deleted files, as well as push your branch to your fork:
git commit -a git push -u origin my-delete
-
Now you're ready to create your pull request.
Note: If the slug of the page you wish to delete contain special characters, include it in quotes:
yarn content delete "Mozilla/Add-ons/WebExtensions/Debugging_(before_Firefox_50)"
If you are moving a document as shown above you don't need to create a redirect. However, you may need to when deleting a document or otherwise fixing up a broken link.
The best way to do this is to use the yarn content add-redirect
command:
-
Start a fresh branch to work in:
cd ~/repos/mdn/content git checkout main git pull mdn main # Run "yarn" again just to ensure you've # installed the latest Yari dependency. yarn git checkout -b my-delete
-
Perform the redirect:
yarn content add-redirect /en-US/path/of/deleted/page /en-US/path/of/target/page
Note that the target page can be an external URL or another page.
-
Commit all of the changed files, as well as pushing your branch to your fork:
git commit -a git push -u origin my-delete
Adding an image to a document is easy as well. All you need to do is add
your image file within the document's folder, and then reference the image
from within the document's index.html
or index.md
file, using an <img>
or the equivalent Markdown syntax.
It's as easy as that. Let's walk through an example:
-
You should be getting used to this by now, as we've done it several times above. Make sure you start with a fresh working branch updated with the latest content from the
main
branch of themdn
remote.cd ~/repos/mdn/content git checkout main git pull mdn main # Run "yarn" again just to ensure you've # installed the latest Yari dependency. yarn git checkout -b my-images
-
Add your image to the document folder. For this example, let's assume we're adding a new image to the
files/en-us/web/css
document.cd ~/repos/mdn/content cp /some/path/my-cool-image.png files/en-us/web/css/
-
Run the
filecheck
command on each image you add. It'll complain if something's wrong (see also the Compressing images section below). We'll automatically run this as one of the tests we run when your new pull request is created, but why wait to fix any possible issues later?yarn filecheck files/en-us/web/css/my-cool-image.png
-
Use your image within the document. For example, add the following
<img>
element somewhere insidefiles/en-us/web/css/index.html
:<img src="my-cool-image.png" alt="My cool image">
-
Add and commit all of the deleted, created, and modified files, as well as push your branch to your fork:
git add files/en-us/web/css/my-cool-image.png files/en-us/web/css/index.html git commit git push -u origin my-images
-
Now you're ready to create your pull request.
When you add images to MDN, you should make sure that they are compressed as much as possible without degrading quality, to save on download size for our readers. In fact, if you don't do this our CI process will fail and the build results will warn you that some of your images are too big.
The best way to compress them is by using the built-in compression tool.
You can compress an image appropriately by using the filecheck
command
with the --save-compression
option — this compresses the specified image
as much as possible, and saves the result over the top of the original.
For example:
yarn filecheck files/en-us/web/css/my-cool-image.png --save-compression
The browser compatibility table shown near the bottom of many of the
MDN document pages, for example on
the JavaScript Array page,
is generated from the npm
package created from the https://github.com/mdn/browser-compat-data
repository. If you'd like to make or suggest a change to the content of
the browser compatibility table on any given MDN document page, you can either
use the Report problems with this data on GitHub
link in the upper-right
corner of the table on the page itself to create an issue, or go to
https://github.com/mdn/browser-compat-data and
read more to learn how to contribute.
There are a lot of code examples on MDN, and you'll probably want to add some as you contribute content to the project. There are four types of code example used on MDN:
- Static examples — plain code blocks, possibly with a screenshot to statically show the result of such code if it were to be run.
- Traditional MDN "live samples"
— A macro that takes plain code blocks, dynamically puts
them into a document inside an
<iframe>
element, and embeds it into the page to show the code running live. - GitHub "live samples"
— A macro that takes a document in a GitHub repo inside the mdn organization,
puts it inside an
<iframe>
element, and embeds it into the page to show the code running live. - Interactive examples — Our system for creating live interactive examples that show the code running live but also allow you to change code on the fly to see what the effect is.
For a complete description of this topic, see the MDN code examples page.
Also make sure that your code examples follow the MDN code example guidelines.
Pages with the banner "This is an archived page. It's not actively maintained." at the top are archived pages — they are archived because either they are obsolete or out-of-date, or they are not in scope for MDN contributors to actively work on.
If you find a page that is marked archived and you think it shouldn't be, you can follow the below steps to unarchive it:
- Submit an issue to check why the page is archived and if it should be unarchived.
- Find the source code location of the archived page. Archived pages live in
the Archived content repo,
the structure of which is the same as this repo (except that there are
also locale directories present other than
en-US
). As an example:- Take the archived Mobile developer challenge
page, which is at the URL
https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/Mobile_developer_challenge
. - This page's source code is at https://github.com/mdn/archived-content/blob/main/files/en-us/mozilla/mobile/mobile_developer_challenge/index.html.
- Take the archived Mobile developer challenge
page, which is at the URL
- To unarchive the page, you need to open a pull request to move the page's
directory into the appropriate place inside this repo, and update the
page's meta data (like
slug
) if needed.
Note: To archive a non-archived page, you need to follow the above procedure, but move the page in question the opposite way between repos. When removing the page from MDN, remember to use the delete command.
Note: You can have an archived page with non-archived pages below it in the
hierarchy, and vice-versa. To achieve this you need to have the same directory
structure in both the content
and archive-content
repos. Whether a page
is non-archived or archived depends on which repo its index.html
file is
in. As an example, compare the archived-content mozilla directory
with the content mozilla directory.
Both locations represent the same directory structure, but the
index.html
file appears in the latter, therefore the page is not archived.
Some MDN content is created from external data files or repositories using KS macros. Generally you should create a PR to first update the external content before updating the associated MDN pages.
Relevant external content includes (non-exhaustively):
- GroupData.json:
Data definition of
Sidebars
used by
{{APIRef}}
macro. - https://github.com/mdn/interactive-examples:
Source code repo for interactive examples inserted using the
{{EmbedInteractiveExample}}
macro. - https://github.com/mdn/learning-area: Source code repo for examples referenced in the Learning Area
- JSON structured data
provides more information about JSON data used to define inheritance diagrams
(
{{InheritanceDiagram}}
macro), specification tables, etc.
After your pull request is merged, it may take up to 48 hours before the change goes live on the production https://developer.mozilla.org/ site, but it will usually be quicker.
- The complete build runs every 24h at around 7PM US/Eastern time, and is then deployed.
- Once deployment has occurred, it can take up to 24 hours for the associated CDN caches to replace their previously-cached content with the updates.
You can use https://whatsdeployed.io/s/DLi/mdn/content to see if your change has been deployed to the production site. And use https://whatsdeployed.io/s/16d/mdn/translated-content for changes to the https://github.com/mdn/translated-content repo.
In general, we do not approve of copying content from other sources and putting it on MDN. MDN should be made up of original content wherever possible. If we receive a pull request and discover that it contains plagiarized content, we will close it and request that the submitter resubmit the change with the content rewritten into their own words.
If someone wants to donate an article to MDN that they previously published on their blog or it makes sense to copy a complex reference sheet to MDN there may be justification for republishing it. In these cases you should discuss your plan with the MDN team first:
- Include a comment on the relevant repo issue that explains your intention — say what you would like to copy (include the URL) and explain why you think this is appropriate.
- If the content is published under a closed license:
- If you hold the rights to the content, state this, and say that you are happy to republish it on MDN.
- If you do not hold the rights to the content, include the author/publisher on the issue if possible, or include details of how they could be contacted so we can ask them for permission to republish the content.
- If the content is published under an open license, say what it is, and link to the license so we can check whether it is compatible with MDN's license.
- @-mention chrisdavidmills on the issue, so he can review the request.
Be warned that unless there is a good reason to republish the content, we will probably say "no". The MDN writing team's decision is final.