mdn/mdn: Planning and governance for MDN Web Docs

mdn/mdn tracks proposals and MDN team coordination

mdn/mdn solves an organizational problem within MDN Web Docs: it gives MDN contributors a common place to track team work and submit formal requests. The README says the repository is used to track MDN team work, while the organization's public projects contain current and upcoming tasks. This distinction matters because the repository is not presented as a local copy of the documentation site. Its job is coordination, with issues and templates providing the routes into governance processes.

The primary audience is contributors who want to influence MDN content or its maintenance structure. That includes people proposing new content or features, people nominating an invited expert, and people nominating a co-maintainer. The repository therefore serves contributors who need an administrative decision path rather than developers looking for JavaScript, CSS, HTML, or documentation-site source files.

The repository is not archived, and its last push was on 2026-10-07. That supports describing the repository as recently changed, but the README does not state a release cadence or promise that every listed process is continuously active. There are also no GitHub releases, so versioned adoption decisions do not apply here.

mdn/mdn uses GitHub issues as governance entry points

The documented mechanism is issue-based routing. The README links to GitHub's issue chooser for three processes: proposing new content or features for MDN Web Docs, nominating an invited expert, and nominating a co-maintainer. The top-level `.github/` directory is consistent with the README's reference to issue templates. Based on the repository layout, requests enter through structured forms rather than through commits to documentation source.

This design keeps planning records close to GitHub collaboration. A contributor does not need to infer a submission format from unrelated project files. The chooser is the documented starting point, and the selected process determines which template and questions apply. However, the repository layout does not provide the contents of those templates, so it would be incorrect to promise particular fields, review times, approval rules, or required evidence.

The README also points to MDN's public GitHub projects for current and upcoming tasks. In practical terms, those project boards answer what MDN is already scheduling. The issue process handles requests that need to be raised through one of the documented governance routes. The README does not say how board status, issue approval, and eventual content work are synchronized, so that connection should not be assumed.

Invited expert nominations are organized by subject ownership

The README names invited experts and their subject areas. Joshua Chen is listed for JavaScript, Hidde de Vries and Scott O'Hara for Accessibility, André Jaenisch for SVG, and Mendy Berger for WASM. This is useful context for the nomination process because it shows that invited expert status is associated with a technical domain.

The repository gives a GitHub link for each person, but it does not explain how nominees are evaluated, how expertise is verified, or whether an invitation can be renewed or withdrawn. It also does not state whether having a listed expert changes who may review articles in that subject. A contributor should therefore treat the list as governance information, not as a complete description of editorial authority.

To nominate someone, the README gives one direct instruction: file an issue in this repository. It does not provide a command-line workflow or a separate nomination form in the README. The linked issue chooser is the operative interface. Anyone preparing a nomination should gather evidence relevant to the proposed subject, but the README does not specify acceptable evidence or selection criteria, so those requirements need to be read in the chooser before submission.

Co-maintainer nominations require a separate governance route

Co-maintainer nominations are listed separately from invited expert nominations. That separation indicates at least two kinds of contribution to recognize: subject expertise and broader maintenance responsibility. The README does not define the duties of a co-maintainer, the expected level of participation, or the approval chain.

This missing detail is a real constraint for contributors. Someone may understand what co-maintainer nomination means in general, but the repository text does not establish how the role is scoped or what commitment it asks. The issue chooser is still the documented starting point, and the nomination should be initiated there rather than through an improvised pull request.

The two nomination routes should not be conflated. An invited expert entry is accompanied by a named subject area, whereas a co-maintainer entry has no equivalent subject list in the README. A prospective co-maintainer should therefore review the current chooser and public project information for the exact requirements. The repository does not document a rollback process for a nomination or a formal appeal path, so those decisions cannot be stated as part of the published process.

Starting with mdn/mdn without installing the documentation site

There is no installation command in the README, and that is appropriate for the repository's stated purpose. It is a planning and request-tracking repository, not a packaged application or documentation build. The visible top-level entries, including `.github/`, governance documents, the README, and `spotlight-contributors/`, do not describe an installable runtime.

For a first real use, begin with the public projects board to determine whether the proposed work is already listed as current or upcoming. Then open the relevant process through the repository's issue chooser. The chooser offers new content or feature proposals, invited expert nominations, and co-maintainer nominations. The reader should confirm that the form corresponds to the intended route before writing a full submission.

The repository does not state any clone, build, test, or server command, so none is included here. A contributor who wants to edit the pages of MDN Web Docs should follow the linked MDN repository guide instead. That distinction prevents a common category error: cloning `mdn/mdn` and looking for page templates will not produce an editable MDN Web Docs checkout, because the README assigns this repository to team work tracking and requests.

MDN's public projects remain the source for current scheduling

The README directs readers to MDN's public GitHub projects for current and upcoming tasks. That is the clearest alternative workflow for tracking work that already fits an MDN scheduling process. Instead of opening an issue first, a contributor can check whether the task exists on a project board and follow its listed status there.

This is different from using `mdn/mdn` for a direct request. A public project provides scheduling context, while the issue chooser provides formal submission routes for content proposals and personnel nominations. Neither source is documented as a replacement for editing the actual documentation source, which the README sends contributors to through the MDN repository guide.

The separation also creates a limitation for automation. No API, export format, synchronization rule, or CLI is documented in the repository. It is therefore not possible to claim that project board entries automatically create issues, that issues automatically become tasks, or that one system is authoritative for every kind of MDN work. The documented approach is manual coordination through GitHub's public projects and the repository's issue templates.

The MIT license applies to the repository's published files under the repository's license terms. That statement identifies the declared license, but it does not establish licensing terms for MDN Web Docs content contributed through the separate content repositories. Organizations should check the relevant repository and contribution terms separately when the material at issue is documentation content rather than this coordination repository.

Editorial conclusion

Use mdn/mdn when contributing to MDN planning, proposing documentation, or nominating an expert or co-maintainer. Do not treat it as a repository for editing MDN pages or installing the documentation site. Before opening a request, check the public projects board for current work, then use the repository's issue chooser for the appropriate process and consult the MDN repository guide for actual content contributions. Based on the repository layout, this project is best understood as an administrative entry point with recent work on 2026-10-07, not as the implementation of MDN Web Docs.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. mdn/mdn on GitHub
4. Project website
5. README