As a Web developer I want to know about the latest DOM features in Firefox 61, so that I can test and make use of new technologies.

Currently MDN articles contain HTML microdata with the https://schema.org/BreadcrumbList context.

Documentation could be enriched with JSON-LD or Microdata from the https://schema.org/TechArticle context, specially with https://schema.org/articleBody.

Code samples could also be enclosed with https://schema.org/Code or https://schema.org/SoftwareSourceCode contexts.

That would make documentation easily extractable using tools like microdata-node or jsonld.js. It'd probably increase the search rank, although I believe MDN documentation rank is already quite high.

Given the work I'm going to be doing on it, it might make sense to make me a maintainer.

https://github.com/schalkneethling/mdn-fiori

{
    "name": "mdn-fiori",
    "description": "Front-End style guide and pattern library for MDN Web Docs - Built with cupper",
    "repository": {
        "url": "https://github.com/mdn/mdn-fiori",
        "license": "MIT"
    },
    "participate": {
        "mailing-list": "https://discourse.mozilla.org/c/mdn",
        "irc": "irc://irc.mozilla.org/#mdndev",
        "irc-contacts": [
            "espressive",
            "jwhitlock",
            "rjohnson"
        ]
    },
    "bugs": {
        "list": "https://github.com/mdn/mdn-fiori/issues",
        "report": "https://github.com/mdn/mdn-fiori/issues/new"
    },
    "urls": {
        "prod": "https://mdn.github.io/mdn-fiori"
    },
    "keywords": [
        "styleguide",
        "pattern library",
        "best practice",
        "code style",
        "hugo",
        "cupper"
    ]
}

MDN docs are my No 1 go to place for documentation and I would like to see better availability of linked examples.

This is a suggestion.

The issue concerns a 3rd party service (CodePen) which has been causing severe compatibility issues over the last year.

I see more and more CodePen demos breaking (all over the web)

Sadly the team behind CodePen does not handle versioning of their libraries/compilers at all and it seems like they don't intend to change this any time soon.

Due to this issue, a lot of demos will fail to load correctly. This will continue to happen until CodePen finally wakes up and changes this behavior.

Besides this issue, CodePen has constant (increasing) server issues and is not reliable. (I had to stop using it for client prototypes).

IMHO MDN should be able to host a similar service to allow editing and playing with demos. Linking to broken Demo-playgrounds doesn't help anybody.
If CodePen links are removed the team might finally wake up and work on better compatibility.

Open for discussion and contribution.

Links:

• Currently, no broken examples found
• Service fallouts

Notes:

• Only demos using compilers/transpilers seem to be affected
• Breaking changes in Codepen happen regularly without any warning (besides a link in a newsletter)

I'm just trying to help provide better demos

I have found an issue where I am not able to get the examples working for Map. Here are the examples that are not outputting the same results that are shown in the docs:

Docs: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map
Examples: https://stackblitz.com/edit/js-wul3uj

Create a mdn.dev repository, to hold the content of https://mdn.dev.

See mdn/sprints#922

