MDN收录规则

如果你正准备记录什么信息，你可能想知道是否要将这些信息放入MDN。更进一步地，你可能想在你的源代码中维护文档，并将文档写入Mozilla wiki，或者写入某Git仓库的readme文件中。本文的目的是帮助你确认你的内容是否适合MDN。

文档是否应放入MDN主要取决于两点：

文档的主题（它是讲什么内容的？）
文档的类型（它是什么类型的文档？）

注意Mozilla的 Websites & Communications Terms of Use 所声明的条例在你使用MDN或对其做贡献时是生效的。检查这个文档，确保你知道在Mozilla的网站上什么是能发表的，什么是不能发表的。

哪些话题在MDN的范畴内？

MDN涉及了惊人的各种材料。总的来说，如果它是开放的面向Web的技术，或者是Mozilla的产品，我们就把它收录到MDN。但也有一小部分东西完全不属于MDN。这一节会告诉你如何确认你的文档是否属于MDN。

这里有一些我们涉及的事物；虽然这不是一个完整的列表，但是可以给你一个大致的印象。

开放的Web标准与技术

现在Web标准文档中受关注的是那些可以被Web开发者用于创建网站与App这些大众应用的功能。这指的是那些被众多浏览器所实现，要么是被标准接受，要么是正在向标准化发展的技术。即主要关注前端Web技术。后端的技术常常在别处有它们自己的文档，MDN不会去尝试取代它们。

同时欢迎关注与Web开发有关的交互技术话题，比如：

注意： MDN 涉及了非Mozilla但对Web开放的技术；举个例子，我们有关于WebKit格式的CSS属性的文档。

Mozilla 产品

这个分类的文档包括如何作为开发者使用Mozilla的产品，以及如何向这些开源项目贡献。

哪些话题不属于MDN？

举一些不适合MDN的话题：

仅适用于某一非Mozilla浏览器的不开放的Web技术。
与Web或Mozilla产品无关的技术。
面向用户的文档；对于Mozilla产品来说，这些文档应属于 Mozilla 技术支持。

哪些类型在MDN的范畴内？

In general, MDN is for product documentation, not for project or process documentation (except about MDN itself). So, if the document is about "how to use a thing" or "how a thing works" (where the "thing" is in one of the topic categories mentioned above), then it can go on MDN. But if it about "who's working on developing a thing" or "plans for developing a thing", then it shouldn't go on MDN. In that case, if the thing is being developed under the umbrella of Mozilla, then the Mozilla project wiki may be a good place for it.

Here are some examples of types of documents that should not be placed on MDN:

Planning documents
Design documents
Project proposals
Specifications or standards
Promotional material, advertising, or personal information^[*]

Advantages to documenting on MDN

If you've determined that the documentation you want to write is appropriate in content and type for MDN, but you're still not sure whether MDN is the best place for it, read on. There are a lot of good reasons to create documentation on MDN.

Lots of writers and translators

The MDN community is big. Really big. It's big in the sort of way that makes big things look small. Seriously, we have a lot of people that participate in creating and maintaining content on MDN. With writers and editors on every continent (okay, I'm not sure about Antarctica, but otherwise), there's a lot of value to the sheer volume of writers:

We have a paid staff of writers whose mission is to make sure that our content is as good as possible.
We have a core community of volunteers who contribute substantial amounts of content and can help you.
The MDN team can work with you to ensure that your documentation project is adequately staffed.
The broader MDN community also contributes enormously; from typo fixes to editorial reviews of your content, they can save your bacon.
The #mdn channel offers a resource where you can talk to our writing community and get their advice, or recruit help with the production of or maintenance of your content.
Because we have contributors all over the world, there's always someone around, watching for problems and fixing them.
Our community of volunteers includes translators for many languages, who can help localize your documentation.

Do you want your development team to be entirely responsible for the production of documentation? That's likely if your documentation is maintained elsewhere.

维护

Because of the sheer number of contributors, there's usually someone on hand to watch for problems with your content: from spam control to copy-editing, things can happen around the clock. Here's just a taste of what our team can do:

Delete spam: Spam happens. We deal with it.
Copy editing: You don't have to worry if your writing isn't as clear or precise as you'd like. We'll turn your prose into something other people can read.
Consistency of style: We'll ensure that your content is stylistically consistent not just within itself, but with the other documentation around it.
Content management: Our team will help ensure that the documentation is cross-linked with other relevant materials, that articles are put in the right places, and that menus and other infrastructure is built to make it easy to follow and understand.
Site and platform maintenance: MDN has both an IT team who keep the site up, running, and secure, and a platform development team who maintain and enhance the platform. You won't need to devote your own or additional resources to documentation infrastructure.

Cases for documenting elsewhere

There are also a few reasons you may be thinking about documenting your work somewhere other than MDN. Here are some of those reasons, and the pros and cons for each.

Plans and processes

Documentation for plans, processes, and proposals should never be put on MDN. That's pretty simple. If your project is part of Mozilla, you can put them on the Mozilla project wiki.

The project is on Github

Some of Mozilla's projects are hosted on Github, and Github offers its own wiki-like system for documentation. Some teams like to produce their documentation there. This is certainly fair and convenient if you're game to write your own docs; however, keep in mind that:

The MDN docs team will probably not be able to help you. We don't generally participate in documentation work off MDN; there are exceptions but they are rare.
Cross-linking your documentation with other relevant materials may be difficult or impossible.
The content will not have consistent style with other documentation.
Your documentation loses discoverability by not being among other (Web or Mozilla) documentation.
Github-hosted docs are generally not as attractive and/or readable as those hosted on MDN.

It's possible, of course, that these things don't bother you, or aren't a problem in your situation. Some teams don't mind keeping their own docs, or are working on code that has minimal documentation needs.

You want to keep docs in-source

Some teams like to have their documentation in the source tree. This is particularly common with project internals and library projects.

This approach has a couple of advantages:

It lets the developers document their technology as they code it, helping to ensure that the docs stay up to date with the code.
Docs can be subject to the same development and release processes as the code, including versioning.

There are some drawbacks:

The MDN docs team can't help you; even if the code is within Mozilla's source repository, the system of reviews and check-ins make it impractical for the docs team to participate.
You don't have easy tools for cross-linking with other relevant documentation. Cross-linking provides both context and additional important information to your readers.
Your documentation loses discoverability by not being among other documentation.
Even if you use conversion tools (like JavaDoc) to create Web-readable documentation, it won't be as attractive as what we can do on MDN.

Still, this can be a viable option (possibly even a good option) for some types of projects, especially small ones or those that aren't expected to get much interest.

^ It's OK to put a limited amount of personal information on your MDN profile page. User profiles should reflect a human being, not a business or organization. A moderate degree of self-promotion is OK, but link-spamming is not. Please do not use your profile to upload personal photos or other irrelevant files.