├── 2023 ├── 2023-11-13 │ ├── agenda.md │ └── minutes.md └── 2023-12-11 │ ├── agenda.md │ └── minutes.md ├── 2024 ├── 2024-09-25 │ ├── minutes.md │ └── agenda.md ├── 2024-05-29 │ ├── agenda.md │ └── minutes.md ├── 2024-10-23 │ ├── agenda.md │ └── minutes.md ├── 2024-08-21 │ ├── agenda.md │ └── minutes.md ├── 2024-07-23 │ ├── agenda.md │ └── minutes.md ├── 2024-02-26 │ ├── agenda.md │ └── minutes.md ├── 2024-04-29 │ ├── agenda.md │ └── minutes.md ├── 2024-06-24 │ ├── agenda.md │ └── minutes.md ├── 2024-03-27 │ ├── agenda.md │ └── minutes.md └── 2024-01-22 │ ├── agenda.md │ └── minutes.md ├── .gitignore ├── 2025-03-26 ├── minutes.md └── agenda.md ├── 2025-05-28 ├── minutes.md └── agenda.md ├── 2025-08-27 ├── minutes.md └── agenda.md ├── 2025-12-04 ├── minutes.md └── agenda.md ├── template [COPY] ├── minutes.md └── agenda.md ├── content meetings ├── template [COPY] │ ├── minutes.md │ └── agenda.md └── 2024-09-02 │ ├── minutes.md │ └── agenda.md ├── 2025-02-27 ├── minutes.md └── agenda.md ├── .markdownlint.jsonc ├── .github ├── ISSUE_TEMPLATE │ └── config.yml ├── PULL_REQUEST_TEMPLATE └── CODEOWNERS ├── CODE_OF_CONDUCT.md ├── .vscode ├── project-words.txt └── cspell.json ├── SECURITY.md ├── CONTRIBUTING.md ├── 2025-04-30 ├── agenda.md └── minutes.md ├── README.md └── LICENSE /.gitignore: -------------------------------------------------------------------------------- 1 | .DS_Store -------------------------------------------------------------------------------- /2025-03-26/minutes.md: -------------------------------------------------------------------------------- 1 | # Minutes from MDN community meeting - 26th March, 2025 2 | -------------------------------------------------------------------------------- /2025-05-28/minutes.md: -------------------------------------------------------------------------------- 1 | # Minutes from MDN community meeting - 28th May, 2025 2 | -------------------------------------------------------------------------------- /2025-08-27/minutes.md: -------------------------------------------------------------------------------- 1 | # Minutes from MDN community meeting - 27th August, 2025 2 | -------------------------------------------------------------------------------- /2025-12-04/minutes.md: -------------------------------------------------------------------------------- 1 | # Minutes from MDN community meeting - 4th December, 2025 2 | -------------------------------------------------------------------------------- /template [COPY]/minutes.md: -------------------------------------------------------------------------------- 1 | # Minutes from MDN community meeting [insert date here] 2 | -------------------------------------------------------------------------------- /content meetings/template [COPY]/minutes.md: -------------------------------------------------------------------------------- 1 | # Minutes from MDN community meeting [insert date here] 2 | -------------------------------------------------------------------------------- /2024/2024-09-25/minutes.md: -------------------------------------------------------------------------------- 1 | # Minutes from MDN community meeting 25th September, 2024 2 | 3 | Meeting notes coming soon! :) 4 | -------------------------------------------------------------------------------- /content meetings/2024-09-02/minutes.md: -------------------------------------------------------------------------------- 1 | # Minutes from MDN Content meeting - 2nd September, 2024 2 | 3 | Meeting notes coming soon :) 4 | -------------------------------------------------------------------------------- /2025-02-27/minutes.md: -------------------------------------------------------------------------------- 1 | # Minutes from MDN community meeting - 27th February, 2025 2 | 3 | Unfortunately, meeting minutes were not recorded for this meeting. Please refer to the [agenda](2025-02-27/agenda.md) to see what was discussed. 4 | -------------------------------------------------------------------------------- /.markdownlint.jsonc: -------------------------------------------------------------------------------- 1 | // This file defines our configuration for Markdownlint. See 2 | // https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md 3 | // for more details on each rule. 4 | 5 | { 6 | "default": true, 7 | "line-length": false, 8 | "first-line-h1": false, 9 | "MD033": false, 10 | "MD034": false 11 | } 12 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/config.yml: -------------------------------------------------------------------------------- 1 | blank_issues_enabled: false 2 | contact_links: 3 | - name: Content or feature request 4 | url: https://github.com/mdn/mdn/issues/new/choose 5 | about: Propose new content for MDN Web Docs or submit a feature request using this link. 6 | - name: MDN GitHub Discussions 7 | url: https://github.com/orgs/mdn/discussions 8 | about: Does your topic involve a lot of pages, or are you not sure how it can be split into actionable tasks? Consider starting a discussion first. 9 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Community Participation Guidelines 2 | 3 | This repository is governed by Mozilla's code of conduct and etiquette guidelines. 4 | For more details, please read the 5 | [Mozilla Community Participation Guidelines](https://www.mozilla.org/about/governance/policies/participation/). 6 | 7 | ## How to Report 8 | 9 | For more information on how to report violations of the Community Participation Guidelines, please read our [How to Report](https://www.mozilla.org/about/governance/policies/participation/reporting/) page. 10 | -------------------------------------------------------------------------------- /.vscode/project-words.txt: -------------------------------------------------------------------------------- 1 | # Project dictionary 2 | Alcalá 3 | Andi 4 | Anuja 5 | Ardle 6 | argl 7 | Augner 8 | Bhattacharya 9 | bsmth 10 | caugner 11 | Claas 12 | couci 13 | Curtean 14 | Dipika 15 | dipikabh 16 | dletorey 17 | Elchi 18 | Hamish 19 | i'gyu 20 | Kazotetsu 21 | Khanna 22 | Konstantina 23 | leomca 24 | Letorey 25 | ljharb 26 | Makeev 27 | nataliaschlebinger 28 | Onkar 29 | ossinsight 30 | pepelsbey 31 | pransh 32 | Pranshu 33 | Ruikar 34 | Rumyra 35 | Scholz 36 | Scrimba 37 | securecontext 38 | Sonal 39 | Sood 40 | teoli 41 | wbamberg 42 | Weyl 43 | Willee 44 | Yari 45 | -------------------------------------------------------------------------------- /.github/PULL_REQUEST_TEMPLATE: -------------------------------------------------------------------------------- 1 | 7 | 8 | **Description:** 9 | 10 | 11 | 12 | **Additional details:** 13 | 14 | 15 | 16 | -------------------------------------------------------------------------------- /.github/CODEOWNERS: -------------------------------------------------------------------------------- 1 | # ---------------------------------------------------------------------------- 2 | # CODEOWNERS 3 | # ---------------------------------------------------------------------------- 4 | # Order is important. The last matching pattern takes precedence. 5 | # See: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners 6 | # ---------------------------------------------------------------------------- 7 | 8 | * @mdn/content-team 9 | 10 | /.github/workflows/ @mdn/engineering 11 | /.github/CODEOWNERS @mdn/content-team @mdn/engineering 12 | /SECURITY.md @mdn/engineering 13 | -------------------------------------------------------------------------------- /.vscode/cspell.json: -------------------------------------------------------------------------------- 1 | { 2 | "$schema": "https://raw.githubusercontent.com/streetsidesoftware/cspell/main/cspell.schema.json", 3 | "version": "0.2", 4 | "language": "en-US", 5 | "languageId": "*", 6 | "dictionaries": [ 7 | "bash", 8 | "css", 9 | "cpp", 10 | "django", 11 | "filetypes", 12 | "fonts", 13 | "fullstack", 14 | "html", 15 | "latex", 16 | "lorem-ipsum", 17 | "markdown", 18 | "node", 19 | "npm", 20 | "Project dictionary", 21 | "python", 22 | "softwareTerms", 23 | "svelte", 24 | "typescript" 25 | ], 26 | "allowCompoundWords": true, 27 | "dictionaryDefinitions": [ 28 | { 29 | "name": "Project dictionary", 30 | "path": "./project-words.txt", 31 | "addWords": true 32 | } 33 | ] 34 | } 35 | -------------------------------------------------------------------------------- /2024/2024-05-29/agenda.md: -------------------------------------------------------------------------------- 1 | # Agenda for MDN Community meeting 29th May 2024 2 | 3 | **Join details:** See 'where' in [the calendar invite](https://calendar.google.com/calendar/u/0/embed?src=c_4656dd7c36825e2be115c0e7992191d550d16edcec37151eb6018581f654727b@group.calendar.google.com) for the call URL. 4 | 5 | ## Intro & overview of agenda 6 | 7 | - Rules: use the chat for questions or to request to speak so that we're talking in-turns. 8 | 9 | ## Team updates 10 | 11 | - A new community manager introduction (@pepelsbey) 12 | 13 | ## Contributor updates 14 | 15 | Project/work updates from contributors 16 | 17 | - [Curriculum](https://developer.mozilla.org/en-US/curriculum/) updates (@chrisdavidmills) 18 | 19 | ## Questions/Discussions 20 | 21 | Questions from folks & anything to discuss 22 | 23 | - [Automation of banner display](https://github.com/orgs/mdn/discussions/676) (@leon-win). 24 | -------------------------------------------------------------------------------- /template [COPY]/agenda.md: -------------------------------------------------------------------------------- 1 | # Agenda for MDN Community meeting [insert date] 2 | 3 | **Join details:** See 'where' in [the calendar invite](https://calendar.google.com/calendar/u/0/embed?src=c_4656dd7c36825e2be115c0e7992191d550d16edcec37151eb6018581f654727b@group.calendar.google.com) for the call URL. 4 | 5 | ## Intro & overview of agenda 6 | 7 | - Rules: use the chat for questions or to request to speak so that we're talking in-turns. 8 | 9 | ## Team updates 10 | 11 | Project updates from the MDN team 12 | 13 | ## Contributor updates 14 | 15 | Project/work updates from contributors 16 | 17 | - [example] Progress on my awesome project. See [link for more details](https://github.com/mdn/community-meetings) (@MyUsername) 18 | 19 | ## Questions/Discussions 20 | 21 | Questions from folks & anything to discuss 22 | 23 | - [example] Discuss my interesting topic. See [link for more details](https://github.com/mdn/community-meetings) (@MyUsername) 24 | -------------------------------------------------------------------------------- /content meetings/template [COPY]/agenda.md: -------------------------------------------------------------------------------- 1 | # Agenda for MDN Community meeting [insert date] 2 | 3 | **Join details:** See 'where' in [the calendar invite](https://calendar.google.com/calendar/u/0/embed?src=c_4656dd7c36825e2be115c0e7992191d550d16edcec37151eb6018581f654727b@group.calendar.google.com) for the call URL. 4 | 5 | ## Intro & overview of agenda 6 | 7 | - Rules: use the chat for questions or to request to speak so that we're talking in-turns. 8 | 9 | ## Team updates 10 | 11 | Project updates from the MDN team 12 | 13 | ## Contributor updates 14 | 15 | Project/work updates from contributors 16 | 17 | - [example] Progress on my awesome project. See [link for more details](https://github.com/mdn/community-meetings) (@MyUsername) 18 | 19 | ## Questions/Discussions 20 | 21 | Questions from folks & anything to discuss 22 | 23 | - [example] Discuss my interesting topic. See [link for more details](https://github.com/mdn/community-meetings) (@MyUsername) 24 | -------------------------------------------------------------------------------- /2024/2024-10-23/agenda.md: -------------------------------------------------------------------------------- 1 | # Agenda for MDN Community meeting - 23rd October, 2024 2 | 3 | **Join details:** See 'where' in [the calendar invite](https://calendar.google.com/calendar/u/0/embed?src=c_4656dd7c36825e2be115c0e7992191d550d16edcec37151eb6018581f654727b@group.calendar.google.com) for the call URL. 4 | 5 | ## Intro & overview of agenda 6 | 7 | - Rules: use the chat for questions or to request to speak so that we're talking in-turns. 8 | 9 | ## Team updates 10 | 11 | - (Pranshu) [Community Page is now LIVE!](https://developer.mozilla.org/en-US/community) 12 | - (Brian) Examples, what's next 13 | 14 | ## Contributor updates 15 | 16 | Project/work updates from contributors 17 | 18 | - [example] Progress on my awesome project. See [link for more details](https://github.com/mdn/community-meetings) (@MyUsername) 19 | 20 | ## Questions/Discussions 21 | 22 | Questions from folks & anything to discuss 23 | 24 | - [example] Discuss my interesting topic. See [link for more details](https://github.com/mdn/community-meetings) (@MyUsername) 25 | -------------------------------------------------------------------------------- /2025-02-27/agenda.md: -------------------------------------------------------------------------------- 1 | # Agenda for MDN Community meeting - 27th February, 2025 2 | 3 | **Join details:** See 'where' in [the calendar invite](https://calendar.google.com/calendar/u/0/embed?src=c_4656dd7c36825e2be115c0e7992191d550d16edcec37151eb6018581f654727b@group.calendar.google.com) for the call URL. 4 | 5 | ## Intro & overview of agenda 6 | 7 | - Rules: use the chat for questions or to request to speak so that we're talking in-turns. 8 | 9 | ## Team updates 10 | 11 | Project updates from the MDN team 12 | 13 | - (Leo) Interactive examples 14 | - (Brian) Content move 15 | 16 | ## Contributor updates 17 | 18 | Project/work updates from contributors 19 | 20 | - (Pranshu) mdn/awesome 21 | 22 | - [example] Progress on my awesome project. See [link for more details](https://github.com/mdn/community-meetings) (@MyUsername) 23 | 24 | ## Questions/Discussions 25 | 26 | Questions from folks & anything to discuss 27 | 28 | - [example] Discuss my interesting topic. See [link for more details](https://github.com/mdn/community-meetings) (@MyUsername) 29 | -------------------------------------------------------------------------------- /2023/2023-11-13/agenda.md: -------------------------------------------------------------------------------- 1 | # Agenda for MDN Community meeting 13th November 2023 2 | 3 | ## Intro & overview of agenda 4 | 5 | ## Updates 6 | 7 | Updates from the MDN team 8 | 9 | - This meeting (feedback & moving forward) 10 | - Discord 11 | - Labels on mdn/content 12 | - Discussions on mdn-community 13 | - [Engineering role](https://www.mozilla.org/en-US/careers/position/gh/5448569/) 14 | 15 | ### Projects 16 | 17 | - Triage work 18 | - Baseline 19 | - (Next time) Observatory 20 | 21 | ## Contributor updates 22 | 23 | Any project/work updates from contributors 24 | 25 | - [Automating BCD](https://github.com/openwebdocs/project/issues/168) & [Web platform features](https://github.com/openwebdocs/project/issues/169) 26 | 27 | ## Questions/Discussions 28 | 29 | Any questions from folks & anything to discuss 30 | 31 | - [Discussion about how we represent API security features in frontmatter](https://github.com/orgs/mdn/discussions/288) 32 | - [Reconsider the way we represent globals in Web/API](https://github.com/orgs/mdn/discussions/360) 33 | - PR review process 34 | -------------------------------------------------------------------------------- /2025-08-27/agenda.md: -------------------------------------------------------------------------------- 1 | # Agenda for MDN Community meeting - 27th August, 2025 2 | 3 | **Join details:** See 'where' in [the calendar invite](https://calendar.google.com/calendar/u/0/embed?src=c_4656dd7c36825e2be115c0e7992191d550d16edcec37151eb6018581f654727b@group.calendar.google.com) for the call URL. 4 | 5 | ## Intro & overview of agenda 6 | 7 | - Rules: use the chat for questions or to request to speak so that we're talking in turns. 8 | 9 | ## Team updates 10 | 11 | Project updates from the MDN team 12 | 13 | - MDN 20th Birthday 14 | - New Frontend is LIVE 15 | 16 | ## Contributor updates 17 | 18 | Project/work updates from contributors 19 | 20 | - [example] Progress on my awesome project. See [link for more details](https://github.com/mdn/community-meetings) (@MyUsername) 21 | 22 | ## Questions/Discussions 23 | 24 | Questions from folks & anything to discuss 25 | 26 | - (@YourUsername) I would like to discuss . See <[add your link](url)> for more details. 27 | - (@yashrajbharti) **Temporal API**: status in Firefox (current support), expected path to support, and any blockers in the way. 28 | -------------------------------------------------------------------------------- /2024/2024-08-21/agenda.md: -------------------------------------------------------------------------------- 1 | # Agenda for MDN Community meeting - 21st August, 2024 2 | 3 | **Join details:** See 'where' in [the calendar invite](https://calendar.google.com/calendar/u/0/embed?src=c_4656dd7c36825e2be115c0e7992191d550d16edcec37151eb6018581f654727b@group.calendar.google.com) for the call URL. 4 | 5 | ## Intro & overview of agenda 6 | 7 | - Rules: use the chat for questions or to request to speak so that we're talking in-turns. 8 | 9 | ## Team updates 10 | 11 | Project updates from the MDN team 12 | 13 | - Introducing Content Meeting starting September (@pransh15) 14 | - Call for Contributors from friends at Common Voice (@jessicarose) 15 | - We are revamping the community page! (@pransh15) 16 | 17 | ## Contributor updates 18 | 19 | Project/work updates from contributors 20 | 21 | - [example] Progress on my awesome project. See [link for more details](https://github.com/mdn/community-meetings) (@MyUsername) 22 | 23 | ## Questions/Discussions 24 | 25 | Questions from folks & anything to discuss 26 | 27 | - [example] Discuss my interesting topic. See [link for more details](https://github.com/mdn/community-meetings) (@MyUsername) 28 | -------------------------------------------------------------------------------- /2024/2024-09-25/agenda.md: -------------------------------------------------------------------------------- 1 | # Agenda for MDN Community meeting - 25th September, 2024 2 | 3 | **Join details:** See 'where' in [the calendar invite](https://calendar.google.com/calendar/u/0/embed?src=c_4656dd7c36825e2be115c0e7992191d550d16edcec37151eb6018581f654727b@group.calendar.google.com) for the call URL. 4 | 5 | ## Intro & overview of agenda 6 | 7 | - Rules: use the chat for questions or to request to speak so that we're talking in-turns. 8 | 9 | ## Team updates 10 | 11 | Project updates from the MDN team 12 | 13 | - (Claas) German MDN preview 14 | 15 | ## Contributor updates 16 | 17 | Project/work updates from contributors 18 | 19 | - [example] Progress on my awesome project. See [link for more details](https://github.com/mdn/community-meetings) (@MyUsername) 20 | 21 | ## Questions/Discussions 22 | 23 | - [content] Should we lint old color syntax? The syntax with comma such as `rgb(100, 100, 100)` and `rgba(100, 100, 100, 0.5)`. There will be scope for adding exceptions so it won't be that strict. (@onkar) 24 | - [example] Discuss my interesting topic. See [link for more details](https://github.com/mdn/community-meetings) (@MyUsername) 25 | -------------------------------------------------------------------------------- /content meetings/2024-09-02/agenda.md: -------------------------------------------------------------------------------- 1 | # Agenda for MDN Content meeting - 2nd September, 2024 2 | 3 | **Join details:** See 'where' in [the calendar invite](https://calendar.google.com/calendar/u/0/embed?src=c_4656dd7c36825e2be115c0e7992191d550d16edcec37151eb6018581f654727b@group.calendar.google.com) for the call URL. 4 | 5 | ## Intro & overview of agenda 6 | 7 | - Rules: use the chat for questions or to request to speak so that we're talking in-turns. 8 | 9 | ## Shout outs to members of the community 10 | 11 | - [example] Thank you @Myusername for amazing work on [this PR](https://github.com/mdn/community-meetings) 12 | 13 | ## Main discussion item 14 | 15 | Discussion items for the call 16 | 17 | ## Speaking updates, other discussions/questions 18 | 19 | Questions from folks & anything to discuss 20 | 21 | - [example] Discussing this example problem. Check [link for more details](https://github.com/mdn/community-meetings) (@MyUsername) 22 | 23 | ## Read only updates & call for help / PR reviews 24 | 25 | - [example] Please check this PR, and share comments. Check [link for more details](https://github.com/mdn/community-meetings) (@MyUsername) 26 | 27 | ## Action items 28 | 29 | [] [example] Review this PR (@Myusername) 30 | -------------------------------------------------------------------------------- /2025-03-26/agenda.md: -------------------------------------------------------------------------------- 1 | # Agenda for MDN Community meeting - 26th March, 2025 2 | 3 | **Join details:** See 'where' in [the calendar invite](https://calendar.google.com/calendar/u/0/embed?src=c_4656dd7c36825e2be115c0e7992191d550d16edcec37151eb6018581f654727b@group.calendar.google.com) for the call URL. 4 | 5 | ## Intro & overview of agenda 6 | 7 | - Rules: use the chat for questions or to request to speak so that we're talking in-turns. 8 | 9 | ## Team updates 10 | 11 | Project updates from the MDN team 12 | 13 | ## Contributor updates 14 | 15 | Project/work updates from contributors 16 | 17 | - [example] Progress on my awesome project. See [link for more details](https://github.com/mdn/community-meetings) (@MyUsername) 18 | 19 | ## Questions/Discussions 20 | 21 | Questions from folks & anything to discuss 22 | 23 | - [example] Discuss my interesting topic. See [link for more details](https://github.com/mdn/community-meetings) (@MyUsername) 24 | - [content] How to keep contributing? General tips, resources to share in chat, fostering curiosity about learning from W3C and WICG, engaging with the community, and checking "help wanted" issues. ([@yashrajbharti](https://github.com/yashrajbharti)) 25 | - Possible intern opportunities for contributors (@CBID2) 26 | -------------------------------------------------------------------------------- /2025-12-04/agenda.md: -------------------------------------------------------------------------------- 1 | # Agenda for MDN Community meeting - 4th December, 2025 2 | 3 | **Joining details:** See 'where' in [the calendar invite](https://calendar.google.com/calendar/u/0/embed?src=c_4656dd7c36825e2be115c0e7992191d550d16edcec37151eb6018581f654727b@group.calendar.google.com) for the call URL. 4 | 5 | ## Intro & overview of agenda 6 | 7 | - Rules: use the chat for questions or to request to speak so that we're talking in turns. 8 | 9 | ## Team updates 10 | 11 | Project updates from the MDN team 12 | 13 | - (Pranshu) Kickoff - Last community call of 2025! 🎉 14 | - (Pranshu) [Contributor Spotlight - Shrinivass Arunachalam Balasubramanian](https://developer.mozilla.org/en-US/community/spotlight/shrinivass-arunachalam-balasubramanian) 15 | - (Dipika) CSS Reorg completed 16 | - (Pranshu) MDN at MozFest 17 | - (Vadim) MDN at TPAC 18 | - (Ruth) MDN workweek with DevTools and WebDriver BiDi 19 | 20 | ## Contributor updates 21 | 22 | Project/work updates from contributors 23 | 24 | - [example] Progress on my awesome project. See [link for more details](https://github.com/mdn/community-meetings) (@MyUsername) 25 | 26 | ## Questions/Discussions 27 | 28 | Questions from folks & anything to discuss 29 | 30 | - (@YourUsername) I would like to discuss . See <[add your link](url)> for more details. 31 | -------------------------------------------------------------------------------- /2024/2024-07-23/agenda.md: -------------------------------------------------------------------------------- 1 | # Agenda for MDN Community meeting - 23rd July 2024 2 | 3 | **Join details:** See 'where' in [the calendar invite](https://calendar.google.com/calendar/u/0/embed?src=c_4656dd7c36825e2be115c0e7992191d550d16edcec37151eb6018581f654727b@group.calendar.google.com) for the call URL. 4 | 5 | ## Intro & overview of agenda 6 | 7 | - Here's what will be discussed: 8 | - Content & Community Updates 9 | - Office Hours for any Questions([add your questions here](#questions-and-discussions)) 10 | - Rules: use the chat for questions or to request to speak so that we're talking in-turns. 11 | 12 | ## Team updates 13 | Project updates from the MDN team 14 | 15 | - MDN Birthday! 16 | - Updates from GitHub Work Week 17 | - Scrimba Curriculum Feedback 18 | - MDN HTTP Observatory Feedback 19 | - Reviewer Meeting 20 | - Localization Meeting 21 | - New callouts system (@pepelsbey) 22 | 23 | ## Contributor updates 24 | 25 | Project/work updates from contributors 26 | 27 | - [example] Progress on my awesome project. See [link for more details](https://github.com/mdn/community-meetings) (@MyUsername) 28 | 29 | ## Questions and Discussions 30 | 31 | Questions from folks & anything to discuss 32 | 33 | - [example] Discuss my interesting topic. See [link for more details](https://github.com/mdn/community-meetings) (@MyUsername) 34 | -------------------------------------------------------------------------------- /SECURITY.md: -------------------------------------------------------------------------------- 1 | # Security Policy 2 | 3 | ## Overview 4 | 5 | This policy applies to MDN's website (`developer.mozilla.org`), backend services, and GitHub repositories in the [`mdn`](https://github.com/mdn) organization. Issues affecting other Mozilla products or services should be reported through the [Mozilla Security Bug Bounty Program](https://www.mozilla.org/en-US/security/bug-bounty/). 6 | 7 | For non-security issues, please file a [content bug](https://github.com/mdn/content/issues/new/choose), a [website bug](https://github.com/mdn/fred/issues/new/choose) or a [content/feature suggestion](https://github.com/mdn/mdn/issues/new/choose). 8 | 9 | ## Reporting a Vulnerability 10 | 11 | If you discover a potential security issue, please report it privately via . 12 | 13 | If you prefer not to use HackerOne, you can report it via . 14 | 15 | ## Bounty Program 16 | 17 | Vulnerabilities in MDN may qualify for Mozilla's Bug Bounty Program. Eligibility and reward amounts are described on . 18 | 19 | Please use the above channels even if you are not interested in a bounty reward. 20 | 21 | ## Responsible Disclosure 22 | 23 | Please do not publicly disclose details until Mozilla's security team and the MDN engineering team have verified and fixed the issue. 24 | 25 | We appreciate your efforts to keep MDN and its users safe. 26 | -------------------------------------------------------------------------------- /2024/2024-02-26/agenda.md: -------------------------------------------------------------------------------- 1 | # Agenda for MDN Community meeting 26th February '24 2 | 3 | **Join details:** See 'where' in [the calendar invite](https://calendar.google.com/calendar/u/0/embed?src=c_4656dd7c36825e2be115c0e7992191d550d16edcec37151eb6018581f654727b@group.calendar.google.com&ctz=Europe/Berlin) for the call URL. 4 | 5 | ## Intro & overview of agenda 6 | 7 | - Some rules, use the chat. Larger topics can be carried over to next time. 8 | - We have an Open Source Community Manager position open please share it with your networks - thank you! 9 | - New [blog post by Dipika](https://developer.mozilla.org/en-US/blog/) about technical writing 10 | - Content workshop happening in March to assess Learn area and related docs given curriculum 11 | 12 | ## Team updates 13 | 14 | Project updates from the MDN team 15 | 16 | - MDN Curriculum launch (Konstantina & Chris M) 17 | - (Brian) Some info on contributing to MDN, where to look for docs, help, how to chat with us. 18 | 19 | ## Contributor updates 20 | 21 | Project/work updates from contributors 22 | 23 | - [example] Progress on my awesome project. See [link for more details](https://github.com/mdn/community-meetings) (@MyUsername) 24 | 25 | ## Questions/Discussions 26 | 27 | Questions from folks & anything to discuss 28 | 29 | - [example] Discuss my interesting topic. See [link for more details](https://github.com/mdn/community-meetings) (@MyUsername) 30 | -------------------------------------------------------------------------------- /2024/2024-04-29/agenda.md: -------------------------------------------------------------------------------- 1 | # Agenda for MDN Community meeting 29th April 2024 2 | 3 | **Join details:** See 'where' in [the calendar invite](https://calendar.google.com/calendar/u/0/embed?src=c_4656dd7c36825e2be115c0e7992191d550d16edcec37151eb6018581f654727b@group.calendar.google.com) for the call URL. 4 | 5 | ## Intro & overview of agenda 6 | 7 | - Rules: use the chat for questions or to request to speak so that we're talking in-turns. 8 | 9 | ## Team updates 10 | 11 | Project updates from the MDN team 12 | 13 | - MDN community call: how it is going and what could be improved @Rumyra 14 | - Update on community manager @Rumyra 15 | - Update on content team projects @Rumyra 16 | - Content workshop summary 17 | - Sentiment data from article footer 18 | - Reference indicators & banners 19 | - Spam coming from zombie GitHub actions @pepelsbey 20 | 21 | ## Contributor updates 22 | 23 | Project/work updates from contributors 24 | 25 | - [example] Progress on my awesome project. See [link for more details](https://github.com/mdn/community-meetings) (@MyUsername) 26 | 27 | ## Questions/Discussions 28 | 29 | Questions from folks & anything to discuss 30 | 31 | - Two discussions about part of MDN not accessible from the interface (@OnkarRuikar via @teoli2003): 32 | - [Writing guidelines section is living on an island](https://github.com/orgs/mdn/discussions/661) 33 | - [Glossary section is not reachable directly from anywhere](https://github.com/orgs/mdn/discussions/662) 34 | -------------------------------------------------------------------------------- /2024/2024-06-24/agenda.md: -------------------------------------------------------------------------------- 1 | # Agenda for MDN Community meeting 24th June, 2024 2 | 3 | **Join details:** See 'where' in [the calendar invite](https://calendar.google.com/calendar/u/0/embed?src=c_4656dd7c36825e2be115c0e7992191d550d16edcec37151eb6018581f654727b@group.calendar.google.com) for the call URL. 4 | 5 | ## Intro & overview of agenda 6 | 7 | - Here's what will be discussed: 8 | - Content & Community Updates 9 | - Office Hours for any Questions ([add your questions here](#questions-and-discussions)) 10 | - Rules: use the chat for questions or to request to speak so that we're talking in-turns. 11 | 12 | ## Team updates 13 | 14 | Project updates from the MDN team 15 | 16 | - (Ruth/Pranshu) These meetings moving forward 17 | - (Ruth) Content workshop update 18 | - (Ruth) GitHub week (8th July) 19 | - (Claas) German locale project 20 | 21 | ## Contributor updates 22 | 23 | Project/work updates from contributors 24 | 25 | - [example] Progress on my awesome project. See [link for more details](https://github.com/mdn/community-meetings) (@MyUsername) 26 | 27 | ## Questions and Discussions 28 | 29 | Questions from folks & anything to discuss 30 | 31 | - (Ruth) External examples 32 | - (Ruth) Is there an objective around closing issues? 33 | - (Ruth) Inline icons [discussion](https://github.com/orgs/mdn/discussions/654#discussioncomment-9746229) 34 | - [example] Discuss my interesting topic. See [link for more details](https://github.com/mdn/community-meetings) (@MyUsername) 35 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contribution guide 2 | 3 | Thanks for your interest in taking part in MDN community meetings. 4 | This document provides some tips for getting your topics added to the agenda and discussed during calls. 5 | 6 | ## Adding to the agenda 7 | 8 | There are folders for each community call in the format `YY-MM-DD`. 9 | If you want to add something to the agenda, you can open a pull request that suggests to add your item to a future call: 10 | 11 | ```plain 12 | ├── 24-01-22 13 | │   ├── agenda.md <-- Add your topic to `agenda.md` (e.g., January 22nd 2024) 14 | │   └── minutes.md 15 | ... 16 | ``` 17 | 18 | You can open a pull request on GitHub by navigating to the `YY-MM-dd/agenda.md` document, and clicking the edit icon. 19 | For more information, see the [GitHub documentation for editing files](https://docs.github.com/en/repositories/working-with-files/managing-files/editing-files). 20 | 21 | Make sure you use the following format when you're adding your topic: 22 | 23 | ```markdown 24 | - Discuss my awesome topic. See [link for more details](https://github.com/mdn/community-meetings/pulls) (@MyUsername) 25 | ``` 26 | 27 | Your pull request should have links to other information in the description field, if necessary. 28 | There are hints in the pull request template that will help guide you on your submission! 29 | 30 | ## Get in touch 31 | 32 | If you get stuck, you can reach out to us in one of our [communication channels](https://developer.mozilla.org/en-US/docs/MDN/Community/Communication_channels). 33 | -------------------------------------------------------------------------------- /2025-05-28/agenda.md: -------------------------------------------------------------------------------- 1 | # Agenda for MDN Community meeting - 28th May, 2025 2 | 3 | **Join details:** See 'where' in [the calendar invite](https://calendar.google.com/calendar/u/0/embed?src=c_4656dd7c36825e2be115c0e7992191d550d16edcec37151eb6018581f654727b@group.calendar.google.com) for the call URL. 4 | 5 | ## Intro & overview of agenda 6 | 7 | - Rules: use the chat for questions or to request to speak so that we're talking in turns. 8 | 9 | ## Team updates 10 | 11 | Project updates from the MDN team 12 | 13 | - (@bsmth) Some code style modernization changes landing. Good opportunities to create some PRs. I'll be putting them in our [issue board](https://github.com/orgs/mdn/projects/25). 14 | 15 | ## Contributor updates 16 | 17 | Project/work updates from contributors 18 | 19 | - [example] Progress on my awesome project. See [link for more details](https://github.com/mdn/community-meetings) (@MyUsername) 20 | 21 | ## Questions/Discussions 22 | 23 | Questions from folks & anything to discuss 24 | 25 | - (@YourUsername) I would like to discuss . See <[add your link](url)> for more details. 26 | 27 | ## CSS in 2025: What's new? 28 | 29 | Talk and Demo by Yash Raj Bharti, UX Engineer at Mercor. 30 | 31 | ### Agenda: 32 | 33 | - What's new in CSS? 34 | - @functions 35 | - If else 36 | - View transitions 37 | - Scroll-driven animations 38 | - @property 39 | - The new attr() 40 | - and more.. 41 | 42 | Questions for the Facilitator 43 | 44 | - (@YourUsername) Can you tell me more about ? See <[add your link](url)> for more details. 45 | -------------------------------------------------------------------------------- /2025-04-30/agenda.md: -------------------------------------------------------------------------------- 1 | # Agenda for MDN Community meeting - 30th April, 2025 2 | 3 | **Join details:** See 'where' in [the calendar invite](https://calendar.google.com/calendar/u/0/embed?src=c_4656dd7c36825e2be115c0e7992191d550d16edcec37151eb6018581f654727b@group.calendar.google.com) for the call URL. 4 | 5 | ## Intro & overview of agenda 6 | 7 | - Rules: use the chat for questions or to request to speak so that we're talking in turns. 8 | 9 | ## Team updates 10 | 11 | Project updates from the MDN team 12 | 13 | - Changes to the Course Partner links 14 | - Mozilla Festival 2025 CFP is live 15 | 16 | ## Contributor updates 17 | 18 | Project/work updates from contributors 19 | 20 | - [example] Progress on my awesome project. See [link for more details](https://github.com/mdn/community-meetings) (@MyUsername) 21 | 22 | ## Questions/Discussions 23 | 24 | Questions from folks & anything to discuss 25 | 26 | - (@YourUsername) I would like to discuss . See <[add your link](url)> for more details. 27 | 28 | ## Technical writing workshop 29 | 30 | Workshop by Pranit Brahmbhatt, Technical Content Developer at Dell. 31 | 32 | ### Agenda: 33 | 1) Introduction and welcome 34 | 2) What is Technical Writing? 35 | 3) Why Technical Writing Matters? 36 | 4) Frameworks for Technical Writing 37 | - Common Structures 38 | - Diátaxis Framework 39 | - Docs-as-Code 40 | 5) Best Practices and Key Tips 41 | 6) How to Get Started 42 | 7) Resources and Communities 43 | 8) Q&A 44 | 45 | Questions for the Facilitator 46 | 47 | - (@YourUsername) Can you tell me more about ? See <[add your link](url)> for more details. 48 | -------------------------------------------------------------------------------- /2024/2024-03-27/agenda.md: -------------------------------------------------------------------------------- 1 | # Agenda for MDN Community meeting 27th March '24 2 | 3 | **Join details:** See 'where' in [the calendar invite](https://calendar.google.com/calendar/u/0/embed?src=c_4656dd7c36825e2be115c0e7992191d550d16edcec37151eb6018581f654727b@group.calendar.google.com) for the call URL. 4 | 5 | ## Intro & overview of agenda 6 | 7 | - Rules: Please use the chat for questions or if you wish to speak, so that we can ensure everyone has a chance to talk. 8 | 9 | ## Team updates 10 | 11 | Project updates from the MDN team 12 | 13 | - Footer updates with feedback mechanism 14 | - Community Participation Guidelines (CPG). What the CPG is and where to find resources, and what's involved when incidents happen. 15 | - Using Discord and Matrix 16 | 17 | ## Contributor updates 18 | 19 | Project/work updates from contributors 20 | 21 | - [example] Progress on my awesome project. See [link for more details](https://github.com/mdn/community-meetings) (@MyUsername) 22 | 23 | ## Questions/Discussions 24 | 25 | Questions from folks & anything to discuss 26 | 27 | - [How to use inline status macros?](https://github.com/orgs/mdn/discussions/654) (@onkarruikar) 28 | Need to conclude the discussion/vote so that the synchronization automation can continue. 29 | - Should secure context and status macros have the same strategy? At the moment we've decided on a [diffrent strategy for secure context macros](https://github.com/orgs/mdn/discussions/482#discussioncomment-7825014). It hasn't been implemented in entire content so there is still time to change it to match the status macro strategy. 30 | - [Indicators & banners](https://docs.google.com/document/d/1aNnhhLuCMlG0G5r3p42eAyuy4JWJfT41S2a4XnqznA4/edit): Synchronous discussion (is there a discussion on https://github.com/orgs/mdn/discussions/). 31 | - [Writing guidelines and Glossary sections are living on islands](https://github.com/orgs/mdn/discussions/661). These sections need some visiblity to be recognized. 32 | -------------------------------------------------------------------------------- /2024/2024-01-22/agenda.md: -------------------------------------------------------------------------------- 1 | # Agenda for MDN Community meeting 22nd January 2024 2 | 3 | ## Intro & overview of agenda 4 | 5 | ## Team updates 6 | 7 | Any project updates from the MDN team 8 | 9 | - Firefox [experimental features](https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Experimental_features) page workflow (@pepelsbey) 10 | - Observatory 11 | - Yari architecture & v2.0 12 | - PR "size" labels in Content 13 | - Chat with Chris M about some pain points 14 | 15 | ## Contributor updates 16 | 17 | Any project/work updates from contributors 18 | 19 | - [Community help needed] Documenting interoperable APIs. Let's document all `HTML*Element.*` APIs! (@teoli2003) 20 | - [Instructions](https://github.com/orgs/mdn/discussions/476) & [Task list](https://docs.google.com/spreadsheets/d/1lvITVZJM8dx8s_Kee5UNI1hDfPNF0gXQwjPop5xIF5E/edit#gid=369545647) 21 | - [Community help needed] Document [missing JavaScript errors](https://github.com/mdn/mdn/issues/505) (@nataliaschlebinger) 22 | 23 | ## Questions/Discussions 24 | 25 | Any questions from folks & anything to discuss 26 | 27 | **Carried over:** 28 | 29 | - Standards position in docs (@Rumyra) 30 | - Consensus secure context usage: [Where and how to use `{{securecontext_inline}}`](https://github.com/orgs/mdn/discussions/482#discussioncomment-7825014) (@teoli2003) 31 | - The first APIs that need an "enrollment" before their use landed in ([Shared Storage API](https://developer.mozilla.org/en-US/docs/Web/API/Shared_Storage_API)) How to display this information on the relevant pages? A banner for secure contexts? (@teoli2003) 32 | 33 | **Added in January:** 34 | 35 | - [Using GFM-standard syntax for notes & co](https://github.com/mdn/yari/pull/10168) (like `[!Notes]`) (@teoli2003) 36 | - [Accepting more sources for polyfills](https://github.com/orgs/mdn/discussions/475#discussion-6000833) (@ljharb / @teoli2003) 37 | - How to get reviews on Yari PRs? Many sit idle for months (@teoli2003) 38 | -------------------------------------------------------------------------------- /2025-04-30/minutes.md: -------------------------------------------------------------------------------- 1 | # Minutes from MDN community meeting - 30th April, 2025 2 | 3 | Host: Pranshu 4 | 5 | Pranshu: Welcome to the April community call! For those who are here for the workshop and want it to be recorded. I would like to let you know that the workshop will be recorded so you can come back and view the [video](https://youtu.be/WLJiNbfnPPs?si=YfPrAEUuNFq3shdP) to follow the workshop. 6 | 7 | Let's move over to the call. 8 | 9 | ## (Pranshu) Changes to the Course Partner links 10 | 11 | Pranshu: We are updating some links within the Learn area and adding some course partner links. Nothing changes in there specifically, just adding more light to links to Scrimba and ensuring that you know if the link is a course partner link or not. 12 | 13 | Pranshu: This is not a huge change, but we wanted to let everyone know of what's coming and how we are changing stuff which you would notice while learning on MDN. 14 | 15 | Pranshu: We are open for feedback on Discord, GitHub Discussions, and let us know what you think. 16 | 17 | ## (Pranshu) Mozilla Festival 2025 CFP is live 18 | 19 | Pranshu: [Mozilla Festival](https://www.mozillafestival.org/), if you don't know, is a place where passionate individuals unite to build a better internet. Whether you create art, code, program or scroll in support of a safer internet—you’re in the right place. A lot of cool stuff happens there. 20 | 21 | Pranshu: As someone who has faciliated, volunteered and wrangled at the Mozilla Festival, I highly recommend attending the conference. Or, better yet, the CFP is open, so you can [apply to speak](https://www.mozillafestival.org/en/proposals/) at the Mozilla Festival 2025. 22 | 23 | Pranshu: It's happening from 7-9 November in Barcelona, and I'm attending! Even if you're speaking, thinking of speaking, or attending, come meet me. If you have any questions, feel free to let me know on [Discord](https://mdn.dev/discord). 24 | 25 | If you would like to follow the workshop happened ahead, you can checkout the [video on YouTube](https://youtu.be/WLJiNbfnPPs?si=YfPrAEUuNFq3shdP). 26 | 27 | Pranshu: Thank you, everyone! See you next month! 28 | -------------------------------------------------------------------------------- /2023/2023-12-11/agenda.md: -------------------------------------------------------------------------------- 1 | # Agenda for MDN Community meeting 11th December 2023 2 | 3 | ## Intro & overview of agenda 4 | 5 | - Welcome 6 | - Notes about time off over the holiday period 7 | - Opensource etiquette reminder for everyone to [be respectful and kind with contributors as well as peers](https://developer.mozilla.org/en-US/docs/MDN/Community/Open_source_etiquette#be_polite_be_kind_avoid_incendiary_or_offensive_language) 8 | - [A recent study of comments of Wikipedia leads to reduce activity](https://academic.oup.com/pnasnexus/article/2/12/pgad385/7457939) 9 | 10 | ## Team updates 11 | 12 | Any project updates from the MDN team 13 | 14 | - Curriculum work 15 | - ~Observatory~ (moved to next month) 16 | - Next steps for Baseline 17 | 18 | ## Contributor updates 19 | 20 | Any project/work updates from contributors 21 | 22 | - Fighting "Flaws": what we did this year and next steps. 23 | - BCD 24 | 25 | ## Questions/Discussions 26 | 27 | Any questions from folks & anything to discuss 28 | 29 | - Content architecture workshop (new year) 30 | - Issues related to "Formal Syntax" section 31 | - Capturing updates to formal syntax (webRef updates not reflected in MDN prose) 32 | - Discussion thread: [What's the "current version" of a spec, for CSS reference docs?](https://github.com/orgs/mdn/discussions/442) 33 | - We are closing new mdn/content GitHub issues related to formal syntax because this is a bigger issue 34 | - Or should we hide the entire "Formal Syntax" section till we are able to provide correct and latest syntax info? 35 | - Would be nice to reach a consensus on this discussion: [Removal of redundant Markdown language headers](https://github.com/orgs/mdn/discussions/426) 36 | - Pros/Cons for removing headings in prose 37 | - Workarounds/solutions for still being able to refer to specific example prose if headings in prose are removed 38 | 39 | ### Moved to next month 40 | 41 | - The first APIs that need an "enrollment" before their use landed this week ([Shared Storage API](https://developer.mozilla.org/en-US/docs/Web/API/Shared_Storage_API)) How to display this information on the relevent pages? A banner like for secure contexts? 42 | - Standards postion in docs https://github.com/orgs/mdn/discussions/463 43 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # MDN community meetings 2 | 3 | This repository is for agendas and minutes from regular MDN community meetings. 4 | 5 | Each meeting has its own folder marked with the date of the meeting. 6 | If you want to add to the agenda reach out to us on [Discord](https://developer.mozilla.org/discord). 7 | 8 | There is a public calendar if you would like to subscribe to these events: 9 | 10 | - [Web](https://calendar.google.com/calendar/embed?src=c_4656dd7c36825e2be115c0e7992191d550d16edcec37151eb6018581f654727b%40group.calendar.google.com&ctz=Europe%2FLondon) 11 | - [iCal](https://calendar.google.com/calendar/ical/c_4656dd7c36825e2be115c0e7992191d550d16edcec37151eb6018581f654727b%40group.calendar.google.com/public/basic.ics) 12 | 13 | ## Upcoming meetings 14 | 15 | - 4 December 2025: ([Meeting Agenda](2025-12-04/agenda.md)) on the [MDN Discord](https://developer.mozilla.org/discord) 16 | - Editorial Meeting: 24th November 2025 17 | 18 | ## Previous meetings 19 | 20 | - [27 August 2025](2025-08-27) 21 | - ([Agenda](2025-08-27/agenda.md)) 22 | - ([Minutes](2025-08-27/minutes.md)) 23 | - [28 May 2025](2025-05-28) 24 | - ([Agenda](2025-05-28/agenda.md)) 25 | - ([Minutes](2025-05-28/minutes.md)) 26 | - [30 April 2025](2025-04-30) 27 | - ([Agenda](2025-04-30/agenda.md)) 28 | - ([Minutes](2025-04-30/minutes.md)) 29 | - [26 March 2025](2025-03-26) 30 | - ([Agenda](2025-03-26/agenda.md)) 31 | - ([Minutes](2025-03-26/minutes.md)) 32 | - [27 February 2025](2025-02-27) 33 | - ([Agenda](2025-02-27/agenda.md)) 34 | - ([Minutes](2025-02-27/minutes.md)) 35 | 36 |
37 | Meetings in 2024 38 | 39 | - [23 October 2024](2024-10-23) 40 | - ([Agenda](2024-10-23/agenda.md)) 41 | - ([Minutes](2024-10-23/minutes.md)) 42 | - [25 September 2024](2024/2024-09-25) 43 | - ([Agenda](2024/2024-09-25/agenda.md)) 44 | - ([Minutes](2024/2024-09-25/minutes.md)) 45 | - [21 August 2024](2024/2024-08-21) 46 | - ([Agenda](2024/2024-08-21/agenda.md)) 47 | - ([Minutes](2024/2024-08-21/minutes.md)) 48 | - [23 July 2024](2024/2024-07-23) 49 | - ([Agenda](2024/2024-07-23/agenda.md)) 50 | - ([Minutes](2024/2024-07-23/minutes.md)) 51 | - [24 June 2024](2024/2024-06-24) 52 | - ([Agenda](2024/2024-06-24/agenda.md)) 53 | - ([Minutes](2024/2024-06-24/minutes.md)) 54 | - [29th May 2024](2024/2024-05-29) 55 | - ([Agenda](2024/2024-05-29/agenda.md)) 56 | - ([Minutes](2024/2024-05-29/minutes.md)) 57 | - [29th April 2024](2024-04-29) 58 | - ([Agenda](2024-04-29/agenda.md)) 59 | - ([Minutes](2024-04-29/minutes.md)) 60 | - [27th March 2024](2024-03-27) 61 | - ([Agenda](2024-03-27/agenda.md)) 62 | - ([Minutes](2024-03-27/minutes.md)) 63 | - [26th February 2024](2024-02-26) 64 | - ([Agenda](2024-02-26/agenda.md)) 65 | - ([Minutes](2024-02-26/minutes.md)) 66 | - [22nd January 2024](2024-01-22) 67 | - ([Agenda](2024-01-22/agenda.md)) 68 | - ([Minutes](2024-01-22/minutes.md)) 69 | 70 |
71 | 72 |
73 | Meetings in 2023 74 | 75 | - [11th December 2023](2023-12-11) 76 | - ([Agenda](2023-12-11/agenda.md)) 77 | - ([Minutes](2023-12-11/minutes.md)) 78 | - [13th November 2023](2023-11-13) 79 | - ([Agenda](2023-11-13/agenda.md)) 80 | - ([Minutes](2023-11-13/minutes.md)) 81 | 82 |
83 | -------------------------------------------------------------------------------- /2024/2024-07-23/minutes.md: -------------------------------------------------------------------------------- 1 | # Minutes from MDN community meeting - 23rd July 2024 2 | 3 | **Attendees:** Ruth John (@Rumyra), Vadim Makeev (@pepelsbey), Pranshu Khanna (@pransh15), Dipika Bhattacharya (@dipikabh), Claas Augner (@caugner), Florian Scholz (@elchi3), Brian Smith (@bsmth), Andi Piper (@argl), Alejandro Alcalá (@GrayWolf9) 4 | 5 | **Host:** Pranshu Khanna (@pransh15) 6 | 7 | ## Intro and overview 8 | 9 | [Pranshu] Welcome to the July community call! If you're not a part of our Discord, please [join the MDN community](https://mdn.dev/discord). While you're in MDN spaces, make sure that you follow the [Mozilla Community Participation Guidelines](https://www.mozilla.org/en-US/about/governance/policies/participation/). 10 | 11 | ## MDN Birthday! (@pransh15) 12 | 13 | [Pranshu] Thank you for joining us today for this special edition of our community call. We are thrilled to have you all here as we celebrate a significant milestone – MDN's 19th birthday! 🥳 14 | 15 | Over the past 19 years, MDN has grown and evolved, becoming an invaluable resource for developers worldwide, and everyone on the call has contributed to making it what it is today. We are very grateful! 16 | 17 | Since it is MDN's Birthday, that also means as if it's your birthday. So, Happy Birthday everyone! 🍰 18 | 19 | ## Updates from GitHub Work Week (@pransh15) 20 | 21 | [Pranshu] We are excited to let the community know that we have wrapped up the GitHub work week and will implement the following changes: 22 | 23 | - We held a GitHub work week to focus on how we work in sync with the community on GitHub. 24 | - Focused on Stale PRs and Issues across the org. We closed a lot of issues, but the aim was never to get it below a target number. 25 | - Discussed issue triage guidelines. 26 | - Reworked teams to a new system that organizes them via team (e.g., MDN, Contributors, Peers, etc.). That includes removal of some teams like `yari-content-{locale}`, `mdn-{function}` that were based on repo access, etc. 27 | - Reviewed access rights to all repositories. 28 | - Evaluated our current pull request review process, received feedback from community members, and explored options for improvement. 29 | - Closed/responded to old discussions (pre-2023) 30 | 31 | You can read the full update in [GitHub Discussions](https://github.com/orgs/mdn/discussions/708). 32 | 33 | ## Scrimba Curriculum & MDN HTTP Observatory Feedback (@pransh15) 34 | 35 | [Pranshu] MDN launched two new initiatives this month, [the new MDN HTTP Observatory](https://developer.mozilla.org/en-US/observatory) and [MDN's partnership with Scrimba](https://developer.mozilla.org/en-US/blog/mdn-scrimba-partnership/). We are open to feedback from the community. 36 | 37 | ## Reviewer and Localization Meeting (@pransh15) 38 | 39 | [Pranshu] In the coming weeks, I wanted to propose starting a new Reviewer's & Localization meeting to discuss content focused topics on things the community and reviewers would like to discuss progress with the MDN Team and move forward with certain topics. 40 | 41 | [Florian S] We used to have a weekly editorial meeting similar to this, and I'm glad we are bringing a similar version back. 42 | 43 | ## New callouts system (@pepelsbey) 44 | 45 | [Vadim] There is an update on the new callout system, I'm not sure what the official terminlogy is, GitHub calls them Alerts (also known as admonitions in other systems). 46 | This is the change: 47 | 48 | Old method: 49 | 50 | ```md 51 | > **Note:** 52 | > This is a note 53 | ``` 54 | 55 | New method: 56 | 57 | ```md 58 | > [!NOTE] 59 | > This is a note 60 | ``` 61 | 62 | [Brian] This changes for folks who translate content as well, so `**Note:**` will have to be changed to `[!NOTE]` and so on. 63 | It looks like [we will not be localizing the keywords](https://github.com/mdn/yari/pull/11108#issuecomment-2163751845) in the source so `WARNING` will be used in all locales in markdown, but displayed in rendered documents in a localized version. 64 | Updates or confirmation on that coming soon, but it will be easier to maintain if the same keywords/syntax are used in all locales. 65 | The new method is now updated on the [MDN writing guidelines](https://developer.mozilla.org/en-US/docs/MDN/Writing_guidelines/Howto/Markdown_in_MDN#notes_warnings_and_callouts). 66 | 67 | [Pranshu] This was it, another great community call. Thank you everyone for joining, a very Happy Birthday to MDN, and everyone! 🍰 68 | -------------------------------------------------------------------------------- /2024/2024-10-23/minutes.md: -------------------------------------------------------------------------------- 1 | # Minutes from MDN community meeting - 23rd October, 2024 2 | 3 | **Attendees:** Ruth John (@Rumyra), Vadim Makeev (@pepelsbey), Pranshu Khanna (@pransh15), Claas Augner (@caugner), Brian Smith (@bsmth), Andi Piper (@argl), Florian Dieminger (@fiji-flo) 4 | 5 | **Host:** Pranshu Khanna (@pransh15) 6 | 7 | Pranshu: All right, welcome to the October community call for MDN. I am very happy that fall is upon us and so is this call. This month, we're starting with the agenda actually and to share the agenda in the chat and use this opportunity to remind again that this is Mozilla space and we expect everyone to abide by the CPG. Everyone's protected by the CPG. And in general, just don't be rude to folks. 8 | 9 | Pranshu: Now, jumping on to the agenda, team updates. First up is me. The community page is now live! We've been working on it for two and a half months to transform it from a simple resource into a hub for contributors, providing recognition, guidance, and connection through community calls and Discord. I'm thrilled with the redesign, and this is just the first iteration—more updates will come. If you have feedback or suggestions, please let us know. The link is in the chat! 10 | 11 | Pranshu: Moving to team updates. First up, Brian. 12 | 13 | Brian: Thanks, Pranshu! My focus for the next two months is consolidating MDN examples from external repositories into Markdown files within the content repo. This reduces maintenance overhead, prevents code duplication, and streamlines updates. 14 | 15 | Brian: Our goal is to move examples embedded on MDN pages directly into Markdown, starting with CSS examples. This will improve tooling, linting, and consistency across repositories. 16 | 17 | Brian: We currently have 140 repositories, with 28 related to examples. The plan is to automate much of the migration while ensuring manual checks. The first step is breaking down a large pull request (130 files changed) into smaller, manageable ones. 18 | 19 | Brian: This shift will also integrate better with MDN's code editors and Playground, leading to a more unified and efficient system. The next steps include tracking progress and refining automation efforts. 20 | 21 | Brian: This is a great opportunity for contributors! There will be a tracking issue and instructions for those who want to help. Let me know if you have any questions. 22 | 23 | Pranshu: I like this! Quick question—we currently have 20+ repositories for examples. What's the goal? 24 | 25 | Brian: Ideally, we reduce them to one active repo, archiving the rest. We need to avoid maintaining duplicate code while ensuring smooth updates. The first step is focusing on six key repositories, starting with CSS examples. 26 | 27 | Pranshu: Love it! Easier to maintain. 28 | 29 | Brian: Exactly. 30 | 31 | Pranshu: Any questions or feedback? Otherwise, that wraps up today’s updates. The floor is open for any additional discussions. 32 | 33 | Florian: I wasn’t sure I’d be ready, but I’ve added myself to the agenda right now and will share this early. We’ve been working on an iteration of the build system—everything stays the same, just better and more efficient. 34 | 35 | Florian: A key update is the new sidebar folder, where sidebars are now easily editable YAML files instead of macros. This simplifies maintenance and translation, as all translations will now be handled within content, removing the need for Yari-based translations. 36 | 37 | Florian: The new project, RARI, is in its final stages. We’ve been releasing builds on GitHub, and while it’s not yet ready for full use, we’re automating the publishing process via npm. The goal is a seamless rollout, ensuring no disruption to current workflows. 38 | 39 | Florian: RARI will allow users to opt into the beta with a simple command and integrate effortlessly with existing content repositories. While nothing major will change immediately, this update sets the stage for faster builds, better automation, and more streamlined content management. 40 | 41 | Florian: We're making this update with feature parity, so changes will be minimal. Some improvements include better automation for badges and external links. A major benefit is faster local builds—MDN content now compiles in 4-5 seconds, making it easier to track changes across pages. 42 | 43 | Florian: Our goal is to make the system more modular and flexible, allowing for faster iterations. A beta version should be ready by Friday or early next week, with the only major change being sidebar migration. Feedback is welcome! 44 | 45 | Vadim: RARI is a binary. How does installation work, and is it compatible with Windows, Linux, and other platforms? 46 | 47 | Florian: Yes, there are some limitations. We’ve created an npm package to handle installation, but binary distribution remains a challenge in today’s fragmented environment. 48 | 49 | Florian: We created an npm package to simplify installation—it downloads and executes the binary automatically. Currently, we support Linux, macOS, and Windows (x86 & ARM), covering most users. If WebAssembly stabilizes, we may expand support further. 50 | 51 | Vadim: So it’ll feel like a regular npm package? 52 | 53 | Florian: Exactly! Just install it, and it works. 54 | 55 | Brian: Any plans for improving the flaws dashboard or a successor? 56 | 57 | Florian: The current flaws system is slow and flawed, but necessary. We’re logging issues by category and working on automated fixes, including better tracking of macro errors and broken links. Our goal is to reduce flaws to zero, making maintenance easier. 58 | 59 | Florian: A key improvement is automating link fixes, and replacing incorrect URLs at scale. We’ll test this in Berlin, focusing on cleanup before enforcing stricter rules. 60 | 61 | Brian: Sounds great! 62 | 63 | Pranshu: That wraps up the October Community Call—thanks, everyone! See you at the content call on Monday. 64 | -------------------------------------------------------------------------------- /2024/2024-02-26/minutes.md: -------------------------------------------------------------------------------- 1 | # Minutes from MDN community meeting 26th February 2024 2 | 3 | **Attendees:** 4 | Brian (@bsmth), Vadim (@pepelsbey), Dipika (@dipikabh), Anuja (@AnujaRajput727), Florian D (@fiji-flo), Konstantina (@couci), Florian S (@Elchi3), Jean-Yves (@teoli2003), Chris (@chrisdavidmills), Onkar (@OnkarRuikar), Owen, Christine (@CBID2) 5 | 6 | **Host:** Brian (@bsmth) 7 | 8 | **Taking notes:** Dipika (@dipikabh) 9 | 10 | ## Intro & overview of agenda 11 | 12 | (Brian) Welcome, let's wait for everyone to join in. 13 | As a reminder, please use the Zoom chat or raise your hand to ask any questions. 14 | 15 | - We have a position open for an [Open Source Community Manager](https://www.mozilla.org/en-US/careers/position/gh/5675010/). It is an exciting role. Please share with your networks. 16 | - There's a new post on the MDN Blog [about technical writing](https://developer.mozilla.org/en-US/blog/technical-writing/) by Dipika. 17 | - Ruth is organizing a content workshop for sometime in March, where we'll assess the Learn area and related docs. This exercise will also be important after the introduction of the MDN Curriculum. 18 | 19 | ## Team updates 20 | 21 | ### MDN Curriculum launch (@chrisdavidmills and @couci) 22 | 23 | Chris: 24 | 25 | - The MDN Curriculum is ready for launch tomorrow, February 27th. 26 | - For those who haven't heard, it will serve as a canonical blueprint to base courses on, a roadmap for learners, and a guide to design certifications. 27 | - (Sharing screen to show a pre-launch preview) A walthrough of the three modules: Getting started, Core, and Extensions. 28 | 29 | Konstantina: 30 | 31 | - Anuja has done a fabulous job with the design work for the MDN Curriculum. 32 | - The MDN Curriculum is launching tomorrow and there'll be a blog post from Hermina as well. 33 | - Let us know if you have any questions when you start using the MDN Curriculum. 34 | - The blog post will link to the curriculum repository where folks will be able to give feedback. 35 | 36 | Question from Brian: Is there any guidance or expectation on how much time a learner would take when proceeding from one module to the next? 37 | Chris: We had considered this aspect but timing ideas are vague and very subjective. The circumstances and backgrounds of learners are pretty varied. We decided not to include any time guidance for now but based on feedback, we could consider it in the future. 38 | 39 | ## Contributing to MDN (@bsmth) 40 | 41 | - Most of the folks in this call are already aware but for the benefit of those new to the project, I'd like to provide a brief overview of how you can contribute to MDN, where to look for docs, and how to chat with us or ask for help. 42 | 43 |
44 | 45 | Contributing to MDN 46 | 47 | > What's MDN Web Docs? 48 | > 12,000 pages (as of 2024) Web platform docs: HTML, CSS, JS, Web APIs 49 | > 50 | > Mozilla content people writing docs and reviewing: 51 | > Dipika Bhattacharya (@dipikabh) 52 | > Brian Smith (@bsmth) 53 | > Vadim Makeev (@pepelsbey) 54 | > Ruth John (@rumyra) 55 | > 56 | > We also work with: 57 | > Dave Letorey (@dletorey) 58 | > Hamish Willee (@hamishwillee) 59 | > Vinyl Da.i'gyu-Kazotetsu (@queengooborg) 60 | > 61 | > MDN Engineering: 62 | > Claas Augner (@caugner) 63 | > Leo McArdle (@leomca) 64 | > Andi Pieper (@argl) 65 | > Florian Dieminger (@fijiflo) 66 | > 67 | > MDN Product who work on MDN Plus and other features: 68 | > Anuja Rajput (UX) 69 | > Miruna Curtean (QA) 70 | > Sonal Sood (Product Manager) 71 | > Hermina Condei (Director) 72 | > 73 | > Open Web Docs also adding / reviewing content: 74 | > Estelle Weyl (@estelle) 75 | > Will Bamberg (@wbamberg) 76 | > Florian Scholz (@elchi3) 77 | > Jean-Yves Perrier (@teoli2003) 78 | > Also featuring! 79 | > Vinyl Da.i'gyu-Kazotetsu (@queengooborg) 80 | > 81 | > We live on GitHub. 82 | > MDN used to be maintained as a wiki and was always accepting > contributions, but was a little hidden. 83 | > Moved to GitHub in 2020 and since then, mdn/content top 30 projects on > GitHub (last time we checked). 84 | > Almost 21,500 commits to mdn/content main branch, and 12,000 pages > means 12,000 markdown files. 85 | > 86 | > We work on: 87 | > 88 | > - Firefox release notes & related doc updates, projects like > documenting features in Interop23 89 | > - reviewing pull requests, triaging issues (needs triage label) 90 | > - Org maintenance 91 | > - Automation / CI / dependencies 92 | > - Blog 93 | > 94 | > OSS maintainance: 95 | > 400 PRs per month in content repo 96 | > 97 | > In the last 2 weeks, there's been 98 | > 2,700 clones per week (CI?) 99 | > 10,000 unique repo visitors 100 | > ossinsight.io - mdn/content 101 | > 102 | > (Where the code lives, an overview of our repositories.) 103 | > 104 | > Looking for something to work on? 105 | > Check existing issues, they're usually labeled per technology category. 106 | > Good first issue / accepting PR are great. 107 | > Ask us about larger work in one of our communications channels (GitHub > Discussions / Discord) 108 | > Talk to us! 109 | > 110 | > Getting started: 111 | > 112 | > - Look for CONTRIBUTING.md 113 | > Things that are the same for all repos: 114 | > - Git and GitHub setup is same for all repos 115 | > - Opening a pull request 116 | > For hints on this, the MDN contribution docs are thorough with > guidance on incorporating feedback from reviews. 117 | > Check results of tests, there are automated suggestions to fix issues. 118 | > Please look at the open source etiquette guide. 119 | > Stuck --> Talk to us! 120 | > 121 | > Good PRs: 122 | > 123 | > - Add a description for the PR (fill out the template) 124 | > - Add "Fixes #123" if you fix an issue 125 | > - Link related PRs, Examples / similar changes 126 | > - incorporate feedback during review 127 | > - Have kind communication, also when there are disagreements. 128 | > 129 | > Get in touch in our communication channels. 130 | > On Discord or Matrix -> say hello, talk about your work, ask for help > getting your changes live. 131 | > GitHub Discussions -> something needs decision or further… discussion 132 | > Sensitive communications? 133 | > 134 | > More resources at developer.mozilla.org/docs/MDN 135 | 136 |
137 | -------------------------------------------------------------------------------- /2024/2024-08-21/minutes.md: -------------------------------------------------------------------------------- 1 | # Minutes from MDN Community Meeting - 21st August 2024 2 | 3 | Attendees: Ruth John (@Rumyra), Vadim Makeev (@pepelsbey), Pranshu Khanna (@pransh15), Dipika Bhattacharya (@dipikabh), Florian Dieminger (@fiji-flo), Leo (@LeoMcA), Andi Piper (@argl), Chris (@chrisdavidmills), Onkar Ruikar(@OnkarRuikar), Jessica Rose, Lucas Garcia, Reko, Halil 4 | 5 | Host: Pranshu Khanna (@pransh15) 6 | 7 | 8 | ## Contributor Spotlight for August (@pransh15) 9 | 10 | [Pranshu] One important item not on the agenda is the contributor spotlight for August. We are highlighting Josh Cena (@Josh-Cena), one of our contributors whose work we greatly appreciate. Josh has made numerous contributions to MDN, and if you've been around, you’ve probably seen his work. This is just a way to recognize Josh and everything he does for MDN. I wanted to share this on the community call before making the announcement. 11 | 12 | - Contributor Spotlight: https://developer.mozilla.org/en-US/community/spotlight/joshua-chen 13 | 14 | ## Content Team Meeting Starting September 2nd (@pransh15) 15 | 16 | In the last community call, I mentioned that we should have a separate reviewers meeting. We've decided to call it the Content Meeting to better reflect the scope and focus of these meetings — this meeting will be our space to discuss all things content. 17 | 18 | We're open to suggestions on how to structure this meeting. I was thinking of keeping an open Google Doc with the complete agenda, where folks can add the issues, PRs, and topics they want to discuss. 19 | 20 | We currently have everything set up on GitHub, but a running document would help us keep track of everything together, and of course, that doc will be linked. 21 | 22 | [Ruth] That sounds great, Pranshu. 23 | 24 | ## Call for Contributions from Our Friends at Common Voice (Jessica) 25 | 26 | [Jessica] I want to interrupt the MDN call to talk about Common Voice. Many of the Mozilla folks had an offsite last week, and one thing I kept hearing from the MDN team was, "Oh, we've got the best contributors!" They were a little bit boastful, if I’m being honest. 27 | 28 | One thing that made sense is that MDN contributors are understandably passionate about good documentation. So, I wanted to talk to you all about Common Voice, and this is really just a very soft cry for help. 29 | 30 | I’m just starting to rework our documentation. You don’t have to write code or do anything technical, but if any of you have the time and interest, I’d love for you to look at our documentation and give us feedback. 31 | 32 | Instead of "PRs welcome", we’ve got a bunch of issues and complaints. If it’s okay, I’ll very briefly chat about what Common Voice is, and show you where the repo lives. It’ll just be a very chill five minutes. 33 | 34 | Common Voice is one of my favorite open-source projects. If you've ever used Siri or Google, or any voice assistant, you know they work 100% of the time—as long as you sound exactly like me. 35 | 36 | Common Voice is a voice contribution platform that lets people donate their voice by reading clips in their home languages. We release this data under a copyright-free, cost-free dataset. Our goal is to ensure that voice technologies work for more languages and accents and that developers building these technologies have high-quality datasets without cost barriers. 37 | 38 | If you want to contribute non-technically, you can read clips in your home language or listen to others. 39 | 40 | One criticism we often hear is, "You don’t have my language." We love that feedback, so right now Common Voice offers data in just 530 languages. But if you think we should add your language, come in and request it. We’d love that. 41 | 42 | Our docs are currently in our main repo, and we’re debating whether to keep it there. If you all have strong opinions, I’d love to hear them. 43 | 44 | I head the project for our main platform and data collection platform. If you have time, it would be immensely helpful if you could take a look and provide feedback. You all are really passionate about contributor guidelines and documentation. Sharing your input would be one of the kindest things you can do. 45 | 46 | If you have 5 or 10 minutes, looking at the documentation and saying, "Hey, this doesn't make sense," or "This is weird," would be incredibly valuable. We’re really looking for wider community feedback because we work on it a lot, and we love it, which means we have a bit of expert bias. 47 | 48 | If you want to raise an issue, I’ll get back to you as soon as I can. But I also understand everyone’s busy. Thank you so much! 49 | 50 | [Chris] Cool. 51 | 52 | [Pranshu] This is great. I’ve also shared the links for Common Voice and GitHub if you all want to check them out: 53 | 54 | - Common Voice: https://commonvoice.mozilla.org/ 55 | - GitHub: https://github.com/common-voice/common-voice 56 | 57 | Where can we find you if we have questions, Jessica? 58 | 59 | [Jessica] The links are in the repo. We’ve also got a Discourse forum, a Matrix channel, or you can email us. There's a 50-50 chance I'll reply, or you might hear from our language community manager, Dina, who is a cooler, smarter version of me. 60 | 61 | [Pranshu] Awesome. Thank you so much. 62 | 63 | ## Revamping the Community Page (@pransh15) 64 | 65 | [Pranshu] Next up, this is both an announcement and a call for contributors. We are revamping the community page! We want the page to focus more on our contributors, with space for them to be featured, and clear ways for newcomers to contribute, all while keeping our good first issues front and center. 66 | 67 | If you want to be part of the contributor section on the community page, reach out to me, and I’ll send you a form to fill out. We would love to feature you as part of our community. 68 | 69 | ## Adding a Few Scrimba Links to the Curriculum (@chrisdavidmills) 70 | 71 | [Chris] You all might know that we have the MDN curriculum published, and Scrimba is our learning partner. What we’re currently doing is looking for ways to increase engagement. Full disclosure: this brings us affiliate revenue, which goes back into MDN to make it even better. 72 | 73 | We’re experimenting with including a few Scrimba links in strategic places in the learning area. We want to get the balance right — we don’t want to add links everywhere, which could seem spammy or like product placement. But we do want to increase engagement. 74 | 75 | MDN typically has strict rules about commercial and promotional links, but since Scrimba is a partner and a valid educational resource, we’re going to try adding a few links and see how it looks. We’ll start with 4 or 5. 76 | 77 | I just wanted to give everyone a heads-up so that you know what’s going on, and you can respond either here or when the links appear. 78 | 79 | [Ruth] We do have a strict policy for adding external links on MDN, but as Chris said, this is a partner. We’re going to see if this drives more engagement, and we’ll take it from there. We’re not going to plaster the links everywhere. We’ve selected a few specific pages, so it’s non-intrusive. 80 | 81 | [Pranshu] 82 | Okay, we're good. Thank you so much, everyone, for joining. I’ll see some of you at the content meeting in September. 83 | -------------------------------------------------------------------------------- /2024/2024-05-29/minutes.md: -------------------------------------------------------------------------------- 1 | # Minutes from MDN community meeting 29th May 2024 2 | 3 | **Attendees:** 4 | Ruth John (@Rumyra), 5 | Chris Mills (@chrisdavidmills), 6 | Vadim Makeev (@pepelsbey), 7 | Pranshu Khanna (@pransh15), 8 | Dipika Bhattacharya (@dipikabh), 9 | Christine Belzie (@CBID2), 10 | Eric Meyer (@meyerweb), 11 | Florian Dieminger (@fiji-flo), 12 | Claas Augner (@caugner), 13 | Anuja (@AnujaRajput727), 14 | Florian Scholz (@elchi3), 15 | Natalia (@nataliaschlebinger) 16 | 17 | **Host:** Vadim (@pepelsbey) 18 | 19 | ## Intro and overview 20 | 21 | [Vadim] Okay. Let's start with the first topic on our agenda. 22 | 23 | ## A new community manager introduction (@pepelsbey) 24 | 25 | [Pranshu Khanna on GitHub](https://github.com/pransh15) 26 | 27 | [Vadim] We have a new community manager joined MDN content team. Pranshu, introduce yourself. 28 | 29 | [Pranshu] Thank you. Hi everyone. I'm Pranshu. I am the new community manager for MDN. I've been a Mozilla contributor for a while now. I'm excited to join in the team. I've been in and around open source almost all my career and life. At least young life and yeah, looking forward to working with all of you and seeing you every month. 30 | 31 | [Vadim] Pranshu will be running the next community call. Perhaps you all already know Pranshu from our Discord and GitHub Discussions. 32 | MDN community is the is the most important part of our work. It's not just a bunch of teams, it includes everyone. So yeah, if you have any questions, Pranshu is your man. 33 | 34 | [Chris] It's awesome. I'm really excited about you joining Pranshu and feel free to reach out to me if you have any questions about the old-school context of MDN because I've been around for a very long time. Happy to help with some of the stuff that you're doing because I think it's going to be really valuable for us. 35 | 36 | [Pranshu] Thank you so much. I'll reach out and yeah, we'll jump on a call. 37 | 38 | 39 | [Vadim] Moving on in the agenda, we have Curriculum updates from Chris. 40 | 41 | ## Curriculum updates (@chrisdavidmills) 42 | 43 | [MDN Curriculum](https://developer.mozilla.org/en-US/curriculum/) 44 | 45 | [Chris] Hello folks. As some of you already know, I wear two hats these days. I have a Mozilla hat and a Google hat. I have my Mozilla hat on today. 46 | 47 | I'd like to draw your attention to some of the work that we've been doing for the MDN Curriculum. We released the MDN Curriculum and it seems to have gone down fairly well. We've had quite a bit of interest from various folks in education and academia and industry and using it to support the knowledge that they need to make available via some of their educational projects. That's really cool. 48 | 49 | We've also been considering bringing on board official education partners. Because one of the things about the curriculum is that it doesn't actually contain any learning material. It is a curriculum in the academic sense. It's basically a syllabus. This was deliberate, there's so much awesome content already available on MDN that we thought it would be ridiculous to just repeat a load of it again. 50 | 51 | But we also want to start linking out to some learning partners. Some of these might be paid. We will definitely also include some free ones because we believe that everybody should be able to have access to this awesome educational experience. 52 | 53 | I can't really say much more about who yet but some of you probably have some guesses as to who is we're gonna announce as our 1st educational partner. So watch this space and look out for it at some point in June. 54 | 55 | As part of the process of selecting learning partners, we've been doing a whole ton of work reviewing their courses and giving them feedback on how to improve their material to make sure that it covers what we feel is the required amount of semantics, accessibility, any information that we feel web developers need to create an awesome and accessible web. So that's been really valuable and a lot of them have been very receptive to that. 56 | 57 | So yeah, I see good things in this space. Watch out for more announcements about learning partners soon. 58 | 59 | [Vadim] Thank you, Chris. 60 | 61 | ## Yari rewrite project (@fiji-flo) 62 | 63 | [Yari: The platform code behind MDN Web Docs](https://github.com/mdn/yari/) 64 | 65 | [Florian] I think we'll blog about it in the next few weeks. So I've been trying to address quite some pain points. For the past 6 weeks, I've been working on the rewrite project to replace Yari with a successor to solve a lot of pain points. 66 | 67 | [Florian] Over the past few years, I tried to address a lot of these issues and became clear that some of them are fundamental architectural issues and the only way to solve them bottom up is to actually start from scratch. This might sound scary, but it's not. I am quite close, as I said, like 6 weeks in. 68 | 69 | The most important thing will be the parity rewrite. So, there should not be any visible change. And everything will render exactly the same. We do this to then incrementally start improving things. 70 | 71 | [Florian] One of our pain points is performance and the most immediate impact will be how long it takes to deploy. 72 | 73 | [Florian] For pure deployment, changes will be reflected like in the olden days when we had a wiki. So bringing parity with 4 years ago. And also build future parity. I do wanna do some improvements in how things work. 74 | 75 | One of the biggest changes is most likely the sidebars. 76 | 77 | [Florian] I don't want to change how the sidebars look and feel. Let me share a link for branch of mine: https://github.com/fiji-flo/content/blob/move-sidebars/files/sidebars/en-us/cssref.yaml. This is a collection of a lot of links, sprinkled with some automation. 78 | 79 | Most important change is that it moved moves sidebars into the content repository. So no more PRs to the build system if you want to change something that actually is content in a way. The other benefit it has is that it takes the titles out of the front matter. Currently, all of this is translated in the macro which it doesn't have to be. 80 | 81 | This is a sneak peak of changes that are coming. When we switch systems or if I just back port this to, which I think is also not too much work. 82 | 83 | [Florian] I'll open up the repo. Right now it's private because it's really quite messy for me because the code moves quite a lot. The work can be forwarded transparently. I want to be sure to wait until it's inevitable and not get people excited and then disappoint them. 84 | 85 | [Vadim] Yeah, thank you. And that's quite an improvement. We're going down from 1,500 to 300 lines of code. 86 | 87 | 88 | [Chris] Super exciting. It's going to be superb to be able to edit things like side bars in the content repo and not have to try and do it in yari every time. 89 | 90 | [Florian] That's to the other topic I wanted to be discussed. There's clear intentions to move much more content into the front matter and also start using templates, start to leverage page types. When we moved to Yari, we didn't have page types, we now have them and there's no reason why not leverage them. Also a big shout out to everyone who worked on page types and pushed for them. 91 | 92 | We can have proper page templates to automatically add things like web compat, browser compat and specification data. This is now within reach. I hope by the end of the year, things will get better for all you. 93 | 94 | ## Stalled PR discussion (@CBID2) 95 | 96 | [Docs: making information about read-only clearer](https://github.com/mdn/content/pull/33193) 97 | 98 | [Vadim] We can give a chance to discuss this pull request. Christine if you're still up for it, go ahead and we can talk about it or we can we can discuss on Discord. 99 | 100 | 101 | [Christine] It's mostly that I need an update. I've added what the maintainer suggested, I'm waiting for feedback. 102 | 103 | [Vadim] I see that Estelle is reviewing this. You can tag her again or some other people from the community can have a look at this PR. 104 | 105 | [Christine] Alright. 106 | 107 | [Vadim] Thank you for bringing this up. Like I mentioned before, you can always go to to our Discord and ask for help there 108 | 109 | [Christine] Okay. 110 | 111 | [Ruth] Yeah, thank you, Christine. We can take a look at this one. If you have any in the future that get stalled, just ping us in Discord. Sorry this one has got stalled. 112 | 113 | [Vadim] Good. And, that's it for today. We'll announce the next date for the community call, but it most likely will be around end of June. Look for announcement in Discord or in the GitHub Discussions. 114 | 115 | We'll see each other in June or in pull requests. See you around. 116 | 117 | [Chris] Awesome, nice to see you all. 118 | 119 | [Ruth] Thank you everyone. 120 | -------------------------------------------------------------------------------- /2023/2023-11-13/minutes.md: -------------------------------------------------------------------------------- 1 | # Minutes from MDN community meeting 13th November 2023 2 | 3 | ## Intro 4 | 5 | - (Ruth) enabled captioning, there's a transcript, call is not recorded 6 | 7 | - 1 again next month, date and time TBD, looking at frequency of these calls in future 8 | - Catch us on Discord, we cleaned it up, we are there 9 | - GitHub labels, if you're going to change labels, ask us or let us know. 10 | - All discussions should be in the [mdn-community](https://github.com/orgs/mdn/discussions) repo 11 | - We will move discussions from across various repos to the mdn-community repo 12 | - Hiring an [engineer, 12 month fixed](https://www.mozilla.org/en-US/careers/position/gh/5448569/), let us know if you know someone 13 | - Summary of the agenda 14 | 15 | ## Issue triage 16 | 17 | - Claas, one focus for us in Q4 is triaging issues, PRs and Discussion. 18 | - October we looked at issues. Our target is that 95% of issues are triaged within a week. This is tracked in a GitHub project that is private. Combination of automation helps us surface issues we weren't looking at. 19 | - We are three teams, product, content and eng. The majority of issues come in for content, but the first challenge is figuring out who should be looking at which issue. Often the engineering team is involved in many issues as there's overlap. 20 | - Triage has a lot of aspects, identify missing information, categorize it, get an understanding of what kinds of issues arise. We already use labels for this. 21 | - next step is figuring out how much work needs to be done, next is priority - figuring out if it should change or if priority needs to be added. 22 | - We have a short backlog of issues to go through, the backlog is decreasing, focus for November is backlog. 23 | - Next topic is PRs. Adding codeowners, adding GitHub project which gives an overview of many repos, should decrease number of old PRs that nobody has eyes on. 24 | - Lastly is Discussions, we will look at this in December. This hasn't always happened in the past. 25 | - Any questions? 26 | - (Robert Nyman) With issues and triage - is there different criteria for types of triage? For plus and content, do they end up in different places? 27 | - Claas, good question, we have one project with different views for different functions. Short answer is no, all issues go through the same funnel. Triage is only one part, there's also prioritization etc, but triage is the first stage. 28 | 29 | ## Baseline 30 | 31 | - Baseline is a common identifier for web platform features. 32 | - Initially launched a few months ago. Quite significant feedback that it didn't quite meet developer expectations. Definition needed quite a lot of work 33 | - Agreed on a new definition (TBD). This is not a huge departure, just an iteration. Two baselines for "support", now recognize interoperability, no longer wait two releases. As soon as it's in a stable version of all major browser versions, it's baseline. Wider availability 2.5 years after all major browsers support it. Full cross-browser support. 34 | - Copy and design are still in progress. 35 | - Baseline high and low -> baseline high, developers do not need to think about whether they can use it or not. Daniel will go into detail on this later. 36 | - How it's presented on MDN may change in future. 37 | - Questions: 38 | - (Vadim) definition has changed from 2 stable major versions to 2.5 years. 39 | - (Leo) Definition has accelerated from 2 stable versions to 0. Design has "long term" / wider support. New design to represent this is incoming. Standards people and vendors are concerned that we will discourage use of features, or be too encouraging to use experimental features. This is what we're experimenting with. 40 | - (Daniel) No questions from me 41 | 42 | ## Web platform features 43 | 44 | - (Daniel) web features is a project to provide a taxonomy of the major features of the web platform. There's already BCD, to identify all points of CSS props and values, granularity is quite fine. Web features try to zoom out and see if all of CSS Grid is supported. On caniuse, we have one box that shows support for CSS Grid. We're trying to regularize this, CSS grid is made of these features and sub-features. Consider also subgrid, web features identify this as a separate thing. We're looking at relationships of features and how they will look in future. 45 | - At the moment it's a way of linking between resources. Link to spec, to BCD, to caniuse. 46 | - Biggest one is Baseline, how this status is built is based on knowing when and where these features are supported. Working on bringing this into BCD. This will become a useful tool for authors to help them understand how to distinguish between features, or influence how features are organized. Grouping bits and pieces of the web is difficult. Web features help here. 47 | - (Ruth) you only have to look at the amount of files to know that this is necessary 48 | - (Vadim) Thank you for pointing out the difference between BCD and web features. 49 | 50 | ## Browser Compat Data 51 | 52 | - (Florian) We are Open Web Docs, we contribute to MDN. Talking a lot with Daniel about how to tag features and categorize them as a group. 53 | - Working a lot with [WebDX community group](https://github.com/openwebdocs/project/issues/169) to figure out how to sort, group and categorize these features. 54 | - Not 12,000 features, but 15,000 in BCD. 55 | - Workflow hopefully looks like tagging resources when adding new BCD data, big thanks to Daniel for his help. 56 | - [Automation in BCD](https://github.com/openwebdocs/project/issues/168), thanks to the work that JYP has done in the last 4 weeks, we're working on the process of automating adding data. This is a hard task to do manually. 57 | - MDN BCD collector can automatically test features, we want to create a pipeline that 58 | - when a browser makes a release, mdn-bcd-collector runs to collect which features are supported. Thanks to MDN team for reviews. 59 | - Shout out to Sovereign Tech Fund who funds this work. 60 | - (Ruth) You're putting the web feature key into BCD, and in web features are you adding the there? 61 | - (Florian) the idea is that you create a group in web features, then add they key to BCD. 62 | - (Ruth) Do we start this already? 63 | - (Florian) We are going to start doing this now. 64 | - (Daniel) One thing that's challenging is to bring in people to create groups and to review these. We want to create features that are useful. When something new lands in Chrome, and an author adds BCD data, this is an opportunity to tag work that's landing so that when a new key is added in BCD, we trigger a process in web features. 65 | - (Ruth) We could check how our workflow would look like as authors, how does it look like for BCD updates. Making a note that we will try to find out best way to move forward in practical way. 66 | 67 | ## Questions from agenda: 68 | 69 | ### (JYP) Recording and displaying security requirement of APIs 70 | 71 | - [Discussion](https://github.com/orgs/mdn/discussions/288) started 1 yr ago. Will thinks it's time to get to a first agreement on this. 72 | - Background is that a lot of APIs have security requirements, like secure contexts, permissions etc. Currently we don't store or display this very effectively. 73 | - Proposal is to add front-matter keys to easily display and manage these. 74 | - This is a long project, so a decision on how to do this should be done soon. 75 | - Please look at this discussion and make some comments so we can resolve this. 76 | - (Ruth) Maybe this data should be held elsewhere, this is visible from the discussion, Hamish and Will. How much front-matter do we want to add? Should there be a limit? 77 | - (JYP) The examples are long because they demonstrate all the examples, but this will be a 1-liner in practice. A flag like "secure context required" etc. but it is very rare that they are multiple values there. 78 | - (Ruth) Availability in workers, this is similar, is that also a front-matter thing? We could move this out of macros and into front matter. 79 | - (JYP) You can get workers info from webref. This doesn't have to be in the content at all. For security requirements, this is an exception, needs to be stored on our side. 80 | - (Ruth) Let's get it in webref 81 | - (JYP) If one day it's available in webref (for example) we could remove it in future. 82 | - (Ruth) Please see discussion 83 | 84 | ### (JYP) Globals in web api 85 | 86 | - [Discussion](https://github.com/orgs/mdn/discussions/360) 87 | - (JYP) 1.5 years ago, we decided to avoid duplication of pages by moving them to global api, examples b_toa, others like crypto object. This reduces several versions of the same content. 88 | - Will discovered that navigation is bad for this. When you get here from a certain path, you will be missing other methods etc. in the sidebar. By looking more closely, this is problematic. 89 | - This amounts to 17 pages of duplication. 90 | - Examples on these pages are also problematic as they use methods in different contexts. We can have different types of pages with examples that are relevant for the context the reader wants. 91 | - We are no longer blocked by BCD considerations. 92 | - (Ruth) Also do not like the sound of duplication, but the discussion looks like it's a can of worms. 93 | 94 | ### (Ruth) PR reviews 95 | 96 | - Please don't submit big pull request reviews. Because of the open way that we work, we sometimes have reviewers in mind when opening PRs. It's a little noisy / hard to tell who should look at PRs. How do we differentiate project work from community work? 97 | - Do we want to kill round robin reviewers / CODEOWNERS? 98 | - Any suggestions for improving this process? 99 | - (JYP) I don't like the Round Robin, I get things that I don't like to review. Assigning someone manually is an indicator that someone else should look at it. Suggest PR review meetings. We could do something like this in PR review. Easier to get typo fixes, smaller PRs 100 | - (Ruth) the upside is that PRs don't slip through the cracks with round robin. Maybe unassigning yourself as a reviewer could help? The other thing is that round robin only happens on content. We don't see other PRs on other repos. Could we try disabling round robin and seeing if reviews happen quicker? Any other ideas? 101 | - (Robert Nyman) I linked to an issue, we want everyone to contribute to MDN, we need some clarity in the process. It might be nice to see publicly available priorities. And expectations, the T-Shirt size categorization could be nice. The third thing is the one who's doing the review, comms would really help with expectations - knowing how long it will take to get a look at them. 102 | - (Ruth) We could try this. Regarding S/M/L we don't want to incentivize taking small PRs. 103 | - (Estelle) Bot comments do inflate the activity on PRs. A bot may add 4/5 comments even. Those tiny PRs that have 6 comments, maybe nobody will look at it. 104 | - (Ruth) Priority on content, all content is equal, not purely stats-driven. Thank you for the comments about PRs. 105 | -------------------------------------------------------------------------------- /2024/2024-04-29/minutes.md: -------------------------------------------------------------------------------- 1 | # Minutes from MDN community meeting 29th April 2024 2 | 3 | **Attendees:** 4 | Andi Pieper (@argl), Chris Mills (@chrisdavidmills), Claas Augner (@caugner), Dipika Bhattacharya (@dipikabh), Florian Dieminger (@fijiflo), Florian Scholz (@Elchi3), hochan Lee (@hochan222), Natalia (@nataliaschlebinger), Ruth John (@Rumyra), Vadim Makeev (@pepelsbey) 5 | 6 | **Host:** Vadim (@pepelsbey) 7 | 8 | **Taking notes:** Dipika (@dipikabh) 9 | 10 | ## Intro and overview 11 | 12 | [Vadim] Welcome everyone! We have a bunch of team updates first and then a couple of topics from the community. If you have any questions, feel free to unmute yourself, raise your hand, or just post them in the chat. 13 | 14 | ## Team updates 15 | 16 | ### Community manager update and reviewing community calls (@Rumyra) 17 | 18 | We are currently in the process of extending an offer to somebody. Fingers crossed that they’ll accept and hopefully the next call will be run by the new community manager. 19 | 20 | Getting a community manager onboard will give us the opportunity to review how our community calls are going, how people feel about the frequency and the time zone. We’re asking if people would like this call in a different time zone. 21 | 22 | [Vadim] Yes, please let us know on Discord or on the GitHub poll what time works best for you. Feel free to leave a comment: https://github.com/orgs/mdn/discussions/678. 23 | 24 | ### Update on content team projects (@Rumyra) 25 | 26 | - About the **content workshop** I ran a month ago, I am still writing up the notes. Sorry for the delay but my time has been dedicated in trying to hire a community manager over the past couple of weeks. 27 | In the content workshop, we talked about content architecture, types of content, and how we are looking at the new curriculum now along with the Learn area and what we want to do with guides and how-to's. 28 | 29 | I'm hoping that I will be able to produce the outline and the summary and propose the next steps forward from that work, very soon. So watch this space. 30 | 31 | - Some of you may have noticed that we added a new **article footer** back in February. The footer now has a little form asking if the page is useful. We intend to use this to give us the sentiment data on pages. 32 | 33 | We have one month of data from March and I will be looking at April's data as well and comparing them. In the content team, we’re looking at that data to guide us on the areas to improve or update. Any area with a low score implies people are saying this wasn't useful because of whatever reason; we can then look into those areas and hopefully update them. There'll be probably more to say on that once we actually start this work. 34 | 35 | I'm excited about getting the data in because then I can compare and see whether it's the same sections that are coming up month on month. 36 | 37 | - For the **reference indicators and banners**, I put together a document back in January. This kind of ties into some platform work, which is ongoing and will run into Q3/Q4. We are obviously in danger with Baseline being rolled out across the site - that's the indicator to say whether a feature is in baseline. 38 | 39 | We're going to get lots of banners at the top of pages, including those for secure context and deprecated features. We need to review how to present that information so we don't end up with just a box after box at the top of the page instead of the information that people actually need. 40 | 41 | I will be revisiting that document this quarter, along with some work that we're doing for the platform. 42 | 43 | Thanks to everybody who reviewed it. And again, sorry for the delay, but it's ongoing. 44 | 45 | Any questions? 46 | 47 | [Chris] I didn't necessarily have any questions, but I just wanted to say - very exciting news on the community manager. Really looking forward to seeing more progress on the content workshop. Let me know if I can help in any way because I do appreciate your time is very stretched. I can't remember if we were intending to have that as what data should we have, what data we need, and then have a "how to present it" as a separate follow-on thing from that session. 48 | 49 | [Ruth] Yes, that will be the next step. For reference indicators and banners, for example, if there's a lot of data that we want to show, maybe we should consider that together. I want to integrate people's comments from the workshop and then think about the next steps. We can talk about the kind of data that we have for pages and make sure that it's confirmed in the way that we're actually getting it, and then we can move forward with how that data is displayed. Thanks very much for the offer. I just want to at least get the transcript bit finished. And then do some rough drafting of some proposals for next steps. 50 | 51 | [Chris] I'm quite interested in the sentiment data. From my experience, people tend to comment primarily when they've had a bad experience and rarely if they have a good experience, which could be useful in identifying pages needing action. I'd love to see semi-regular data updates to monitor patterns and get a clearer idea of the trends. 52 | 53 | [Ruth] Right now, we're looking at high-level areas with low scores, not breaking it down by page yet. We have an average of about 70% good sentiment, so people are actually telling us that they like the content, which is super nice. But this isn't perfect and won't tell us exactly what is wrong, though it gives us a good place to start to know what needs our attention. 54 | 55 | We'll get more data over the next month, and I'll let you know when it comes in. 56 | 57 | ### Spam from zombie GitHub actions (@pepelsbey) 58 | 59 | I want to address the issue of notifications from zombie GitHub actions. You might have received notifications titled something like '[jessejay-ch/content] PR review companion workflow run' (https://github.com/jessejay-ch/content/pull/2). Someone forked the `mdn/content` repository a year ago, and it started failing some GitHub action. We later fixed this action, but the fork and pull request are stuck, causing it to fail every time someone pushes commits to `mdn/content`. I get an email every time my pull requests get merged, and 90 other people in the pull request also get notified. This has been going on for a year. 60 | 61 | I've contacted GitHub support, but there's not much they can do for now. They are, however, considering options to let users disable these notifications or unlink forks. 62 | 63 | In the meantime, we can only filter these out. I'm sorry for the inconvenience, but let us know if you experience something similar. We'll let you know if it gets solved in any way. 64 | 65 | ### SEO and translation experiments updates (@caugner) 66 | 67 | I wanted to briefly share two things. 68 | 69 | - First, we're working on SEO improvements, including [a notable experiment](https://github.com/orgs/mdn/discussions/673), though it's too early to share results. 70 | - Second, we're creating a German locale using machine translation. We'll share more details later, but this gives a sneak peek at what's coming. 71 | 72 | ## Contributor updates 73 | 74 | ### Documenting missing JavaScript errors (@nataliaschlebinger) 75 | 76 | Josh (@Josh-Cena) and I have been working on documenting errors. We've identified a list of errors to address, focusing particularly on JavaScript errors listed in V8. We noticed many errors that should be documented, especially those related to classes were missing. For example, there were only two class-related errors listed, while nameless functions were documented in more detail. 77 | 78 | It seems classes were introduced later, leading to this imbalance. Our initial plan was to go through the V8 list in order, but after discussing with Josh, who is reviewing the PRs, we've decided to allow contributors to choose the most interesting errors first. This way, we prioritize complex and valuable errors, particularly those users might actively search for, rather than just glancing at the error text and moving on. 79 | 80 | Related pull request: https://github.com/mdn/content/pull/32857 81 | Planning issue: https://github.com/mdn/mdn/issues/505 82 | 83 | [Chris] I really approve of this effort because when we first documented JavaScript errors, those pages became some of the most visited on the site. People search for errors in Google when they face issues, so updating these is definitely worthwhile. Have you talked to Florian Scholz (@Elchi3) about this? He originally documented the errors and might have useful insights. It's also great to have a checkbox for the errors completed, making it easier for contributors to pick up where others left off. One issue to consider is that error messages vary across browsers. V8 error messages are fine, but it might be helpful to link these to the equivalent messages in Gecko. This discrepancy isn't a blocker, but it's something to think about. 84 | 85 | [Ruth] I agree. I've seen the discussion on Discord and think going out of order is fine. Florian Scholz could give us feedback, and others can join the discussion. The checkbox idea is helpful for tracking progress and guiding contributors. You can message Florian on the GitHub issue for input. 86 | 87 | [Natalia] I'll contacted Florian. When testing errors, I've been running code that triggers the error on V8 and Gecko. There might be discrepancies, but it hasn't been an issue. We could consider how to handle these differences. 88 | 89 | Are there any automated tests for the documentation, particularly to ensure examples still work. If not, we could consider checking examples for errors across different browsers. 90 | 91 | [Florian D] No, we don't run automated tests on the content examples. This can be tricky because not everything works everywhere. Some examples are specifically wrong to teach the right approach. Additionally, errors can vary between JavaScript engines, and some are API-specific. 92 | 93 | [Ruth] I agree. Automated testing might not work well due to the variety of content and intentional errors. Let's focus on content errors for now. 94 | 95 | [Vadim] It sounds like something for browser compatibility data. Maybe we could add this data to BCD and run some tests. We could also flag features that are experimental in different JavaScript engines. 96 | 97 | [Chris] I think the priority is getting pages written. We can review them afterward. Thank you for the work on this. 98 | 99 | ### Documentation updates on MDN (@chrisdavidmills) 100 | 101 | I've been documenting various features for Google and responding to comments on my pull requests. This has led to a lot of published content, including: 102 | 103 | - [Long Animation Frames API](https://developer.mozilla.org/en-US/docs/Web/API/Performance_API/Long_animation_frame_timing) 104 | - [CSS `field-sizing` property](https://developer.mozilla.org/en-US/docs/Web/CSS/field-sizing) 105 | - [Vertical form controls](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_writing_modes/Vertical_controls) using writing modes, now coming to both Chrome and Firefox 106 | - The `notRestoredReasons` API, helping identify [why a page is incompatible with the back-forward cache](https://developer.mozilla.org/en-US/docs/Web/API/Performance_API/Monitoring_bfcache_blocking_reasons), aiding in performance improvements 107 | - [CSS relative color syntax](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_colors/Relative_colors), which received significant publicity 108 | 109 | I'm currently working on CSS anchor positioning, a new spec coming to Chrome and soon to other browsers. This feature simplifies anchoring UI elements, like context menus, to each other, eliminating the need for complex positioning scripts. Anchor positioning will be released in Chrome 125 around the middle of next month, and I aim to document it before then. 110 | 111 | Thanks to everyone who reviewed my work, helping to get these features published. 112 | 113 | ## Closing comments 114 | 115 | [Vadim] We'll figure out the date for the next community call, which might be in June. That's all for today. Have a great day, and see you next month or in pull requests or issues on GitHub! 116 | -------------------------------------------------------------------------------- /2023/2023-12-11/minutes.md: -------------------------------------------------------------------------------- 1 | # Minutes from MDN community meeting 11th December 2023 2 | 3 | **Attendees:** Ruth (@rumyra), Claas (@caugner), Zach (@zfox23), Vadim (@pepelsbey), Onkar (@OnkarRuikar), Dave (@dletorey), Vinyl (@queengooborg), Florian (@Elchi3), Jean-Yves (@teoli2003), Estelle (@estelle), Chris (@chrisdavidmills), Will (@wbamberg). 4 | 5 | **Host:** Ruth (@rumyra) 6 | 7 | **Taking notes:** Brian (@bsmth) 8 | 9 | ## Welcome 10 | 11 | - (Ruth) Happy holidays, this is the last community call of the year, incoming calls will be announced soon. 12 | 13 | - MDN team not here for week of 25th, will announce on GitHub. Bear in mind we may be slow to respond. 14 | - Reminder of Open source etiquette, everyone should revisit our CPG, familiarize yourself with it. Please be nice online. 15 | 16 | ## MDN Front End Developer Curriculum 17 | 18 | - Chris Mills 19 | 20 | - (GitHub repo URL for curriculum) - 21 | - Been working on FED (Front-End-Developer) curriculum. We'd like to improve education on MDN. 22 | - Started with Learn area, Chris worked a lot on about 100 articles on web dev. 23 | 24 | - starting point was feedback on other forums to make MDN more approachable for beginners as it can seem intimidating. 25 | - as an extension, should we revisit the Learn area as a curriculum? 26 | - Curriculum is based on research from people in a lot of different companies, what are people missing with new hires? what skills do people need? Are certifications actually useful? 27 | - Results were that hiring managers universally said we wish people knew more about a11y, core JavaScript, not just React. 28 | - Answer was very much "certs are not super useful", we want to see portfolios, certs cannot be trusted fully. Surely Mozilla has a reputation that could be trustworthy. 29 | - This is not a course, not a certification. This is the organization of the essentials that a FED should know, arranged into a pathway. Things are arranged as: 30 | - prerequisites (file system, tooling) 31 | - soft skills 32 | - research 33 | - team work, collaboration 34 | - core skills, JS, version control, testing. 35 | - optional extensions -> does privacy / frameworks etc belong in core skills? This is arguable, good to know, but being a security expert might not be a required. 36 | 37 | - Feedback is always welcome. In the new year, the curriculum will be published. It will be free. With some momentum, this could be the basis for courses that others will develop. Guide for complete beginners. Could be used for certifications, but no definite plans there at the moment. 38 | - (Q from Estelle): New v advanced, what is the boundary? 39 | - (CM) We've tried to include just fundamentals, but try to steer clear of advanced stuff. Core shouldn't be overwhelming for beginners. We want to keep it short and manageable. If someone wants to create a course from it, or create a certification, it shouldn't be impossible to test "everything". There may be room for this in the advanced or extension modules. Floor is open for this, please file issues on the repo. 40 | - (Estelle) - I have thoughts 41 | - (CM) Contact me on Slack or file an issue in the repo. 42 | 43 | ## MDN Observatory 44 | 45 | - (RJ) Work is ongoing on MDN Observatory, deep dive about this is postponed for now, but we'll share details soon, it will be on the agenda for the next call. 46 | 47 | ## Baseline 48 | 49 | - (RJ) New definition rolled out recently. More features are coming soon, there is an MDN blog, go read it :) 50 | There is a feedback mechanism on pages with this feature. The WebDX community is a place to give feedback there about that. 51 | 52 | ## Flaw fixing 53 | 54 | - (JYP) What happened this year fighting flaws on MDN. 55 | - At the top of each article (in development mode), there are flaws, and also on localhost, there is a list of flaws and a dashboard. 56 | - Over time, we want to fix all of them. At one point, there were 15,000 flaws. 57 | - At this year, there were 5,000, so far we're down to 2,500 over the year. 58 | - This has been organic, plus directed goal by others. Thanks to Onkar, Brian. 59 | - We're very close to only "missing pages" flaws. 60 | - There are a lot of BCD flaws, a lot of these are temporary, from current work in progress. 61 | - There are flaws for sidebar macros, for static methods. We want to take the macro and fix it there. 62 | - For missing pages, maybe we can get help from the community. 63 | - If there are community members who would like to help, reach out to JYP. These pages are easy enough to get started as a contributor. This will be a great project for 2024. At the moment, this is something for community efforts. 64 | - One thing that's annoying, there is a PR for redirection open from Onkar. This PR is open a long time, should be done soon. 65 | - (Ruth) Let us know when you want to get contributors involved, we can announce it. Claas - do you have eyes on the Yari PR? 66 | - (Claas) No capacity in December, but should be on the cards for first 2 weeks of January 2024. 67 | - [Notes in chat from Onkar] - Also implemented ReviewDog automatic reviews / suggestions from CI workflows doing linting. 68 | - (JYP) This is a really cool addition in 2023, this really lowers the amount of effort to fixing flaws. 69 | 70 | ## BCD 71 | 72 | - (Vinyl) OWD and Mozilla contractor, maintainer in BCD. Working extensively on BCD collector project. See link for web-features. [https://github.com/web-platform-dx/web-features] 73 | - Good chunk of data from web features now integrated into BCD. 74 | - WebDX group will be using this to implement feature categories. 75 | - Also working hard on a system to automatically update BCD following different browser releases. Whenever there's a new release, the collector runs. 76 | - (Ruth) Do we run it on stable or beta? 77 | - (Vinyl) We run it on stable now, because this is the least likely to change. Occasionally run on Beta, but we can do this more often. Main plan is to let machines do repetitive work. 78 | - Great news, just this week I've gone over BCD issues and closed old, duplicates, resolved etc. About 70% of the 168 issues resolved by the BCD collector! 79 | - (Ruth) that's amazing, well done. 80 | 81 | ## Content architecture 82 | 83 | - (Ruth) I am foreseeing changes with Learn and curriculum. What would be some next steps with organizing documentation. Should we be very strict about content architecture, would this help with guides and docs that sit in multiple places? 84 | - It would be nice to do a joint workshop on "what would you do to organize content" if we started from scratch. Having it very clear what you write and where it goes. 85 | - (JYP) I agree we need to discuss content architecture. Especially about Divio system, we've looked at this over many years. The recent changes are based on cleaning up guides that have been without a home for a long time. Some of them seem to be from 2007. These changes are more a cleaning rather than re architecture. This will in turn help with sidebars. 86 | - (Ruth) Thanks for clarifying. We're aware of the Divio system and we can use it for inspiration, but on MDN we are covering a lot of different technologies and this system might not be a silver bullet for us. 87 | - (Ruth) Would start planning a workshop, would be great to do two 1 hour (remote) sessions, would be nice to have a forum for everyone to have their input. Comments, questions, feedback welcome. 88 | 89 | ## Formal syntax 90 | 91 | - (Ruth) Handing it over to Onkar for this one. 92 | - (Onkar) [audio issues] 93 | - (Will Bamberg) I can share some info. This is a big issue, it's about more than Formal Syntax. We have pages about CSS, they have links to specs, links to BCD. How can we make sure these things agree? One of the main problems is formal syntax. What makes sense that MDN does is documenting the realities in browsers. But Formal Syntax documents whats in specs. We can choose to show formal syntax from a certain module, but not specific ones, such as those that are delivered or working in browsers. What's the best thing to do here? 94 | - We have people opening issues like "Formal syntax doesn't match what's on the page" 95 | - For the formal syntax, you could have a note saying "not all these things are not implemented" - but we don't have a way to show something as not implemented. At least the formal syntax as it currently is, is better than nothing, but it could be more helpful. 96 | - Another branch of this is that one of the problems that this exposes is basic support is not defined in BCD. 97 | - In BCD we have feature -> sub-feature. What does basic support mean? If you say Fx supports align items, but which values? How to find that out? 98 | - (Vinyl) in regards to a lot of that, the plan is to test for sub-features, and have it be as extensive and comprehensive as possible. So the collector can help with a lot fo that. We can have the collector scan the spec and build tests for this. 99 | - (WB) Often this is not clear-cut, as there are things such as different syntax in different module levels. 100 | - (JYP) Non-standard values don't appear in formal syntax. This is very quickly a can of worms, and very involved. 101 | - (Ruth) Thank you for the explanation. I re-read this, I've seen the issues coming in about this. We might want to try to do something sooner than later, with a notice in the meantime. I would suggest we do a temporary workaround. 102 | - (Will) It's not a fix, but it's helpful, so I'm +1 on that. There's a separate issue about bugs, this can be fixed, but the Formal syntax issues here are more content architecture issues, not bugs. 103 | - (Onkar) [audio issues] 104 | - (Will) As soon as you say you want to be precise about it, you'll hit issues. This doesn't go away if you go back to hand-curated data (mdn/data) 105 | - (Vinyl) WiFi issues, sorry. 106 | - (Ruth) This is something for us to handle in 2024 107 | - (Chris) Does this mean we don't have to update CSS data? 108 | - (Ruth) Not quite yet! We did put out a call to people using this package to say how much we depend on it, but nobody got back, so we couldn't deprecate it entirely. It's in limbo, but the end goal would be to deprecate it. 109 | - (Chris) I would love to remove and archive that completely. 110 | - (WB) There are translated strings, making it harder. The main one is CSSTree, which depends on mdn/data. It would be great to split mdn/data into two parts to separate concerns. I get the feeling CSSTree might not be maintained much at the moment, I'm not sure. Although there are some patches on top of MDN/Data, maybe they do their own thing to bridge gaps. 111 | - (Ruth) The decision is whether there's an interim solution while we wait for BCD to do sub-features. Should we add a banner / note? 112 | - (JYP) We can try a sentence, like "This is the spec syntax" and see if there are fewer issues opened. we want issues to be reported, of course, but to mention "there may be differences because browsers may have separate implementations". We could do a search/replace for this afterwards, which helps solve it. 113 | - (Ruth) This is also CSS-only at the moment, right? 114 | - (Will) If we think a real great fix in BCD would take a long time, there may not be very many places where the formal syntax shows stuff that's not on the pages. We could do overrides, some manual fixes. 115 | - (Ruth) Would you like to make a proposal so we can evaluate options? 116 | 117 | ## Removal of duplicate markdown headings for examples 118 | 119 | - (Ruth) Added by Dipika, this is about repeating titles in the prose and the code. 120 | We had a discussion about this one internally. Originally, I thought headings were a great idea, however I don't think that's a great solution, as the content is machine-readable with language of code blocks visible in source. 121 | - We're not going to be moving them to the right, that's not a fix. 122 | - (Will) This is not about the code, it's about the prose. The prose that's associated with the code. "Here's a block of HTML, here's a description about it". Just to be clear, it's about "how do you link the prose with the code?"" 123 | - (Ruth) How often does this happen? I would assume it's mostly implicit based on the position of the prose. 124 | - (Will) This has been talked to death, if you want convention that if you have prose before the code. Or if you say we want to support this use case, we have this convention. This makes it harder to review. 125 | - (Estelle) This came to a head with Chris Mills PR, there are many examples where there's 3 lines of CSS, 3 lines of JS, now it looks very much like a duplicate. When there is content, and a lot of it, it helps tell the user what they expect. Not always, when there's a complex example, this really helps readers when you describe complex actions. When you put the H3s in there, you can link to it from outside. To say we can't have it for newbies, this makes things much harder. We have to frame it based on what learners get, but it has to be geared towards learners. 126 | - (JYP) For the position, before or after, it would be great to get stats. If there's 23 pages, it's not much work. If it's 200+, it's a different story. 127 | - (Ruth) anything else? [no other topics] 128 | - Thanks all! 129 | -------------------------------------------------------------------------------- /2024/2024-01-22/minutes.md: -------------------------------------------------------------------------------- 1 | # Minutes from MDN community meeting 22nd January 2024 2 | 3 | **Attendees:** 4 | Ruth (@Rumyra), Brian (@bsmth), Vadim (@pepelsbey), Dipika (@dipikabh), Leo (@LeoMcA), Andi (@argl), Sonal (@s-sood), Florian (@Elchi3), Jean-Yves (@teoli2003), Estelle (@estelle), Chris (@chrisdavidmills), Robert (@robnyman), Onkar (@OnkarRuikar), Natalia (@nataliaschlebinger), Jordan Harband (@ljharb) 5 | 6 | **Host:** Brian (@bsmth) 7 | 8 | **Taking notes:** Dipika (@dipikabh) 9 | 10 | ## Welcome 11 | 12 | (Brian) Welcome everyone to this year's first community call. Thanks for joining in. We have a packed agenda. We'll try to cover the updates in the first half and then move over to community updates. I'll keep a time check. 13 | 14 | - I'll take this opportunity to welcome Vadim who joined MDN as a technical writer in November'23. He's based in Berlin. 15 | - Also let's welcome Andi, who's joined the engineering team on the 15th of this month. He's also based in Berlin. 16 | 17 | (Brian) A kind reminder for anyone working on contribution guidelines, macros, automations, give us a heads up for the changes coming. You know where to find us (Discord, Discussions on GitHub). 18 | 19 | ## Team updates 20 | 21 | ### Firefox [experimental features](https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Experimental_features) page workflow (@pepelsbey) 22 | 23 | - (Vadim) Firefox releases some features behind flags. They're interesting features that developers should play around with it. To enable surfacing these features, we decided to add a section to the Firefox release notes (as an example, we added [this section in Firefox 121](https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/121#experimental_web_features)). This will include a single para description to say which features are shipped in the release behind a flag. This would help making the developers aware. There are definitely features like :has(), declarative shadow dom, that developers would like to experiment. Highlighting this here in our community call so that we remember to update this section while preparing our release notes. 24 | - (Chris) Is the plan to keep both pages, "Firefox release notes" and "Experimental features"? This is a good move to create awareness among developers. 25 | - (Ruth) Yes, we'll keep both pages for now. The plan is also to somehow improve the table format on the "Experimental features" page moving forward 26 | 27 | ### Observatory (@LeoMcA) 28 | 29 | - (Leo) [Mozilla observatory](https://observatory.mozilla.org/) is coming to MDN. We recently announced this in our [blog post](https://developer.mozilla.org/en-US/blog/mdn-observatory/). We might be able to release it this week on Thursday. 30 | - As an introduction, its been around in Mozilla. Our infra team did not have capacity to maintain it. It is basically a tool where you give it a URL and it tells you the security recommendation, mostly around headers, recommends the best practices. 31 | - We’ll be updating and maintaining it from now on. 32 | - MDN is expanding on tools for web developers, like the Playground and now Observatory, and these tools link back to MDN 33 | - It is technically an interesting project. 34 | - We welcome your thoughts and ideas 35 | 36 | ### Yari architecture (the build part) v2.0 37 | 38 | - (Brian) Florian D. has sent some notes. Since Florian D is not here, Leo, do you want to fill in? 39 | - (Leo) Sure! Everyone please bear with me as I speak on behalf of Florian 40 | 41 | #### What we want to achieve: 42 | 43 | - Much faster build time 44 | - Incremental builds 45 | - Decouple content from front-end 46 | - Intermediate representation to make content reusable (like VS-Code / devtools integration) 47 | - Simplify writers experience (fewer dependencies and a dev process closer to production) 48 | - Be prepared to leverage new things like page types 49 | - Streamline our various code examples 50 | 51 | #### Where we are 52 | 53 | - We're scoping the work and are considering options moving forward. More once we narrowed things down. 54 | - Some options we'e considering: 55 | - Moving to Rust for most parts of the build system because it's: 56 | - Embedable via WASM so we can reuse code and gradually migrate 57 | - Easy to distribute as a single binary 58 | - Performant 59 | - Bigger changes to the macros. Some preliminary thoughts: 60 | - Move to a common templating language like mustache 61 | - Move to web-components that can either be rendered during build or in the client 62 | - Replace macros with custom md logic (think `[Array]` will link automagically to `/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array`) 63 | - Move more things like sidebar, BCD or syntax into front matter 64 | 65 | - (Jean-Yves) What is the timeline? This quarter or year? For macros, examples, please come to the writer team, we know why they are different, what they are used for, the nuances. So please discuss at the beginning. 66 | - (Leo) The aim is to try to do things gradually, we will definitely reach out. As for the timeline, probably the first half of this year, not sure of exact dates. The work is starting now. 67 | 68 | ### PR "size" labels in Content (@bsmth) 69 | 70 | - (Brian) I've added an automation that adds labels to pull requests in content https://github.com/mdn/content/labels?q=size based on the size of the pull request. You can find the related discussion: https://github.com/orgs/mdn/discussions/629 71 | - This is working as expected. 72 | - Now we can improve the categories. The numbers are at the moment, for example, large is small. We can change the configurations. 73 | - So let me know what you think 74 | - (Chris) I am pleased you’ve added this automation. There's certainly value in people with limited time to quickly pick up PRs for review and contribute. 75 | - (Brian) The bot was also adding comments to the PR, which we have disabled for now. But we can add going forward if they're helpful 76 | - (Chris) They might be helpful because then Estelle would not have to manually ask me to split my big PRs into smaller ones! 77 | 78 | ### Chat with Chris M about some pain points (@Rumyra) 79 | 80 | - (Ruth) Chris and I had a collaboration discussion to talk about the pain points in the last few months. Chris has put together a doc so we can share resolutions to the pain points very soon. Looking forward to discussions that come as a result. 81 | 82 | ## Contributor updates 83 | 84 | ### [Community help needed] Documenting interoperable APIs (@teoli2003) 85 | 86 | - (Jean-Yves) Let's document all `HTML*Element.*` APIs! 87 | - [Instructions](https://github.com/orgs/mdn/discussions/476) & [Task list](https://docs.google.com/spreadsheets/d/1lvITVZJM8dx8s_Kee5UNI1hDfPNF0gXQwjPop5xIF5E/edit#gid=369545647) 88 | - (Jean-Yves) This is a community project to document all interoperable APIs. It's been 10-15 years that we’ve been wanting to do this. Now is a good time to add all missing docs - document all the APIs that are now available in the three engines 89 | - There are more than 300 pages missing. 90 | - When we started documenting, over the years we gave priority to new features 91 | - With Baseline and Interop gaining importance, we now have a gap 92 | - Html elements - 300 93 | - Svg also 94 | - I've created a list of pages in Google docs, and there are instructions: Go to the task list, put your name (GitHub handle), create the pull request, and we’ll review 95 | - We managed to complete 3-4% in the last week itself. I am hoping we'll be done with all by the end of the year. I am hoping the process will become faster. 96 | - Once you've completed the documentation for one element, you can go quickly, use the same template and create another one. If we go faster, I am hoping it can be done by end of summer. 97 | - If you have any question, ping me on the pull request or on the discussion (linked above). 98 | - Thanks for your help. 99 | 100 | ### [Community help needed] Document missing JavaScript errors (@nataliaschlebinger) 101 | 102 | - (Natalia) Lot of them are missing, I looked into how many are missing. The details are captured in the issue https://github.com/mdn/mdn/issues/505. 103 | - I checked JS engine code, Spidermonkey, v8 104 | - (The connection was getting choppy and voice was breaking up, so Brian took over) 105 | - (Brian) I can provide context. There are JavaScript errors that Natalia has spotted are missing documentation. Different browsers report them differently. 106 | - We do have quite a few documented already. 107 | - If anybody has any concerns, let us know 108 | - Please leave questions in the issue 109 | - Natalia, if I’ve missed anything, please let us know in the chat! 110 | - (Natalia in chat): I was hesitating, thanks for the segway Brian!! The hardest part abt documenting the errors, is figuring out which ones we are missing, because if we look at the code of an engine, most user facing errors are next to internal ones. So maybe we need someone who is comfortable with that c++ code, to help out with that 111 | 112 | ### Update from Onkar (@OnkarRuikar) 113 | 114 | - For context: https://github.com/mdn/content/pull/31694#issuecomment-1902848995 115 | - Do not manually add/update the following: 116 | 117 | 1. Front-matter `status` 118 | 2. Page banners {{SeeCompatTable}}, {{Deprecated_Header}}, {{non-standard_header}} 119 | 3. Inline badges {{Experimental_Inline}} etc. 120 | 121 | - (Ruth) Can you let us know where this is documented, announced, or discussed. 122 | - (Onkar) It has not been announced. 123 | - (Jean-Yves) We've been doing this for a year. 124 | - (Ruth) My team is still doing the updates manually and we're not aware of these automations. Could you open a PR to update the guidelines, and then we can announce. 125 | 126 | ## Questions/Discussions 127 | 128 | ### Standards position in docs (@Rumyra) 129 | 130 | [Discussion open](https://github.com/orgs/mdn/discussions/463). I'll push this one out. I'd prefer to have a meeting specifically to discuss this because some folks involved are not here today. We'll hopefully meet within this week to discuss it. 131 | 132 | ### Consensus secure context usage (@teoli2003) 133 | 134 | - [Where and how to use `{{securecontext_inline}}`](https://github.com/orgs/mdn/discussions/482#discussioncomment-7825014) 135 | - (Jean-Yves) There is a discussion open on this. We'll move forward with the plan in the discussion. 136 | 137 | ### APIs that need an "enrollment" (@teoli2003) 138 | 139 | - The first APIs that need an "enrollment" before their use landed in ([Shared Storage API](https://developer.mozilla.org/en-US/docs/Web/API/Shared_Storage_API)). How to display this information on the relevant pages? A banner for secure contexts? 140 | - (Jean-Yves) Not going to discuss this here. In order to use APIs, you need to enroll. These are controversial APIs, linked to the [standards position in docs discussion](https://github.com/orgs/mdn/discussions/463) 141 | - (Florian Scholz in chat) Feature detection also doesn’t really work for APIs that use enrollment. If anyone has thoughts —> https://github.com/openwebdocs/mdn-bcd-collector/issues/986 142 | - (Chris) At the moment, there's only enrollment requirement. This is an early way of doing it - Shared Storage docs https://developer.mozilla.org/en-US/docs/Web/API/Shared_Storage_API#enrollment_and_local_testing. Happy to get feedback 143 | - (Brian) Where should we ask for feedback? 144 | - (Ruth) We’ll have a meeting soon, hopefully we'll be able to discuss intricacies 145 | - (Chris) So I wont create a discussion, we meet first 146 | 147 | ### Using GFM-standard syntax for notes & co (like `[!Notes]`) (@teoli2003) 148 | 149 | - https://github.com/mdn/yari/pull/10168 150 | - (Jean-Yves) GitHub has extended the markdown syntax, but we do our own syntax for Notes. 151 | - Do we want to use new syntax in phases? 152 | - Secondly, there are more types of notes in GitHub markdown. Do we want to use more cases? 153 | - For localization, you don't have to translate notes. It would be nice going forward. 154 | - Yari team can include this in their refactoring. It is better for maintenance. 155 | - Folks will know it works here in GitHub and elsewhere. We need to coordinate this effort. 156 | 157 | ### Accepting more sources for polyfills (@ljharb / @teoli2003) 158 | 159 | - https://github.com/orgs/mdn/discussions/475#discussion-6000833 160 | - (Jean-Yves) The current problem: few years ago, polyfills on MDN were a mess, were unmaintained, and were plain wrong. There were links to many pages with polyfills without correctness assessment. 161 | - 2 years ago, we decided not to host polyfills on MDN, instead we link to external websites 162 | - For security reasons, we want to be strict about which place we trust for polyfills, only standard places like tc39 163 | - It was never the intention that it would be the only one 164 | - We have a shortcoming, we only have one source. What if the source is not trustable or there are more? 165 | - We should have more than one website for accepting polyfills. What is the criteria, how to vet these websites? Jordan is maintaining a good website but no way to know if it is compliant 166 | - (Jordan) Thanks for making the time for this topic and giving me a chance to speak 167 | - I can talk about JS polyfills, cant speak for broader platform polyfills, core js and my package pass two tests, both are well maintained. Need to consider risk factors, high adoption 168 | - Criteria could include conformance, web platform tests, sufficient adoption, which could be tough to quantify. Also it could be the case of you know it when you see it. JS has less than 5 of us with packages that are well known. Having two choices is a good start. 169 | - (Ruth) Thanks Jordan for adding this topic to the agenda and for coming, thanks Jean-Yves. We need to be cautious of moving forward, thinking about who we include. We need to be mindful of what we need to maintain, and so I am inclined to start with two. Two that you mention is a good place to start. 170 | - Let’s start with JS 171 | - (Jean-Yves) Start with JS, yes. Decide which pages we include, criteria for which polyfill 172 | - (Vadim) Worth considering how we recommend including them, link to CDN, hotlinking from cdn (performance, security), 173 | - (Jordan) That is a complex question. npm package is/should be sufficient. MDN can avoid having to wade into that discussion, work you all do is hard enough 174 | - (Jean-Yves) To move forward on this, I'll add a discussion, criteria where and how to link, and invite people to the discussion 175 | 176 | ### How to get reviews on Yari PRs? (@teoli2003) 177 | 178 | - (Jean-Yves) Most small yari PRs sit idle. How can we streamline the process so that it is not too much work for the reviewers? 179 | - (Leo) Some of this relates to the build process, research, and rewrite. What we can do now - we've started working in sprints on the dev side. This will help us to look at consistent number of PRs to see what we need to prioritise. We do have some of these marked as priority, we need to carve out time. 180 | - What would help is to make clear in the PR body - whether it's just a content PR or you've fixed a macro, give the discussion link or provide sufficient context. 181 | - (Onkar) Is it possible for OWD or content folks to merge kumascript PRs? They dont break build. 182 | - (Leo) You can review and leave a comment 183 | - (Onkar) Could we get merge permissions? 184 | - (Leo) We do not want to do that, risk of breaking a build is high at night or on Fridays. Ping the core team. You can help with reviewing other PRs. If you have a list of small PRs that are easy to merge, send them our way. 185 | - (Onkar) Where? 186 | - (Leo) We are on Discord and GitHub 187 | - (Onkar) I need permission to be able to ping the core team on GitHub 188 | - (Jean-Yves) I’ll put together a list and will message on Discord, in the platform channel. Onkar can do the same. 189 | - (Ruth) I too will do the same with some of the work content team is waiting on 190 | - (Onkar) npm release of yari. Can we release it automatically at the end of the week? We used to do it after every PR earlier but that was too much. npm release is different from prod release. Last time we were waiting for a couple of days, there was a flaw. Can we automate npm release every weekend? 191 | - (Leo) Yes, it is frustrating to have to do it manually 192 | 193 | ## End of the topics and call 194 | 195 | - (Brian) Appreciate and thank you everyone who could make it. Until next time. 196 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Mozilla Public License Version 2.0 2 | ================================== 3 | 4 | 1. Definitions 5 | -------------- 6 | 7 | 1.1. "Contributor" 8 | means each individual or legal entity that creates, contributes to 9 | the creation of, or owns Covered Software. 10 | 11 | 1.2. "Contributor Version" 12 | means the combination of the Contributions of others (if any) used 13 | by a Contributor and that particular Contributor's Contribution. 14 | 15 | 1.3. "Contribution" 16 | means Covered Software of a particular Contributor. 17 | 18 | 1.4. "Covered Software" 19 | means Source Code Form to which the initial Contributor has attached 20 | the notice in Exhibit A, the Executable Form of such Source Code 21 | Form, and Modifications of such Source Code Form, in each case 22 | including portions thereof. 23 | 24 | 1.5. "Incompatible With Secondary Licenses" 25 | means 26 | 27 | (a) that the initial Contributor has attached the notice described 28 | in Exhibit B to the Covered Software; or 29 | 30 | (b) that the Covered Software was made available under the terms of 31 | version 1.1 or earlier of the License, but not also under the 32 | terms of a Secondary License. 33 | 34 | 1.6. "Executable Form" 35 | means any form of the work other than Source Code Form. 36 | 37 | 1.7. "Larger Work" 38 | means a work that combines Covered Software with other material, in 39 | a separate file or files, that is not Covered Software. 40 | 41 | 1.8. "License" 42 | means this document. 43 | 44 | 1.9. "Licensable" 45 | means having the right to grant, to the maximum extent possible, 46 | whether at the time of the initial grant or subsequently, any and 47 | all of the rights conveyed by this License. 48 | 49 | 1.10. "Modifications" 50 | means any of the following: 51 | 52 | (a) any file in Source Code Form that results from an addition to, 53 | deletion from, or modification of the contents of Covered 54 | Software; or 55 | 56 | (b) any new file in Source Code Form that contains any Covered 57 | Software. 58 | 59 | 1.11. "Patent Claims" of a Contributor 60 | means any patent claim(s), including without limitation, method, 61 | process, and apparatus claims, in any patent Licensable by such 62 | Contributor that would be infringed, but for the grant of the 63 | License, by the making, using, selling, offering for sale, having 64 | made, import, or transfer of either its Contributions or its 65 | Contributor Version. 66 | 67 | 1.12. "Secondary License" 68 | means either the GNU General Public License, Version 2.0, the GNU 69 | Lesser General Public License, Version 2.1, the GNU Affero General 70 | Public License, Version 3.0, or any later versions of those 71 | licenses. 72 | 73 | 1.13. "Source Code Form" 74 | means the form of the work preferred for making modifications. 75 | 76 | 1.14. "You" (or "Your") 77 | means an individual or a legal entity exercising rights under this 78 | License. For legal entities, "You" includes any entity that 79 | controls, is controlled by, or is under common control with You. For 80 | purposes of this definition, "control" means (a) the power, direct 81 | or indirect, to cause the direction or management of such entity, 82 | whether by contract or otherwise, or (b) ownership of more than 83 | fifty percent (50%) of the outstanding shares or beneficial 84 | ownership of such entity. 85 | 86 | 2. License Grants and Conditions 87 | -------------------------------- 88 | 89 | 2.1. Grants 90 | 91 | Each Contributor hereby grants You a world-wide, royalty-free, 92 | non-exclusive license: 93 | 94 | (a) under intellectual property rights (other than patent or trademark) 95 | Licensable by such Contributor to use, reproduce, make available, 96 | modify, display, perform, distribute, and otherwise exploit its 97 | Contributions, either on an unmodified basis, with Modifications, or 98 | as part of a Larger Work; and 99 | 100 | (b) under Patent Claims of such Contributor to make, use, sell, offer 101 | for sale, have made, import, and otherwise transfer either its 102 | Contributions or its Contributor Version. 103 | 104 | 2.2. Effective Date 105 | 106 | The licenses granted in Section 2.1 with respect to any Contribution 107 | become effective for each Contribution on the date the Contributor first 108 | distributes such Contribution. 109 | 110 | 2.3. Limitations on Grant Scope 111 | 112 | The licenses granted in this Section 2 are the only rights granted under 113 | this License. No additional rights or licenses will be implied from the 114 | distribution or licensing of Covered Software under this License. 115 | Notwithstanding Section 2.1(b) above, no patent license is granted by a 116 | Contributor: 117 | 118 | (a) for any code that a Contributor has removed from Covered Software; 119 | or 120 | 121 | (b) for infringements caused by: (i) Your and any other third party's 122 | modifications of Covered Software, or (ii) the combination of its 123 | Contributions with other software (except as part of its Contributor 124 | Version); or 125 | 126 | (c) under Patent Claims infringed by Covered Software in the absence of 127 | its Contributions. 128 | 129 | This License does not grant any rights in the trademarks, service marks, 130 | or logos of any Contributor (except as may be necessary to comply with 131 | the notice requirements in Section 3.4). 132 | 133 | 2.4. Subsequent Licenses 134 | 135 | No Contributor makes additional grants as a result of Your choice to 136 | distribute the Covered Software under a subsequent version of this 137 | License (see Section 10.2) or under the terms of a Secondary License (if 138 | permitted under the terms of Section 3.3). 139 | 140 | 2.5. Representation 141 | 142 | Each Contributor represents that the Contributor believes its 143 | Contributions are its original creation(s) or it has sufficient rights 144 | to grant the rights to its Contributions conveyed by this License. 145 | 146 | 2.6. Fair Use 147 | 148 | This License is not intended to limit any rights You have under 149 | applicable copyright doctrines of fair use, fair dealing, or other 150 | equivalents. 151 | 152 | 2.7. Conditions 153 | 154 | Sections 3.1, 3.2, 3.3, and 3.4 are conditions of the licenses granted 155 | in Section 2.1. 156 | 157 | 3. Responsibilities 158 | ------------------- 159 | 160 | 3.1. Distribution of Source Form 161 | 162 | All distribution of Covered Software in Source Code Form, including any 163 | Modifications that You create or to which You contribute, must be under 164 | the terms of this License. You must inform recipients that the Source 165 | Code Form of the Covered Software is governed by the terms of this 166 | License, and how they can obtain a copy of this License. You may not 167 | attempt to alter or restrict the recipients' rights in the Source Code 168 | Form. 169 | 170 | 3.2. Distribution of Executable Form 171 | 172 | If You distribute Covered Software in Executable Form then: 173 | 174 | (a) such Covered Software must also be made available in Source Code 175 | Form, as described in Section 3.1, and You must inform recipients of 176 | the Executable Form how they can obtain a copy of such Source Code 177 | Form by reasonable means in a timely manner, at a charge no more 178 | than the cost of distribution to the recipient; and 179 | 180 | (b) You may distribute such Executable Form under the terms of this 181 | License, or sublicense it under different terms, provided that the 182 | license for the Executable Form does not attempt to limit or alter 183 | the recipients' rights in the Source Code Form under this License. 184 | 185 | 3.3. Distribution of a Larger Work 186 | 187 | You may create and distribute a Larger Work under terms of Your choice, 188 | provided that You also comply with the requirements of this License for 189 | the Covered Software. If the Larger Work is a combination of Covered 190 | Software with a work governed by one or more Secondary Licenses, and the 191 | Covered Software is not Incompatible With Secondary Licenses, this 192 | License permits You to additionally distribute such Covered Software 193 | under the terms of such Secondary License(s), so that the recipient of 194 | the Larger Work may, at their option, further distribute the Covered 195 | Software under the terms of either this License or such Secondary 196 | License(s). 197 | 198 | 3.4. Notices 199 | 200 | You may not remove or alter the substance of any license notices 201 | (including copyright notices, patent notices, disclaimers of warranty, 202 | or limitations of liability) contained within the Source Code Form of 203 | the Covered Software, except that You may alter any license notices to 204 | the extent required to remedy known factual inaccuracies. 205 | 206 | 3.5. Application of Additional Terms 207 | 208 | You may choose to offer, and to charge a fee for, warranty, support, 209 | indemnity or liability obligations to one or more recipients of Covered 210 | Software. However, You may do so only on Your own behalf, and not on 211 | behalf of any Contributor. You must make it absolutely clear that any 212 | such warranty, support, indemnity, or liability obligation is offered by 213 | You alone, and You hereby agree to indemnify every Contributor for any 214 | liability incurred by such Contributor as a result of warranty, support, 215 | indemnity or liability terms You offer. You may include additional 216 | disclaimers of warranty and limitations of liability specific to any 217 | jurisdiction. 218 | 219 | 4. Inability to Comply Due to Statute or Regulation 220 | --------------------------------------------------- 221 | 222 | If it is impossible for You to comply with any of the terms of this 223 | License with respect to some or all of the Covered Software due to 224 | statute, judicial order, or regulation then You must: (a) comply with 225 | the terms of this License to the maximum extent possible; and (b) 226 | describe the limitations and the code they affect. Such description must 227 | be placed in a text file included with all distributions of the Covered 228 | Software under this License. Except to the extent prohibited by statute 229 | or regulation, such description must be sufficiently detailed for a 230 | recipient of ordinary skill to be able to understand it. 231 | 232 | 5. Termination 233 | -------------- 234 | 235 | 5.1. The rights granted under this License will terminate automatically 236 | if You fail to comply with any of its terms. However, if You become 237 | compliant, then the rights granted under this License from a particular 238 | Contributor are reinstated (a) provisionally, unless and until such 239 | Contributor explicitly and finally terminates Your grants, and (b) on an 240 | ongoing basis, if such Contributor fails to notify You of the 241 | non-compliance by some reasonable means prior to 60 days after You have 242 | come back into compliance. Moreover, Your grants from a particular 243 | Contributor are reinstated on an ongoing basis if such Contributor 244 | notifies You of the non-compliance by some reasonable means, this is the 245 | first time You have received notice of non-compliance with this License 246 | from such Contributor, and You become compliant prior to 30 days after 247 | Your receipt of the notice. 248 | 249 | 5.2. If You initiate litigation against any entity by asserting a patent 250 | infringement claim (excluding declaratory judgment actions, 251 | counter-claims, and cross-claims) alleging that a Contributor Version 252 | directly or indirectly infringes any patent, then the rights granted to 253 | You by any and all Contributors for the Covered Software under Section 254 | 2.1 of this License shall terminate. 255 | 256 | 5.3. In the event of termination under Sections 5.1 or 5.2 above, all 257 | end user license agreements (excluding distributors and resellers) which 258 | have been validly granted by You or Your distributors under this License 259 | prior to termination shall survive termination. 260 | 261 | ************************************************************************ 262 | * * 263 | * 6. Disclaimer of Warranty * 264 | * ------------------------- * 265 | * * 266 | * Covered Software is provided under this License on an "as is" * 267 | * basis, without warranty of any kind, either expressed, implied, or * 268 | * statutory, including, without limitation, warranties that the * 269 | * Covered Software is free of defects, merchantable, fit for a * 270 | * particular purpose or non-infringing. The entire risk as to the * 271 | * quality and performance of the Covered Software is with You. * 272 | * Should any Covered Software prove defective in any respect, You * 273 | * (not any Contributor) assume the cost of any necessary servicing, * 274 | * repair, or correction. This disclaimer of warranty constitutes an * 275 | * essential part of this License. No use of any Covered Software is * 276 | * authorized under this License except under this disclaimer. * 277 | * * 278 | ************************************************************************ 279 | 280 | ************************************************************************ 281 | * * 282 | * 7. Limitation of Liability * 283 | * -------------------------- * 284 | * * 285 | * Under no circumstances and under no legal theory, whether tort * 286 | * (including negligence), contract, or otherwise, shall any * 287 | * Contributor, or anyone who distributes Covered Software as * 288 | * permitted above, be liable to You for any direct, indirect, * 289 | * special, incidental, or consequential damages of any character * 290 | * including, without limitation, damages for lost profits, loss of * 291 | * goodwill, work stoppage, computer failure or malfunction, or any * 292 | * and all other commercial damages or losses, even if such party * 293 | * shall have been informed of the possibility of such damages. This * 294 | * limitation of liability shall not apply to liability for death or * 295 | * personal injury resulting from such party's negligence to the * 296 | * extent applicable law prohibits such limitation. Some * 297 | * jurisdictions do not allow the exclusion or limitation of * 298 | * incidental or consequential damages, so this exclusion and * 299 | * limitation may not apply to You. * 300 | * * 301 | ************************************************************************ 302 | 303 | 8. Litigation 304 | ------------- 305 | 306 | Any litigation relating to this License may be brought only in the 307 | courts of a jurisdiction where the defendant maintains its principal 308 | place of business and such litigation shall be governed by laws of that 309 | jurisdiction, without reference to its conflict-of-law provisions. 310 | Nothing in this Section shall prevent a party's ability to bring 311 | cross-claims or counter-claims. 312 | 313 | 9. Miscellaneous 314 | ---------------- 315 | 316 | This License represents the complete agreement concerning the subject 317 | matter hereof. If any provision of this License is held to be 318 | unenforceable, such provision shall be reformed only to the extent 319 | necessary to make it enforceable. Any law or regulation which provides 320 | that the language of a contract shall be construed against the drafter 321 | shall not be used to construe this License against a Contributor. 322 | 323 | 10. Versions of the License 324 | --------------------------- 325 | 326 | 10.1. New Versions 327 | 328 | Mozilla Foundation is the license steward. Except as provided in Section 329 | 10.3, no one other than the license steward has the right to modify or 330 | publish new versions of this License. Each version will be given a 331 | distinguishing version number. 332 | 333 | 10.2. Effect of New Versions 334 | 335 | You may distribute the Covered Software under the terms of the version 336 | of the License under which You originally received the Covered Software, 337 | or under the terms of any subsequent version published by the license 338 | steward. 339 | 340 | 10.3. Modified Versions 341 | 342 | If you create software not governed by this License, and you want to 343 | create a new license for such software, you may create and use a 344 | modified version of this License if you rename the license and remove 345 | any references to the name of the license steward (except to note that 346 | such modified license differs from this License). 347 | 348 | 10.4. Distributing Source Code Form that is Incompatible With Secondary 349 | Licenses 350 | 351 | If You choose to distribute Source Code Form that is Incompatible With 352 | Secondary Licenses under the terms of this version of the License, the 353 | notice described in Exhibit B of this License must be attached. 354 | 355 | Exhibit A - Source Code Form License Notice 356 | ------------------------------------------- 357 | 358 | This Source Code Form is subject to the terms of the Mozilla Public 359 | License, v. 2.0. If a copy of the MPL was not distributed with this 360 | file, You can obtain one at http://mozilla.org/MPL/2.0/. 361 | 362 | If it is not possible or desirable to put the notice in a particular 363 | file, then You may include the notice in a location (such as a LICENSE 364 | file in a relevant directory) where a recipient would be likely to look 365 | for such a notice. 366 | 367 | You may add additional accurate notices of copyright ownership. 368 | 369 | Exhibit B - "Incompatible With Secondary Licenses" Notice 370 | --------------------------------------------------------- 371 | 372 | This Source Code Form is "Incompatible With Secondary Licenses", as 373 | defined by the Mozilla Public License, v. 2.0. 374 | -------------------------------------------------------------------------------- /2024/2024-06-24/minutes.md: -------------------------------------------------------------------------------- 1 | # Minutes from MDN community meeting - 24th June 2024 2 | **Attendees:** Ruth John (@Rumyra), Chris Mills (@chrisdavidmills), Vadim Makeev (@pepelsbey), Pranshu Khanna (@pransh15), Dipika Bhattacharya (@dipikabh), Christine Belzie (@CBID2), Florian Dieminger (@fiji-flo), Claas Augner (@caugner), Florian Scholz (@elchi3), Brian Smith(@bmsith), Andi Piper(@argl), Onkar Ruikar(@OnkarRuikar) 3 | 4 | **Host:** Pranshu Khanna (@pransh15) 5 | 6 | ## Intro and overview 7 | 8 | [Pranshu] Welcome to the June community call. If you're not a part of our discord community, please join the MDN community. While you're in MDN spaces, make sure that you follow the Mozilla community participation guidelines. 9 | 10 | ## Team updates 11 | 12 | ### Project updates from the MDN team (@rumyra/@pransh15) 13 | 14 | [Ruth] Moving forward, we are planning to make community calls more focused. 15 | 16 | We'll have one set focused on content, community, and contributing and another set focused on product and engineering, eg, what's happening with platform rewrites. Community members can join ones they are interested in. 17 | 18 | We've also been talking about frequency of these calls and having some open office hours as well. Once we've made some decisions around that, we will communicate that. Am I right, Pranshu? 19 | 20 | [Pranshu] Yes, that's correct. Please share if you any suggestions around office hours and content and community/product/engineering calls. We're very open to feedback and make this experience work for you. 21 | 22 | [Chris] So, whatever the frequency ends up being, you're just gonna alternate between Product/Engineering and content? That's cool and makes sense. I also like the idea of having office hours. 23 | 24 | [Ruth] Yes, the idea is to have something less official so people can join and talk about things they're working on or want to talk about. 25 | 26 | ### Content workshop update (@rumyra) 27 | 28 | [Ruth] We ran a couple of content workshops at the end of Q1. I have been slowly putting together a plan for the content architecture (excluding the UI side of it). I'm putting together a presentation this week. I will hopefully present on Thursday and get some feedback. I can then share the presentation with the community members and get more feedback as to what a good plan would be for content. I just wanted to give you an update that there is progress happening and that it hasn't fallen by the wayside. 29 | 30 | ### GitHub Week - 8th July (@rumyra) 31 | 32 | [Ruth] The content and community team at Mozilla will be having a GitHub week. We try to do these once every 6 months. We'll be doing a bit of spring cleaning of our GitHub repositories, reviewing some of our processes, and looking at the pain points again. 33 | 34 | We won't accomplish everything in a week, but it's a space for us to be able to focus specifically on GitHub organization and management and other tasks that we don't tend to do in our day-to-day. 35 | 36 | We'll make an announcement in GH Discussions, probably this week, with a few goals and what to expect. We will keep everybody informed with the things that we are actually doing. 37 | 38 | [Chris] Is this just related to closing issues or is it a wider variety of things? 39 | 40 | [Ruth] We will do some triaging and we will look at stale things. I think with Pranshu starting last month, it's a really good opportunity to look at the processes, the way that we track things, what our projects look like, and teams and access rights. All those aspects need to be sorted and reviewed periodically to make sure they're working for everybody. 41 | 42 | [Onkar] Is it like inviting students to work on small tasks? 43 | 44 | [Ruth] Not this one. This one will include the core team, the writers and Pranshu. We repeat this exercise every six months for iterating over and improving our processes and guidelines. 45 | 46 | [Chris] That's great. It sounds super positive because I've noticed that OWD folks have been doing quite a bit of issue triaging recently. Some of our volunteers like Josh Chen have also done loads recently and closed a lot of stale issues. 47 | 48 | I'm wondering whether it would be worth spending some time figuring out a way to highlight good first issues. This would help with regular flow of volunteer contributions but will also be useful for events like Hacktoberfest. 49 | 50 | [Ruth] Yeah. Our previous community manager set up a project specifically for contributors. It would be a good idea to revisit that and see whether we can improve it. We also want to improve the workflow between contribution docs on MDN and what we have on GitHub because the flow is a little bit disjointed at the moment. 51 | 52 | [Pranshu] Also reviewing PRs is important. If a new wave of contributors comes in, it will be overwhelming for everyone with the number of reviews. It might just be easier to review the processes right now before these students and contributors come in. 53 | 54 | ### German locale project (@caugner) 55 | 56 | [Claas] In April, we shared that we are experimenting with the German locale on MDN. We've made some progress. We're waiting for a partner to come back to us before announcing it on GitHub. 57 | 58 | What I can share now is that we ran a survey in the beginning of June, targeting users whose browsers indicated German as their preferred language. In the survey, we asked their preferred locale if German locale was available, their proficiency in German and English, and what they think is important in the German locale on MDN. 59 | 60 | We got a lot of responses. In fact, 3% of all users who saw the survey responded, which indicates to us that the German-speaking community is quite active and engaged. This is useful for such an experiment. Of those who responded to the survey, 90% were native German speakers, and 25% indicated that they would mostly use the German locale. This is interesting considering that those people were on a non-German Page. One of the explanations is that 33% of the survey respondents indicated that they're not fluent in English. 61 | 62 | So these are the people who already visit MDN and if MDN is available in German, other people who are not comfortable visiting a page in English might additionally come to MDN. This is one of the reasons why we wanted to run this experiment - to see if we can attract a new audience, mainly German-speaking people, that is not comfortable in reading documentation in English. 63 | 64 | Keeping in mind the general problems that machine translations have, we will use LLM-based translations because they are much more consistent and coherent compared to traditional machine translations. 65 | 66 | We saw respondents who were interested in testing to ensure that the quality of the translations is good enough. If the quality of translation is good, we will go live. 67 | 68 | This is the reason we asked for priorities and let the respondents rate them. What was rated the most important was technical correctness. Then the consistency of technical terms, followed by up-to-dateness, completeness, and comprehensibility. This confirms our plan to translate all of MDN to German, so all of our 12,000 pages. The source for these will be markdown files. They would be open for edits. The idea is that as changes happen in the English locale, they would be synchronized to that. 69 | 70 | The community will review those changes to help us increase the quality of translations. We know that machine translations, and more generally, German translations of technical documentation, don't often read great. But what's most important is that the people who feel more comfortable reading in German find this helpful and useful. And obviously avoiding any important issues introduced in the translation. 71 | 72 | So our next steps are to have an internal test environment, and we will then share the first version of the German locale with 300 volunteers who are interested in testing, and then we will iterate with those. Once we come to the conclusion that the quality is good enough, we'll launch this in production. This might be around September - the launch in production. Any questions? 73 | 74 | [Onkar] Is Google Translate helpful for translating pages? 75 | 76 | [Claas] That's a good question. We see in our server logs that some requests from Google can be stale, so we know that some folks are using Google Translate. Although we don't have data on this, I assume it's not the best experience. It's probably also delayed. We could have asked survey respondents, for those using Google Translate to browse MDN. But they would not have seen the survey. 77 | 78 | About the second question about converting images to translated versions: one of the aspects we asked in the survey was to rate the necessity to translate graphics. It rated second to last, just before translating code examples, so we don't think it's that important. But yeah, it has to be taken into consideration. Now we have some charts that have English terms but we are already seeing those in some of the locates that we have. 79 | 80 | Does that answer your question? Maybe you're referring to the shared-assets repository where the idea is to also store the original versions like SVGs or Mermaid files. It would be possible to use that to generate translated images. But based on the results of the survey, this is not as important and would rather come later down the line as a nice-to-have. 81 | 82 | [Chris] One thing I just thought I'd bring up, though I'm not sure how helpful it will still be because it was quite a few years ago, is that when I worked at Mozilla on MDN and I did a survey specifically asking folks that used MDN and for whom English is not their 1st language, to compare an existing manually translated page that I thought looked fairly reasonable, with one that was done on the fly using Google Translate and probably another service. 83 | 84 | The idea was to see if they thought the Google Translate version was usable in any way or more usable than the manually translated versions on average. I seem to remember that on average, people said that while it will obviously nice to have perfectly translated pages, but that the Google Translated ones weren't too bad and they would be serviceable if that was what was available. Of course, that was mainly in Latin-based languages such as those in Europe. For languages like Chinese and Japanese, the answer was a big fat no; it was very, very different. 85 | 86 | I'm not sure if that's still helpful or if you'd be able to find that data still hanging around somewhere. I know that Ruth has a giant document like repository somewhere of all my old stuff from when I worked there. 87 | 88 | [Claas] It's interesting that you mentioned other languages. We went with German because Germany is the country from where we get the most visits and most users, where we don't have a native language available. So it makes sense to test with that. The second aspect is that we had the German locale for 15 years, between 2011 and 2022, so it's a little more natural to to bring that back; it was retired in 2022 because it was incomplete and outdated. We would solve this with an automated machine translation approach. And if successful, we can think about extending it to other languages. For example, I think the next language on the list could be Italian or Indonesian. 89 | 90 | Regarding the question from Florian about localizing strings in the UI, this was also one of the aspects we considered. It ranked 7th out of 9 in terms of priority. It is not the most important thing to tackle, but it's definitely on our agenda. We have some plan to work on the front end later this year or early next year after the rewrite that Florian is working on. We definitely will look at making it possible to localize the UI. 91 | 92 | [Vadim] I have a feeling that the list of priorities will change from locale to locale. For German speakers who are into web development, they just have to know some basic English to understand the UI, but for other other locales, we might have to translate the UI as well. 93 | 94 | [Claas] Absolutely. That's a good point. I think for other languages, we might use a similar approach, that is conducting a survey first to see the priorities and to understand if it makes sense, and at some point, it may not make sense or we won't be able to maintain high-quality translation. At some point, machine translations might not be good enough quality for certain languages. 95 | 96 | [Florian] I just wanted to add that translating the UI is on our agenda. Macros are coming sooner. We're planning to move that into content. Hopefully that will help with getting them translated because a lot of them are translated in only a handful of languages. And yeah, same for side bars. All of this will be up and coming in the next couple of weeks. 97 | 98 | [Pranshu] Awesome. 99 | 100 | ## Contributor updates 101 | 102 | [Pranshu] Next up, we don't have any contributor updates, but I would still like to remind you that we have a space for contributors updates. We're looking to feature you in the community call for the amazing work that you do. 103 | 104 | ## Questions and discussions 105 | 106 | ### External examples (@rumyra) 107 | 108 | [Ruth] External examples. We have a lot of repositories, a lot of examples, and a lot of JSFiddles. We do want to start conforming these examples in the long term. We would like to integrate the playground a little bit better into the site. So initially it'll be really good if any contributor wants to pull out any small example from external example repositories, ones that can be live samples and only in one or two pages. If they cross five pages, we'll keep them separate for now. 109 | 110 | You're more than welcome to take them out of the repositories and put them into content because that would be helpful. It will also be helpful with live samples. Just FYI, when they're moved, they can be deleted from the repositories. 111 | 112 | And then we will come up with a plan on how to actually structure bigger examples being a part of the repository. As soon as we know more about the plan, which I'm working on in July, I will share it. 113 | 114 | So maybe the problem is if we don't remove them from the repository, we will not know which ones need to be moved later, which might make things difficult. 115 | 116 | [Onkar] Maybe we need to create a spreadsheet. 117 | 118 | [Ruth] Yes, let's create a spreadsheet for each 119 | 120 | [Claas] One thing we've done in the past is that when we delete one from content, we create an issue, and have a checklist for each locale. 121 | 122 | [Florian] In early July, I plan to start working towards tooling. A lot of that will be much easier in the new system. I'm happy to help leveraging and making it easier with the new build system like scraping out external links, which will be much easier and faster. No need to dig into it, but I published the first pre-release earlier today. 123 | 124 | You can check it out if you want to get a rough idea of what's up and coming, but the polishing is missing. Chunking through macros and broken links is so much easier if your iteration cycle is like a second instead of a few minutes. I hope that will help fixing a lot of these and resolving other issues. 125 | 126 | [Ruth] Thanks, Florian. That sounds really good. We're excited 127 | 128 | Onkar, so for examples, I think you're right, we need to create a spreadsheet. We will think about that ASAP and review what external examples we want to keep because they're not all going to be live examples. Once we've done that, we will have a list of the ones that can be moved and we can tell translated content team. 129 | 130 | [Pranshu] Should we create an issue or discussion for this so that it's easier for everybody to see? 131 | 132 | [Ruth] Let us do the audit first and then we'll create a discussion which can link to the spreadsheet with the items we want people to help us with. We need to have a list first that contributors can refer to and take tasks from. 133 | 134 | [Pranshu] Awesome! Looking forward to some progress in the next call. 135 | 136 | ### Is there an objective around closing issues? (@rumyra) 137 | 138 | [Ruth] I had a question around closing issues because we have contributors closing lots of issues. I found out the answer earlier, which is, there is no objective. People just wanted to come in and close loads of issues. So I guess the thing to mention here is that you're gonna see a lot of activity over the next few weeks because some of our contributors are trying to reduce that issue count, which is fine and cool. 139 | 140 | ### Inline icons [discussion](https://github.com/orgs/mdn/discussions/654#discussioncomment-9746229) (@rumyra) 141 | 142 | [Ruth] The inline icons discussion on code. This is probably something most relevant to you, Onkar. This is the idea of putting experimental and deprecated icons throughout the site, not just in the sidebars, but making sure they're clear in our reference pages and things like that. 143 | 144 | I want to see the vote on the discussion to see how maintainers feel this should be done. But I don't think at this time it's a good idea for us to implement it because of the platform changes that are coming. So we will be updating macros, but in about three months, that'll all be moot because we'll be doing it in a completely different way. 145 | 146 | [Florian] Yeah, I can also add that when I redid the sidebars, I'm adding more icons where we previously did not have them. I need to figure out if we want to keep them. 147 | 148 | At the same time, it's quite easy because there's a global post-processing of all links where we have this context so just injecting them is straightforward. 149 | 150 | [Ruth] Yeah, that's what I'm trying to say. I want people to vote. But no implementation will happen at this time. 151 | 152 | [Florian] I was wondering about one case I ran into and that I was not aware of — some guide pages have a feature status 153 | 154 | [Ruth] Yes, because they've got a BCD key. We're using the BCD key for the baseline status. 155 | 156 | #### Other topics 157 | 158 | [Onkar] I need a review on a pull request. I think we can take that offline. 159 | 160 | [Christine] How does someone become a maintainer on MDN? 161 | 162 | [Ruth] It's usually someone who has been around for a long time and has been helping with pull request reviews, issue triaging, and those kind of activities. We consider it on a case-by-case basis. 163 | 164 | [Pranshu] We don't have fixed guidelines yet. I will be building those, so I will have a clear response for you in a few weeks. For now, just get involved, get your hands dirty with issues, PRs, and help us out, just like Onkar, Chris, and other folks here. After some time, I'll add you as a maintainer, it's as simple as that. I'll reach out to you, and we'll take it offline. No worries. 165 | 166 | [Onkar] I'm being asked to convert an image to an SVG, but I'm not well-versed with SVG. How should I proceed? Can we have a tool hosted somewhere to convert PNG to SVG for other contributors? 167 | 168 | [Brian] I can help you with that, Onkar. I've been doing a lot of the HTTP diagrams in the last couple of weeks, mostly redoing them from scratch, which has been okay if they're mermaid diagrams, because then we have the source for them afterwards. Otherwise, if they're just boxes and lines, they're pretty easy to recreate, so I can give you a hand with that if you want. 169 | 170 | [Pranshu] Awesome. We don't have anything else on the agenda. One last important update that I wanted to share was that our next community call will be on the 23rd of July, 2024. If you haven't guessed it yet, MDN will turn 19. I hope to see all of you there. 171 | -------------------------------------------------------------------------------- /2024/2024-03-27/minutes.md: -------------------------------------------------------------------------------- 1 | # Minutes from MDN community meeting 27th March '24 2 | 3 | **Attendees:** 4 | Brian (@bsmth), Vadim (@pepelsbey), Dipika (@dipikabh), Florian D (@fiji-flo), Onkar (@OnkarRuikar), Holee (@hochan222), Eric Meyer (@meyerweb), Claas Augner (@caugner), Andi (@argl), Ruth John (@rumyra), Arkanit, Jean-Yves (@teoli2003), Estelle (@estelle), Florian S (@Elchi3), Mahi 5 | 6 | **Host:** Brian (@bsmth) 7 | 8 | ## Intro & overview of agenda 9 | 10 | (Brian) 11 | Welcome, great to see everyone including new faces. 12 | Agenda: 13 | 14 | - new Footer that's on the website. 15 | - community participation guidelines (CPG) 16 | - What's changed on Discord and Matrix 17 | - The new blog post out 18 | 19 | ## Team updates 20 | 21 | - The Matrix room and the "# general" channel on Discord are now bridged. 22 | It's a bi-directional chat. So messages posted in the MDN matrix room are posted in the "# general" channel on Discord and vice versa. 23 | We're trying to make sure that people on Matrix are not left out because we tend to be on Discord quite a lot. 24 | - There's a new blog post out about Interop: https://developer.mozilla.org/en-US/blog/interop2023-mdn-doc-updates/ 25 | 26 | ### Footer 27 | 28 | [Ruth John] 29 | We've updated the MDN article footer based on user feedback, shifting more from decisions based on personal preferences to data-driven choices. 30 | This involves a simple feedback form (on-page) asking users if they found the content helpful, so we're working more towards improving content quality through user insights. 31 | Although there's no freeform text field feedback (for qualitative data), we're exploring other methods to gather this. 32 | 33 | Since launching, we've seen an average 70% positive sentiment in March. 34 | We will analyze this data by larger sections before tackling individual pages, combining it with other metrics like page views to inform updates or removals. 35 | This is an ongoing project, and we're not taking specific requests yet for the data as we focus on actionable tasks. Any questions? 36 | 37 | [Estelle] Q: Is there any way for people outside of Mozilla to see the feedback that is coming through? 38 | 39 | [Ruth John] 40 | No, the requests will come in, I know. That's why I would ask you not to ask me for that just yet, I want to be able to analyze the data first and be able to answer follow-up questions, which we'll surely have. 41 | 42 | [Estelle] 43 | Side note: I really miss the edit button in the Footer and I realized that I can just click on the "view on GitHub" and then edit. 44 | 45 | [Ruth John] 46 | Yeah, we went back and forth on this a lot of times. There were 3 links all to exactly the same thing in the old footer and it just it didn't make any sense. 47 | 48 | ### Community Participation Guidelines 49 | 50 | [Brian Smith] 51 | I'll talk about Mozilla's Community Participation Guidelines (CPG) — this is super important for us, especially because we're on GitHub all day and working closely with the community. 52 | Here's a link to [Community Participation Guidelines (CPG)](https://www.mozilla.org/en-US/about/governance/policies/participation/) for anyone interested. 53 | The CPG guides how we all behave on MDN's GitHub repositories, ensuring everyone follows a shared code of conduct. 54 | 55 | There's a useful GitHub repo called [mozilla/inclusion](https://github.com/mozilla/inclusion) that has all the info on CPG, how to report issues, blog posts about it, and enforcement details. 56 | 57 | For everyone: If you see something off on GitHub, like in comments or pull requests, you can report it using the 3-dot menu. 58 | This alerts all the admins of the repo. 59 | When a report comes in, we check it out right away to decide what to do. Often, it's clear what needs to happen, like hiding spam or blocking a bot. 60 | But we always look at each case individually. 61 | If it's not always straightforward, we follow a more detailed (and thorough) formal process, which involves the Community Participation team for an official investigation. 62 | 63 | The goal is to keep the community safe and respectful. 64 | If someone breaks the rules, we might have to take serious steps, but banning is an absolute last resort. 65 | We prefer to resolve issues quickly with reminders of how to behave so everyone can keep participating. 66 | 67 | If reporting through GitHub isn't your thing, you can also email CPG reports directly. 68 | It's all private and confidential. 69 | If you need to chat about something, just reach out. We're here to help. 70 | 71 | [Estelle] 72 | Any rules for false reports, a situation on Mastodon where a hijabi person was targeted with reports due to Islamophobia. 73 | The reporter gets blocked in such cases. 74 | 75 | [Brian Smith] 76 | Yes abusing the reporting process is indeed a violation, consequences can vary, but it's abuse. Not sure of the specific language in CPG for that. 77 | 78 | [Onkar] 79 | Is this information linked from the main MDN website? 80 | 81 | [Brian Smith] 82 | The community pages on MDN have links, we might link directly to the Mozilla/inclusion repo. 83 | 84 | [Estelle] 85 | Opened a PR to add more links to the CPG for better visibility. 86 | 87 | [Brian Smith] 88 | Appreciated! 89 | 90 | ## Discussions & questions 91 | 92 | ### How to use inline status macros 93 | 94 | **Discussion:** https://github.com/orgs/mdn/discussions/654 95 | 96 | [Onkar] 97 | We put these macros in two spots: up top in the header and inline right next to each property in the content. 98 | Recently, we pulled the inline macros because of some issues, but now we're debating if we should add them back for properties marked as experimental. 99 | It's handy because people don't have to scroll all over to find out if something's experimental (to BCD table or to top of page with banner) 100 | 101 | We've got two ways to go about it: put them everywhere like a 'christmas tree' or just up top like a 'traffic light'. 102 | Putting them inline makes it super obvious and cuts down on the need for scrolling or checking other sections. 103 | If the property is experimental, the question is, do we tag each value with an inline badge? 104 | It looks repetitive, but it's immediately noticeable to people without referring to other parts of the page. 105 | 106 | [Estelle] 107 | At first, I was skeptical, thinking, "This is going to be a massive headache," but then I realized it's not so bad because a bot can handle adding and removing these experimental inlines, making it less of a maintenance nightmare. 108 | So, the burning question is, should we, or should we not add the experimental inline, considering it's automated? 109 | This could make it significantly easier for readers to spot experimental features without extra effort. 110 | 111 | [Brian Smith] 112 | I can also leave an opinion on the GitHub discussion if that also helps, but just my initial thoughts were that this a bit too much to start inlining per CSS property value in the content. 113 | I wonder if there's something in between where if we say in the banner that if it's not experimental (property) but there are parts of it which are (values). 114 | 115 | [Onkar] 116 | If the property is **not experimental** but the some of **the values are** then then we do tag them with the inline badges. 117 | But the question is about if the property itself is experimental, should we tag each value with an inline badge? 118 | It looks repetitive and verbose, but we have found that it is really visible to people and they do figure out if this is experimental or not. 119 | So this way they notice it quickly. And they don't necessarily refer to BCD tables or scroll up to see the header macros. 120 | 121 | 'christmas tree' is the current implementation. So if we now change the strategy then we'll have to educate the readers as well. 122 | That this is how it is. So there are a bunch of pros and cons stated in the discussion. 123 | Please go through the discussion and please add your comments. 124 | 125 | [Ruth John] 126 | This would help for experimental values. So the property itself is not experimental, but sometimes we get new values on the property and their class is experimental. 127 | 128 | [Estelle] 129 | If we're putting experimental on a value when the property is not experimental, then someone can automatically see that this value is experimental. 130 | But if the property itself is experimental, then they would have to actually go to the top or go to the bottom of the page. 131 | To realize it's experimental and not realize that every single value is experimental. 132 | So if every single value is experimental we probably should put it someplace in the values area that it is experimental. 133 | Because they do get that information sometimes but not if the property itself is experimental. 134 | 135 | [Brian Smith] 136 | I wonder could that be a display fix instead where where we don't actually edit in the content, but Yari shows something for experimental values of an experimental property. 137 | 138 | [Estelle] 139 | So we the thing to realize, cause I thought this was the worst idea ever until Onkar explained that a bot does it. 140 | So we don't have to maintain it. 141 | 142 | -- off topic -- 143 | 144 | [Onkar] 145 | There's an API example in chat, open that. The page header is experimental because the accelerometer is experimental API. 146 | And if you scroll down each member of the API like constructor and instance property they are all marked with experimental inline badge (the flask icon). 147 | Do we add a flask icon for each member of the API or the CSS property if the property itself is experimental? 148 | 149 | This question arose because we have decided different strategy for secure context macros. 150 | And Will objected saying that we should adopt this same strategy for inline status macros as well. 151 | 152 | Right now we are using the 'christmas tree' strategy. 153 | Will says that if we could use the same strategy that we decided for the Secure context macros. 154 | 155 | [Ruth John] 156 | It's difficult 157 | 158 | [Dipika] 159 | Yeah, I think, on initial thoughts, it seems that it might be a good idea to replicate whatever the BCD is showing. 160 | So if the BCD is showing the status as experimental. Instead of having to scroll between values and BCD table. 161 | If it's shown also next to the value. Then it would be helpful. 162 | 163 | [Onkar] 164 | Yes. It certainly is. 165 | 166 | [Brian Smith] 167 | Okay, then maybe the next step for us is to just record that on the GitHub discussion. 168 | Do you need votes, right? Whether you go for the 'traffic light' or the 'christmas tree'? 169 | 170 | [Onkar] 171 | Yeah, please do go through Pros and Cons. 172 | 173 | [Estelle] 174 | Class asked a question or made a comment in chat, which I guess we should clarify, which is "the bot that would add the inline experimental macros, is that on Yari is that done in the Content"? 175 | 176 | [Ruth John] 177 | Content. 178 | 179 | [Estelle] 180 | Class does that change your comment? 181 | 182 | [Claas Augner] 183 | Hmm. So this implies that. The information about whether something's experimental is actually added to the content. 184 | I wonder if there would also be a way to get what in the Markdown is enriched when rendering just like we run with BCD tables. 185 | 186 | [Ruth John] 187 | Yes, there is a whole document and project about automating things like this so we don't have to, but the way to Onkar's implemented is he's running an automation in the content repo. 188 | 189 | [Claas Augner] 190 | Okay. 191 | 192 | [Ruth John] 193 | And he's checking against BCD key, he's checking for the experimental flag and then he's automatically adding a markdown macro into the content, which isn't terrible. 194 | We don't have to author it, which is kind of key here. 195 | Maintenance is definitely a concern. We did decide with secure context though to only put the banner on the interface page. 196 | 197 | [Estelle] 198 | Secure context is a bit different because in secure context everything is served over HTTPS nowadays. 199 | 200 | [Ruth John] 201 | Oh, it's more that secure context is required to use the API. 202 | 203 | [Onkar] 204 | So if we are going to use 'christmas tree' for a status macros, then we should use the same strategy for secure context macros as well. 205 | For sake of keeping the things the same. 206 | If you use different strategy for each macro then there will be confusion. 207 | And we so whatever we decided for secure context we haven't implemented in content repo. 208 | So there is still chance that we could revert the decision on secure context macro. 209 | 210 | [Ruth John] 211 | I'm having a think about it. I don't know I'm gonna come to any conclusions in this call. 212 | 213 | [Estelle] 214 | There are guidelines now to discussions as to how to move them forward. 215 | So Onkar; as the driver of this discussion, if you can summarize what was said in the meeting in the discussion and then if anyone has any opinions that they haven't shared, if you can put them directly in the discussions. 216 | Cause the discussion is supposed to be the source of truth for any decisions that we come up with. 217 | 218 | [Onkar] 219 | My question is now I have conveyed this, are you going to put your comments in the discussion itself for are we going to conclude in the next community meeting? 220 | 221 | [Ruth John] 222 | We can conclude it in the discussion. 223 | 224 | ### Indicators and banners 225 | 226 | [Brian Smith] 227 | Next up, indicators and banners. This one is from Estelle, is it? 228 | 229 | [Estelle] 230 | I didn't know if there was a discussion, but if we could open up a discussion, point into the PRD, we can have the conversation in the Google doc and then once we have all the feedback in the Google Doc, port it over to the GitHub discussion. 231 | 232 | [Ruth John] 233 | This is a project that we want to go over sometime later in the year to sort out this banner mess basically. 234 | What I will do (I'm not necessarily against capturing the timeline of this in discussion) I think everybody has commented on the Doc I created now. 235 | Next up is to go through that Doc again and create a proposal. 236 | Once I've done that, we can start a discussion and say "this is the proposal" and discuss the thoughts behind it. 237 | Does that work? 238 | 239 | I would also say regarding the timeline for this; there's no urgency. 240 | We also have to wait for Baseline to be on more pages before we can actually make a good educated decision, if we try to do that before then I think we'll be doing the work twice. 241 | 242 | [Estelle] 243 | There's about 6 different conversations about indicators and banners. So there's already all these discussions going on. 244 | 245 | [Ruth John] 246 | They're all captured in the Doc. 247 | I'd rather wait until we had a proposal and how we're going to move forward and then open the discussion and in all the related discussions, say 'Let's go and look at this discussion because this is our proposal'. 248 | 249 | [Estelle] 250 | I would love to at some point close all those other discussions and move on 251 | 252 | [Ruth John] 253 | Yeah, it's next on the list. 254 | 255 | ### Writing Guidelines and Glossary 256 | 257 | **Discussion:** https://github.com/orgs/mdn/discussions/661 258 | 259 | [Brian Smith] 260 | The sections Glossary and Writing Guidelines living on islands. A bit more of a visibility to be recognized. 261 | 262 | [Ruth John] 263 | I think where we link to the Writing Guidelines, where we link to the Glossary, are 2 separate discussions to be had because they're very separate things. 264 | In the discussion, Will very rightly points out that if we put Writing Guidelines at the top anywhere, our users are just going to think it's "how to write code" guidelines. 265 | So that's not something that we are going to do. 266 | 267 | Glossary; there are design and product considerations to find out how everyone feels about putting Glossary in that dropdown. 268 | It seems to be the consensus that people want it there. 269 | 270 | As far as the Writing Guidelines go. 271 | There's a lot of talk about where to put links and all the rest of it and the changes to be made. 272 | The key one for me was: when you click on contributing, you get taken to contributing.md on GitHub and then all the links in there move you back onto MDN. 273 | And then this kind of opens a can of worms about where we put the contribution guidelines but I think they're too linked to the Writing Guidelines to really separate them. 274 | 275 | And we can't have the Writing Guidelines elsewhere because they contain so much styling from MDN itself that we'd lose all of that. 276 | 277 | [Onkar] 278 | So I think it is better to move whatever there is in the GitHub `.md` files about contributing to the rendered pages and we host everything like other MDN docs. 279 | So, basically all the README files on GitHub (CONTRIBUTING.md), we move it into the content and host it. 280 | 281 | [Ruth John] 282 | Yeah, I think that we could stop the user flow from going to GitHub and back again. 283 | We need to keep repository specific stuff with the repository though. 284 | 285 | That was a conscious decision that we made when we were doing all the contribution docs because otherwise we're gonna have 2 places to list our 50 repositories and put all the guidelines for all of them on MDN. 286 | I don't think that's MDN content. I think that's repository-specific. 287 | 288 | So some stuff is still going to have to stay on repositories, READMEs, CONTRIBUTING.md, things like that. 289 | 290 | [Onkar] 291 | We can have minimal stuff on the repository and most of the checking out, the git stuff, all the small small things about using it. 292 | 293 | [Ruth John] 294 | I think there is some "how to use GitHub" stuff in both places, we should review it again. 295 | We can review the contributing.md on content that we link to, revise that and make sure that when people do click on Contributing they're taken still to MDN rather than back and forth. 296 | 297 | [Estelle] 298 | The other thing we can do is since it's all markdown; point to the blob on GitHub which is actually then automatically rendered so it's just written in one place. 299 | And where you link to it if you're in GitHub you can link to it from GitHub like from the README file. 300 | 301 | [Ruth John] 302 | We don't want to duplicate content and have to keep it up to date in 2 places. 303 | So that does help solve that problem, definitely. 304 | Unless you have macros. I think we can avoid them in our contributing docs. 305 | 306 | [Estelle] 307 | I mean, there'll be the sidebar macro, but that would be about it. 308 | 309 | [Ruth John] 310 | Yeah, I think that's a blocker. As far as some of the suggestions on where this link should go, I think we carry that on in the discussion. 311 | Some of the suggestions already in there crossing over with some work that Anuja, our UX designer is currently doing on site-wide navigation. 312 | But things like adding Writing Guidelines specifically unobtrusively is okay. 313 | I think if we have a markdown page that links to all the different things on MDN, then we can harness that and we can link to that. 314 | 315 | [Brian Smith] 316 | Anything else? Anyone? 317 | 318 | [Onkar] 319 | No, just contribute to the discussions. If you put your comments over there, then we know that it is making progress. 320 | 321 | [Estelle] 322 | I guess what you're also saying is we should pull out Glossary from the Writing Guidelines discussion and create a separate discussion for Glossary. 323 | 324 | [Ruth John] 325 | I think maybe that's a good idea. Cause I think that user flow for the guidelines and where it comes from where it goes to and everything is probably gonna take over from Glossary discussion. 326 | There'll be 2 conversations happening at the same time. 327 | 328 | [Onkar] 329 | Okay, I'll create a separate discussion. 330 | 331 | [Ruth John] 332 | Thanks. 333 | 334 | [Estelle] 335 | Thank you for all your contributions Onkar 336 | 337 | [Brian Smith] 338 | Yeah, absolutely. 339 | 340 | [Onkar] 341 | My pleasure. 342 | 343 | ## Closing discussions 344 | 345 | [Brian Smith] 346 | If there's anything else that you want to discuss, talk about, bring up. Now's a good time. 347 | 348 | [Estelle] 349 | I went through a bunch of discussions. So I might have hit you up asking you a question to move your discussion forward. There's a lot of discussions that have been opened since like 2022. 350 | 351 | [Ruth John] 352 | That's great Estelle, thank you. I did start trying to do this a couple of months back but got caught up in discussions. 353 | 354 | ### Playground feedback 355 | 356 | [Onkar] 357 | Yeah, I have one issue that has been bugging me. In the playground, there is a Reset button. 358 | And when we click on the Reset button, it wipes out everything. I think it should bring back the original code. 359 | 360 | [Brian sharing screen] 361 | 362 | [Florian Dieminger] 363 | Background color is my favorite. 364 | No, that's a good point. It should be a "clear" button. That's what it does. 365 | And I do see the need for a "reset". 366 | 367 | [Onkar] 368 | If I've modified the code and hit Reset but now I can't get the original code 369 | 370 | [Florian Dieminger] 371 | Yeah, the original code is not stored anywhere. We should at least change it to "clear". 372 | So it's clear to everyone what this button does. It doesn't reset. 373 | 374 | I think it was done prior to the integration, so the thing was to reset the current state. 375 | If you click on refresh, like if you come to the playground from the top, you have a fresh thing. 376 | 377 | And reset like get it back to be clean. But it should should be clear. And I do see the need for that. 378 | 379 | To get back to the example. 380 | We have enhancing the playground in our goals. 381 | And we'll actually extend it quite a bit and move to having a proper Service worker implementation. 382 | 383 | I think we can do the "clear" rather soon because that's like UI renaming. 384 | But to actually store the context you came with like the original example and reset to that original state. 385 | Probably have to wait until we do the second iteration of the playground, which will be midsummer, something like that. 386 | 387 | [Onkar] 388 | In the share URL, you are already capturing the code, right. Could you just pick up the code and repopulate the editor? 389 | 390 | [Florian Dieminger] 391 | No, the permalink is quite different. 392 | That actually creates Gist on GitHub where the code is stored and we don't have this for a live sample. 393 | So the live samples are stored in local local storage. 394 | I can look if I can see an easy way to restore that state but right now we don't keep history. 395 | I mean that's the issue; if you modify the code, we override the current state and we don't have a history in the state. 396 | 397 | [Onkar] 398 | So quick solution is to rename the button to clear, right? 399 | 400 | [Florian Dieminger] 401 | Yes, and I think Control C in the editors works and maybe there is a way for me to actually make this to go in the editors to the initial state. I need to look into that. 402 | Thanks for bringing it up. I'm sorry for the confusion with that naming. 403 | 404 | [Onkar] 405 | Thank you. 406 | 407 | [Brian Smith] 408 | It was great seeing everybody. Really appreciate all of you joining. You know where to catch us. 409 | I'm looking forward to the next one. And have a lovely evening and we'll see you next time. 410 | --------------------------------------------------------------------------------