• Repo is setup (https://github.com/mdn/mdn.dev)
• Collaborators added (@schalkneethling, @davidflanagan)
• Has README
• Has LICENSE
• Has contribute.json

We should write a document that lives in this repository that explains what kind of repositories we are maintaining in this organization and what the process is to request a new one.

Such a document could contain:

• How to request a new repo in the MDN org.
• How example repositories are organized (basically "<api-name>-examples", e.g. "webassembly-examples", "webaudio-examples", webextensions-examples", etc).
• What belongs into this org and what not. My current thinking is: open web example repos, mdn infra repos (kuma, kumascript), open web data repos (data, compat data), mdn related repos (wp-plugin, atom plugin)

Hi!

I've seen CC0 license, as well as MPL-2.0

I think we should have all of them in CC0, and also indicate this in the contribution.md

I would love to add greenkeeper to the /bob and /interactive-examples repos. This will automate away the responsibility for keeping dependencies up to date. This will also ensure we do not have dependencies with security vulnerabilities.

A situation we are currently in. Thanks!

API-URL:

https://developer.mozilla.org/zh-CN/docs/Web/API/MessageChannel

DEMO-404-URL:

http://mdn.github.io/channel-messaging-basic-demo/

What is Expected?

Can I restore the demo address to help me improve my learning API?

Thank you.

As part of moving operations from MozMEAO, I'm bringing in the repo https://github.com/mozmeao/infra as https://github.com/mdn/infra, replacing a skeleton repo of the same name.

It would be good to come up with a standard README format for all of MDN's repositories. Tasks that I can think of:

• Collect format ideas
• Agree on what is mandatory to mention in a README file.
• Put a template into this repository.
• Roll out standardized README files to all of MDN's repos.

Inspiration:

• https://gist.github.com/PurpleBooth/109311bb0361f32d87a2
• https://github.com/kentcdodds/all-contributors
• https://github.com/mdn/webextensions-examples

Link on this page (at the bottom of an article refers to non-existing site: http://mdn.github.io/promises-test/)

@limed would like to transfer this repository into the MDN org:

https://github.com/limed/ansible-jenkins

For some reason, when I try to sign in/create an account with GitHub, MDN tries to send an email to the email account I originally tried to sign up for MDN with (and was connected to my GitHub account via Google). I have now changed my GitHub email to an email address that can recieve emails to and gotten rid of the old one, but MDN keeps trying to email my old account. I have tried revoking permission, for MDN to access my GitHub email, but it still tries to use my non-working email.

Due to my locale preference, Google search prefers Japanese page to other locales.

For example, for my query "HTMLElement", it returns
https://developer.mozilla.org/ja/docs/Web/API/HTMLElement
as the first result.

Then I switch the language on top-right link to "en-US", then this popup asks me if I want to view pages in that locale.

But after answering "Yes" to this, if I do the search again, and follow the link for "ja" locale - I expected MDN to redirect to en-US if available, but it doesn't work.

Is this working as expected?
if so, what the real expectation for the answer for the popup?

The link to Performance Tracking on page https://developer.mozilla.org/en-US/docs/Mozilla/Participating_in_the_Mozilla_project leads to graphs.mozilla.org which is either down or non-existent. If the site has moved, please update the link.

https://developer.mozilla.org/en-US/docs/Web/SVG/Tutorial

Hello! 😄
I'm extremely interested in the browser-compat-data project, and have enjoyed attempting to contribute to it. I'd love to be more involved and assist with reviewing, if that would be preferable.

This issue was observed on page https://developer.mozilla.org/en-US/docs/Mozilla/Participating_in_the_Mozilla_project on a Mozilla Developer Edition 66.0b14 (64-bit).

Below is what I see on the above page

I am not sure about the usage of tmui. Is this a valid html tag ?

To whom it may concern,

I've been contributing some pretty big updates to the browser-compat-data repository, as well as smaller updates, particularly relating to the schema and linters for the project. I'm really glad to be working with everyone on the repository, and being able to contribute my code to the project. And I want to do what I can to keep the project going in the right direction.

I'm big on maintaining consistent organization, as my existing contributions have probably shown, so that, and responding to incoming issues, would be my primary focus, with additional assistance wherever I'm needed. All of my own code will be contributed in the form of pull requests -- never directly to the repository's master branch -- and merged only when another peer has approved the changes.

I will gladly abide to the Code of Conduct, as well as the Commit Access Requirements. I also have 2-Factor Authentication set up on my GitHub account.

Thank you for reading through, and looking forward to working with everyone!
Vinyl

@hobinjk needs write access to the mdn/sprints repository, so that he can assign himself to sprint issues.

This repository should contain the Code of Conduct for this organization, so that we can link to it from the individual repositories (for example from a standardized README file, see #1).

I think that opening an issue against this repository would be a good open process to request privileges for MDN repositories. Other proposals?

As part of migrating the process for documentation issues from Bugzilla to Github, there needs to be a repo in Github to house the issues. Consensus from the content team is not to use an existing repo (i.e., mdn/sprints), to avoid confusion.

I am leaning in favor of "mdn/docs" for the name. Submitting an issue under that name implies to me "This is an issue with MDN docs." Like mdn/sprints, the new repo would for the foreseeable future contain primarily issues, and not files.

We can get history of a single page using $history appended to the entry's link - but is there a similar way to get a global history of all recent changed pages - say, I would like to see a list of all pages has been updated since f.ex. one week ago?

If not, is this something that is doable as it would be helpful when scraping since this enable us to just scrape pages that has actually been updated/created (since last scraping) instead of the entire site.

I have read, and agree to abide by, the Mozilla Commit Access Requirements.

Also, as of Firefox 52+, Full-Page Screenshots no longer work using F12 DevTools - Screenshot Button. Only captures what is viewable in window.

I've leaving the MDN team, so it is inappropriate for me to continue to be an organization owner. That would leave 3 owners, which could be a healthy number, but no one from the dev team. If you need another owner, I suggest @escattone (for seniority) and / or @peterbe (for experience with managing multiple Mozilla repos).

Some of my unfinished work may be relevant:

• I came up with a system for categorizing projects by their security demands in Roles and teams in the MDN organization. My next step was to add a "Tier 1", "Tier 2", and "Tier 3" tag to all the repos, but since I didn't, it is fuzzy which repos require stricter reviews. Org Owners also get Owner on all the repos, which is a consideration for replacing me.
• I wanted to add an "Emeritus Members" doc, to list people previously involved. It should have been fast, but I was hoping to get years of service in the doc too, so I procrastinated. If I'd done that, there would be a natural place to put my name, and a way to transition people from active to inactive status.
• I felt the Member list was too broad to justify moving https://github.com/mozilla/kuma into the MDN org, so I delayed that as well. The new dev team may decide it is time to move it in. I think the private repos should remain in the Mozilla org, to avoid converting the MDN org into a paying account.

@escattone would like write access to the mdn/interactive-examples repo, so that he can create branches on that repo. This will speed up the development cycle for updating the repository for working with the MozIT Jenkins instance (mdn/infra#41)

Create a new /mdn/sprints repo, for issues and documentation related to our use of Zenhub.

• Security: Tier 3
• Roles:
  • Admins: jswisher
  • Writers: MDN staff (can add key contributors later)

I think we'd like to encourage staff and contributors to prepare a new repository in their own accounts, and then request a transfer when they are up the standards. Something like:

• Create your repo, add the required files
• Open an issue to transfer in the repo
• A repo owner will ensure your project is appropriate and up to standards
• Add the requested repo owner to the project
• Transfer it in, update people and documentation

Please add the "Project Managers" team with Admin privileges (or at least Write) to the mdn/short-descriptions repo, to enable members of that team (i.e., me) to do ZenHub management tasks.

Given that many MDN repositories use ESLint, I believe that the MDN ESLint configuration should be standardised into a repository and npm package (like what I did with @exe‑boss/eslint‑config ).

This can then be included in .eslintrc as:

module.exports = {
	// Repository specific environment configuration
	env: {
		…
	},
	extends: '@mdn',
	// Repository specific globals
	globals: {
		…
	},
	// Override rules from `@mdn/eslint‑config` based on the repository’s specific needs.
	rules: {
		…
	},
};

If possible, I’d like to have collaborator access to the @mdn/eslint‑config repository to help create the initial version.

See also:

• https://eslint.org/docs/developer-guide/shareable-configs

Your required text does not appear to be correct

As of January 1 2019, Mozilla requires that all GitHub projects include this CODE_OF_CONDUCT.md file in the project root. The file has two parts:

1. Required Text - All text under the headings Community Participation Guidelines and How to Report, are required, and should not be altered.
2. Optional Text - The Project Specific Etiquette heading provides a space to speak more specifically about ways people can work effectively and inclusively together. Some examples of those can be found on the Firefox Debugger project, and Common Voice. (The optional part is commented out in the raw template file, and will not be visible until you modify and uncomment that part.)

If you have any questions about this file, or Code of Conduct policies and procedures, please reach out to [email protected].

(Message COC003)

I have created @ExE-Boss/mdn-packages which contains miscellaneous MDN packages, like @mdn/prettier-config or a shared lint script, like what I suggested in mdn/data#362.

needinfo?(@Elchi3)

While downloading files for roku channel creation (repository files ) my phone slipped from my hand, and a damn popup said I just blocked download of further files!!!!! WTH?!?!?Lol!!!! I've been all thru Chrome and Github settings and cannot find how to reverse this retarded mistake. Just learning how to code but I have nothing for that!!!! Jesús Christ.....I've tried backtracking and a couple other things but have a feeling the remedy lies in code. How do I reverse the block to repository downloading? Please tell me some knows?!?!?

Here it says: "(the viewport), usually wider than the screen"
https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/Viewport_meta_tag

On this page: "viewport... area in computer graphics that is currently being viewed."
https://developer.mozilla.org/en-US/docs/Glossary/viewport

These statements are mutually exclusive. If a viewport is wider than the screen than it can't only be the portion of the screen that's being viewed.

Also I'm tying to understand the width value of a viewport but it's not making sense. For the width setting of viewport is says "Defines the pixel width of the viewport, or allows the viewport to adapt to the device's screen width."
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta

But what does that actually mean? It's ambiguous. I don't know what they mean by "define" or what that definition actually does. I thought it could mean set the initial width of the viewport. So I tried setting it to 1 pixel and trying it on a mobile device screen. I was wrong because the page didn't change, showing many more than 1 pixel as the initial width

I want to help making, fixing or bugging the examples at interactive-examples repo

(Not sure where's the best place for this.)

Having repos full of examples is good, but we need to make sure we have links from MDN pages to the examples. For webextensions-examples, I thought about this, and ended up doing this:

• a JSON file at the root called examples.json
• a KumaScript macro, WebExtExamples, that uses the JSON to find examples that are relevant to the current page.

It's a terrible solution, because I have to generate the JSON manually (well, I have a script to generate it, but I have to push the new version manually). Even so, it works well enough to give me:

• a page listing all the examples: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Examples
• links to relevant examples from all my API reference pages: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/Tabs/query#Example_add-ons. There's obviously no way I'd be able to maintain these links for all 360-odd pages without a solution like this.

So it would be worth thinking about whether we should do something similar for the other repos, and hopefully implementing something less terrible, that parsed the examples on commits and updated the JSON file, say.

Recently there was a security vulnerability found in a NPM package that interactive examples and BoB indirectly depended on. The required quick action, including notifying users, contributors and forks of these projects.

We need to document the process that followed as it seemed to have been very effective. This will take away some of the guesswork should this scenario happen again in future.

Acceptance Criteria

• A document describing this process exists in mdn/mdn and has been reviewed by 1 knowledgeable stakeholder.

@jmswisher requested that @irenesmith needs to be added to one or more MDN repositories, so that she can be assigned sprint tasks. Which repositories does she need access to?

Many of the open web example repos use GitHub pages. We need to agree on a few guidelines:

• Always enable HTTPS.
• Make clear which branch is used for the GitHub pages (ideally we only use master imo).
• Use a standard layout for the examples? (if examples are embedded into MDN, then this makes no sense)

Create a file like contribute.dist.json that contains the common settings for contribute.json for our MDN sample code projects.

https://github.com/schalkneethling/bob

{
    "name": "bob",
    "description":
        "Builder of Bits aka The MDN Web Docs interactive examples, example builder",
    "repository": {
        "url": "https://github.com/mdn/bob",
        "license": "MPL2"
    },
    "participate": {
        "home": "https://github.com/mdn/bob",
        "docs": "https://github.com/mdn/bob",
        "irc": "irc://irc.mozilla.org/#mdndev",
        "irc-contacts": ["espressive", "jwhitlock", "rjohnson", "wbamberg"]
    },
    "bugs": {
        "list": "https://github.com/mdn/bob/issues",
        "report": "https://github.com/mdn/bob/issues/new"
    },
    "urls": {
        "prod": "https://github.com/mdn/bob"
    },
    "keywords": ["nodejs", "javascript"]
}

I’ve been working on my local fork of mdn/browser‑compat‑toolkit and would like to merge them into the upstream repository to get closer to resolving mdn/browser-compat-data#2354.

I have read and agree to abide by the Code of conduct and Mozilla’s Commit Access Requirements.

I also have 2FA enabled on my GitHub account.

Back when I was really, really, really bad at Git (instead of just dodgy like I am now), I specifically asked not to be given collaborator status for kumascript, just to avoid any incidents. This is now becoming more of a hindrance than a boon, and I would like to be given collaborator status. Not being able to do things like assign reviewers and actually formally do reviews is interfering with my work. Especially now that more of our work is done on Github than originally envisioned.

As a Mozilla employee of many years, I already have my committer agreement in place, and I agree to abide by the code of conduct and have 2-factor authentication enabled. I also promise not to draw on the walls with crayons or to track mud in all over the just-polished floors.

It would be good to come up with a standard CONTRIBUTING format for all of MDN's repositories. Tasks that I can think of:

• Collect format ideas
• Put a template into this repository.
• Roll out standardized CONTRIBUTING files to all of MDN's repos.

Inspiration:

• https://mozillascience.github.io/working-open-workshop/contributing/
• https://github.com/atom/atom/blob/master/CONTRIBUTING.md
• https://news.ycombinator.com/item?id=4828165
• https://github.com/mdn/webextensions-examples/blob/master/CONTRIBUTING.md