├── .github ├── labels.json └── workflows │ └── set-default-labels.yml ├── CODE_OF_CONDUCT.md ├── README.md ├── about.md ├── assets ├── browser-support-spec-info.png ├── pab-group-photo-feb-2020.jpg └── pab-group-photo-jan-2019.jpg ├── meeting-notes ├── 2018-01-notes.md ├── 2018-03-notes.md ├── 2018-07-notes.md ├── 2019-01-notes.md ├── 2019-06-notes.md ├── 2020-02-notes.md ├── 2020-05-notes.md ├── 2020-06-notes.md ├── 2020-07-notes.md ├── 2020-12-notes.md ├── 2021-01-notes.md ├── 2021-02-notes.md ├── 2021-03-notes.md └── ExecSummary_PAB_Jan.2018.md ├── membership.md └── webforall-demos ├── mdn-dir.html ├── mdn-input.html └── mdn-lang.html /.github/labels.json: -------------------------------------------------------------------------------- 1 | [ 2 | { 3 | "name": "good first issue", 4 | "color": "028c46", 5 | "description": "A good issue for newcomers to get started with." 6 | }, 7 | { 8 | "name": "help wanted", 9 | "color": "028c46", 10 | "description": "If you know something about this, we would love your help!" 11 | }, 12 | { 13 | "name": "needs info", 14 | "color": "028c46", 15 | "description": "This needs more information to review or act on." 16 | }, 17 | { 18 | "name": "needs triage", 19 | "color": "028c46", 20 | "description": "Triage needed by staff and/or partners. Automatically applied when an issue is opened." 21 | }, 22 | { 23 | "name": "expert help needed", 24 | "color": "028c46", 25 | "description": "This needs more information from a subject matter expert (SME)." 26 | }, 27 | { 28 | "name": "idle", 29 | "color": "028c46", 30 | "description": "Issues and pull requests with no activity for three months." 31 | }, 32 | { 33 | "name": "on hold", 34 | "color": "028c46", 35 | "description": "Waiting on something else before this can be moved forward." 36 | }, 37 | { 38 | "name": "for later", 39 | "color": "028c46", 40 | "description": "Not planned at this time." 41 | }, 42 | { 43 | "name": "needs content update", 44 | "color": "028c46", 45 | "description": "Needs update to the content to support this change." 46 | }, 47 | { 48 | "name": "chore", 49 | "color": "028c46", 50 | "description": "A routine task." 51 | }, 52 | { 53 | "name": "enhancement", 54 | "color": "028c46", 55 | "description": "Improves an existing feature." 56 | }, 57 | { 58 | "name": "bug", 59 | "color": "c05964", 60 | "description": "Indicates an unexpected problem or unintended behavior." 61 | }, 62 | { 63 | "name": "wontfix", 64 | "color": "c05964", 65 | "description": "Deemed to be outside the scope of the project or would require significant time and resources to fix." 66 | }, 67 | { 68 | "name": "effort: small", 69 | "color": "866dc1", 70 | "description": "Task is a small effort." 71 | }, 72 | { 73 | "name": "effort: medium", 74 | "color": "866dc1", 75 | "description": "Task is a medium effort." 76 | }, 77 | { 78 | "name": "effort: large", 79 | "color": "866dc1", 80 | "description": "Task is large effort." 81 | }, 82 | { 83 | "name": "p0", 84 | "color": "6e8bc1", 85 | "description": "Urgent. We will address this as soon as possible." 86 | }, 87 | { 88 | "name": "p1", 89 | "color": "6e8bc1", 90 | "description": "We will address this soon and will provide capacity from our team for it in the next few releases." 91 | }, 92 | { 93 | "name": "p2", 94 | "color": "6e8bc1", 95 | "description": "We want to address this but may have other higher priority items." 96 | }, 97 | { 98 | "name": "p3", 99 | "color": "6e8bc1", 100 | "description": "We don't have visibility when this will be addressed." 101 | } 102 | ] 103 | -------------------------------------------------------------------------------- /.github/workflows/set-default-labels.yml: -------------------------------------------------------------------------------- 1 | name: set-default-labels 2 | on: [workflow_dispatch] 3 | 4 | jobs: 5 | set-default-labels: 6 | uses: mdn/workflows/.github/workflows/set-default-labels.yml@main 7 | with: 8 | target-repo: "mdn/pab" 9 | should-delete-labels: true 10 | -------------------------------------------------------------------------------- /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 | 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. 9 | 10 | 16 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # MDN Web Docs Product Advisory Board 2 | 3 | This is the GitHub repo for the [MDN Web Docs](https://developer.mozilla.org/) Product Advisory Board (MDN PAB). 4 | The PAB is a collaborative group of tech organizations and leaders who together advise and make suggestions for the future of MDN, as well as, in many cases, make direct contributions to MDN's code or content. 5 | 6 | ## Meetings 7 | 8 | You can find notes from our meetings in the [meeting-notes](meeting-notes) directory: 9 | 10 | - [March 2021 video call](meeting-notes/2021-03-notes.md) 11 | - [February 2021 video call](meeting-notes/2021-02-notes.md) 12 | - [January 2021 video call](meeting-notes/2021-01-notes.md) 13 | - [December 2020 video call](meeting-notes/2020-12-notes.md) 14 | - [July 2020 video call](meeting-notes/2020-07-notes.md) 15 | - [June 2020 video call](meeting-notes/2020-06-notes.md) 16 | - [May 2020 video call](meeting-notes/2020-05-notes.md) 17 | - [February 2020 F2F meeting, Mozilla Toronto](meeting-notes/2020-02-notes.md) 18 | - [June 2019 F2F meeting, Mozilla Berlin](meeting-notes/2019-06-notes.md) 19 | - [January 2019 F2F meeting, Google New York](meeting-notes/2019-01-notes.md) 20 | - [July/August 2018 F2F meeting, Microsoft Seattle](meeting-notes/2018-07-notes.md) 21 | - [January 2018 F2F meeting, Google London](meeting-notes/2018-01-notes.md) 22 | - [March 2018 video meeting](meeting-notes/2018-03-notes.md) 23 | 24 | ## Other links 25 | 26 | - [PAB Charter & Membership](./membership.md) 27 | - [Current PAB Members](./about.md) 28 | - [PAB Membership Application](https://www.surveygizmo.com/s3/4024118/MDN-Advisory-Board-Application) 29 | -------------------------------------------------------------------------------- /about.md: -------------------------------------------------------------------------------- 1 | # MDN Product Advisory Board 2 | 3 | MDN Web Docs is a trusted source of technical documentation for web developers, built on an open-source web development documentation platform based on wiki technology, which allows virtually anyone to write and edit content. 4 | 5 | The MDN Product Advisory Board's mission is to build collaboration between Mozilla, its documentation team, and the key collaborating organizations that help the MDN community collectively maintain MDN as the most comprehensive, complete, and trusted reference documenting the most important aspects of modern browsers and web standards. 6 | 7 | The Product Advisory Board provides advice from external leaders, helping MDN in its mission to provide unbiased, browser-agnostic documentation of HTML, CSS, JavaScript, and Web APIs to ensure that it's the top reference for standards-based web development. 8 | 9 | ## Members 10 | 11 | Current members of the MDN Product Advisory Board are: 12 | 13 | - **Reeza Ali** 14 | Principal Program Manager, Microsoft Edge Developer Experiences 15 | - : Reeza Ali is a Program Manager at Microsoft, who leads the content strategy on the Edge developer relations team. Throughout his Microsoft career, he's been a strong advocate for developer success. Over the past 7+ years, he's led several web content documentation teams and projects at Microsoft. He believes that product content and learning experiences play a pivotal role in creating successful outcomes for developers. He's passionate about content strategy, technology, and technical communication. 16 | - **Sukriti Chadha** 17 | Product Manager, Spotify 18 | - : Sukriti Chadha is a mobile developer-turned-product manager at Spotify where she leads efforts in cross-platform accessibility and developer experience on mobile. She also serves as an Invited Expert at the [W3C WCAG (Web Content Accessibility Guidelines) Working Group](https://www.w3.org/WAI/standards-guidelines/wcag/) and the [Mobile Accessibility Task Force (MATF)](https://www.w3.org/WAI/standards-guidelines/mobile/), where she contributes to industry guidelines for accessible web and mobile applications. She built a new way of making data visualization accessible for visually impaired users, and [open-sourced the Android solution in 2019](https://developer.yahoo.com/blogs/612790529269366784/). Sukriti's product role entails managing developer experience roadmaps, automated testing, and embedding accessibility in the product lifecycle. 19 | - **Hermina Condei** 20 | Head of Product CE, Marketing Operations, Mozilla 21 | - : Hermina Condei leads product management and engineering for MDN Web Docs and platform engineering for SUMO at Mozilla. Over the past years, she's driven company-wide projects focused on access and identity management for employees and the community. She also led the product team in the **Open Innovation Group**, with a focus on managing internal and external stakeholders for the team's portfolio of projects. 22 | - **Dominique Hazael-Massieux** 23 | W3C Web Technology Expert including [Telecommunications Vertical champion](https://www.w3.org/Telco/), [Web Real-Time Communications Working Group](https://www.w3.org/groups/wg/webrtc), [Device and Sensors Working Group](https://www.w3.org/das/) 24 | - : Dominique Hazael-Massieux is part of the W3C staff, leading W3C efforts in developer relations. Dom has been working for W3C since 2000, and in addition to devrel, is currently involved in the standardization of WebRTC, device APIs and WebVR. 25 | - **Brian Kardell** 26 | Developer Advocate, Igalia 27 | - : Brian is a Developer Advocate at Igalia. He participates in W3C where he is Igalia's Advisory Committee Representative and participates in various working groups and community groups. He also has represented the Open JS Foundation there. 28 | - **Eric Meyer** 29 | Developer Advocate, Igalia 30 | - : [Eric](https://meyerweb.com/) ([@meyerweb](https://mastodon.social/@Meyerweb)) is an [author](https://meyerweb.com/eric/writing.html), speaker, blogger, sometimes teacher and consultant, Developer Advocate at [Igalia](https://www.igalia.com/), and co-founder of [An Event Apart](https://aneventapart.com/). He's been working on the Web since 1993 and still finds it deeply compelling. 31 | - **Laura Morinigo** 32 | Web Developer Advocate, Samsung 33 | - : Laura is a software developer, advocate, and mentor. She is passionate about sharing her knowledge and connecting with different tech communities worldwide. Thanks to her contributions, she has been recognized as a Google Developer Expert and a Woman Techmakers Ambassador. As a mentor, she helped startups participating in accelerator programs like Google Launchpad and the World Food Programme by the United Nations. Currently, she is a web developer advocate for Samsung Internet. She contributes to web standards and spreads the word about advanced web features, helping developers create great and more inclusive web apps. 34 | - **Sheila Moussavi** 35 | Principal, Bocoup 36 | - : Sheila is a Principal at [Bocoup](https://www.bocoup.com/about), where she leads a team working on web standards like HTML and CSS, and no-code programming tools like [Scratch](https://www.scratchfoundation.org/). Sheila oversees Bocoup's web standards strategy at the W3C, and is passionate about building more equitable spaces in web standards and stronger connections between the standards process and web developer education. Throughout her career in tech (and previously in health equity and disability justice), she has been focused on cultivating effective, justice-oriented organizations and work spaces. 37 | - **Robert Nyman** 38 | Global Lead for Programs & Initiatives, Web Developer Relations, at Google 39 | - : Robert Nyman is the Global Lead for Developer Feedback & Communities, Web Platform at Google. In his role, he works to make the web the best platform for developers. Prior to Google, Robert was a technical evangelist at Mozilla, focused on the Open Web and the company's various products and initiatives. He lives in Stockholm, and has a passion for traveling and meeting people. He claims the title of "Most Well-Traveled Speaker" on Lanyrd, having presented in 42 countries. 40 | - **Kyle Pflug** 41 | Senior Program Manager, Microsoft Edge Developer Experiences 42 | - : Kyle Pflug is a Program Manager at Microsoft, leading developer relations and community outreach for Microsoft Edge. Over the past five years, he has worked to champion web developer and partner perspectives within Microsoft. He is passionate about making the web more inclusive and accessible to developers across platforms and devices. 43 | 44 | **MDN Product Advisory Board Alumni:** 45 | 46 | - Ali Spivak, Okta 47 | - Daniel Appelquist, Samsung 48 | - Jory Burson, Bocoup 49 | - Joe Medley, Formerly Google 50 | - Meggin Kearney, Google 51 | - Erika Doyle Navara, Microsoft 52 | - Patrick Kettner, Microsoft 53 | - Travis Leithead, Microsoft 54 | - Chris Mills, Mozilla 55 | - Kadir Topal, Mozilla 56 | 57 | ## See also 58 | 59 | - [Product Advisory Board Charter & Membership](./membership.md) 60 | -------------------------------------------------------------------------------- /assets/browser-support-spec-info.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mdn/pab/b485871f2138c5034cb92c112c75300d63baf537/assets/browser-support-spec-info.png -------------------------------------------------------------------------------- /assets/pab-group-photo-feb-2020.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mdn/pab/b485871f2138c5034cb92c112c75300d63baf537/assets/pab-group-photo-feb-2020.jpg -------------------------------------------------------------------------------- /assets/pab-group-photo-jan-2019.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mdn/pab/b485871f2138c5034cb92c112c75300d63baf537/assets/pab-group-photo-jan-2019.jpg -------------------------------------------------------------------------------- /meeting-notes/2018-01-notes.md: -------------------------------------------------------------------------------- 1 | # Meeting notes — MDN PAB F2F meeting, London Google Office, Jan 10-12 2 | 3 | Too long? You can also read an [Executive summary](ExecSummary_PAB_Jan.2018.md) of the January notes. 4 | 5 | ## Attendees 6 | 7 | Ali Spivak (Mozilla), Kadir Topal (Mozilla), Chris Mills (Mozilla), Robert Nyman (Google), Meggin Kearney (Google), Dominique Hazael-Massieux (W3C), Erika Doyle Navara (Microsoft), Daniel Appelquist (Samsung), Patrick Kettner (Microsoft). 8 | 9 | 10 | ## Day 1 11 | 12 | ### Topic: MDN 2017 numbers in review 13 | 14 | **ACTION** [Kadir]: For metrics, comparison US vs. Europe as a whole would be helpful 15 | 16 | Q: Can we get numbers of % of developer population per country? 17 | A: There really aren’t reliable sources, we generally look at what the big survey companies provide for total developer population, then look at the percentage of Stack Overflow users who identify as web developers (roughly 16-18m estimate) 18 | Could use more, better sources for developer population. If anyone has suggestions we’d love to all use the same metrics (no real answer here) 19 | 20 | Q: Does the MDN team know what are the growth opportunities across the globe? 21 | A: We do have data on this we’ve connected for MDN, it’s a sliding scale as far as need of English. Some populations are more comfortable working in English (e.g. Germany, Scandinavian countries, India) than others (France, Spain, China). We do know contributions are proportional to traffic, as a general rule. The way MDN backend is designed there isn’t a robust review system for localization 22 | 23 | * **ACTION** [Ali] Add localization as a working session topic to dive deeper tomorrow 24 | * **ACTION** [Kadir]: Get metrics by language as opposed to by country 25 | 26 | Q: What are the most trafficked content areas on MDN? 27 | A: JavaScript is the most trafficked part of MDN 28 | 29 | * Not just web developers look at the docs, e.g. node links to MDN 30 | * CSS growth - combination of moving samples to the top of pages & CSS Grid launch and docs being written by Rachel Andrew 31 | * HTML traffic growth mostly came from updating input type 32 | * Learning Area on MDN, launched last year, driven growth (over 1 million per month visitors). 33 | * Code schools didn’t link to MDN because the topics were too advanced, now they are linking more to the learning content (over 80% increase) 34 | 35 | Q: How do you talk to contributors? 36 | A: Don’t have built-in tools for communications in the MDN wiki platform, users have to find and then explicitly join a mailing list to participate. Creates a gulf between contribution (editing the wiki) and community (people communicating). Purely technical issue/resource constraints, we could add these features to the platform but don’t have the resources (and not sure the ROI is there). 37 | 38 | Q: Do we survey contributors through their accounts (email)? 39 | A: Yes, but it requires legal permission to email account holders. Been a year+ since we last did a contributor survey. 40 | 41 | Q: Do we know specific things that drive traffic increases? 42 | A: We do plot out things like releases, etc over the charts (e.g. redesign) but it can be difficult to pinpoint a specific cause. 43 | 44 | ### Topic: [Looking forward at 2018](https://docs.google.com/presentation/d/1WqknZ4jvNItlXHQbehh1GDuL_Z0bL7jjY3U4tDI3a_U/edit#slide=id.p) 45 | 46 | Shifting the mission statement a bit to help people figure out what they might want to know, as opposed to them coming to MDN looking for a specific thing. Board members generally agreed that they want wording to stress cross-platform or cross browser as opposed to “delightful” which sounds like marketing. 47 | 48 | * **ACTION** [ali]: Add working session for MDN mission statement wording. 49 | 50 | Theme for 2018: Build more functionality for action oriented (like to play with the code to learn) vs. concept oriented (reading). For most of our history, MDN primarily catered to concept oriented developers (more reading oriented), last year (and this one) have been working on rolling out samples on top and interactive examples to help action-oriented developers. 51 | 52 | Q: Is there a difference between use case oriented and action oriented? 53 | A: Action oriented vs. conceptual are how they learn, not the specific reason they are coming. Addressing use cases is a new content area, one there is a lot of potential for. 54 | 55 | Theme for 2018: Search Results/SEO. 80% of MDN traffic comes through search, improving results pages will have huge impact.Last year did a SEO audit and set of experiments to see what has impact to improve search. Page load time improvements also will help - MDN servers are on the west coast, performance impact. Adding CDN is a 2018 projects, in Q1 we’re doing a performance audit. In 2017, moved MDN to AWS, that project took our 2 backend devs all year. 56 | 57 | Build samples into structured data for search results? 58 | 59 | * **ACTION** [ali]: Add structured data in search results to working session list… 60 | 61 | Theme for 2018: Making it easier for users to browse and learn if they don’t know the specific things they are looking for (also includes use case browsing). Don’t yet have a specific plan or set of topics for how we will do this but it is an area we want to explore 62 | 63 | Theme for 2018: Making structured data available off of MDN (e.g. compatibility data). 64 | 65 | Meggin is working on making a compatibility data extension for Chrome, similar to the [one built by a contributor for Firefox](https://addons.mozilla.org/en-US/firefox/addon/compat-report/). Need to figure out how to track success for this type of data. Maybe getting consent/approval for sharing usage data with Mozilla could help here, or we could look at coverage via specific tools. Will most likely require more qualitative data. Can see extension users, could use it at least for getting started. Visual studio has strong analytics. 66 | 67 | Links in Firefox DevTools give a read more link to MDN when you get a JS error, which drives a lot of traffic. JS error pages are some of the most read docs on MDN. Same for Google, when “test your code” pages link to docs they drive a lot of traffic. 68 | 69 | Theme for 2018: Sustainability 70 | MDN has 50-60% traffic and contribution growth with the same Mozilla staff & variable program budget. Mozilla as a whole is looking at ways to get revenue outside of search in Firefox, MDN specifically is an area of high interest because it is a valuable resource for developers. We’re specifically looking for ways to fund MDN beyond what Mozilla invests today - will have a working session to deep dive on this. 71 | 72 | For platform sustainability, potentially move to GitHub as the backend for all of MDN, including content. There are obviously challenges to this - potentially lock people out because there is a much higher bar to contributing if you have to learn Git/GitHub. Google has hybrid model w/ GitHub, can talk more in deep dive. We have experimented with moving some parts of MDN content to GitHub. Compatibility data, interactive samples, and macros/scripts are currently on. We are seeing growing contribution in these areas. Noted that Mozilla has a lot of success with community around RUST; can use as a learning exercise. University connections form PAB members could lead to good potential community member sourcing. 73 | 74 | ### Topic: How MDN works 75 | 76 | MDN work structure 77 | 78 | ~10 Mozilla paid staff, 3 developers, product manager, content lead/writer, 3 content writers, project manager. 79 | ~ 1M$US budget 80 | Use budget for contractors, events, travel, etc. 81 | 82 | Do have some contracted workers: content writers for specific skill sets we don;t have on staff and can’t find volunteers for, graphic design, UX. 83 | 84 | On a day to day basis, staff uses a “agile” type process. Work gets done in 12 day sprint with 3 days at the end to plan for the next sprint, do a retrospective, and have a breather day. Sprint goals get defined every 3 weeks based on OKRs, with a prioritizing process. 85 | 86 | Each sprint aims at delivering value (as - deployed on mdn), but features typically require several sprints for completion. 87 | 88 | Also have an [opportunity assessment process](https://docs.google.com/a/mozilla.com/presentation/d/1YlEk6d-SNTv_cUqWA443Zxhn9JjH2QMtIu0L8eOG_98/edit?usp=sharing). The [submission form](https://goo.gl/forms/E9WylsuHPgrSod4I2) is open to anyone, but mostly used by MDN contributors, also sometimes by other Mozilla employees. There is a [weekly meeting](https://docs.google.com/document/d/1QXOFKsymw5N2KqO1s3LNOygQ7fA347Fp-vCgWqqZuoY/edit#) to discuss new opportunities and work on the backlog. The rule and goal is to keep the backlog of opportunities (that need to be assessed) to 20 items max. 89 | 90 | The PAB input process is expected to be rolled into this existing system - with the Mozilla team owning the prioritization of the requests. 91 | One difficulty is how to include external contributors (especially volunteers) in sprints (mostly an issue for content, rather than the platform). 92 | 93 | * **ACTION** [kadir] Share current opportunity backlog 94 | 95 | User Testing: Haven’t really released the outcomes of user testing, post out summary of results publicly, don’t do in-depth white paper… more information and raw data to the board to get a second view on the results. Do remote user testing every sprint, recruit on MDN via banner, 5-6 people per session (over that on prototypes becomes redundant). Would be interesting to get beyond the self-selected target audience being recruited from MDN. There is a screener in the current process. Want to be able to do it outside of/beyond MDN. Aware of selection bias of using MDN audience, would like to get beyond it. Basically free to do it. 96 | Share sprint model with Google team 97 | 98 | ### Topic: Content Roadmap 99 | 100 | Q: Progressive Web Apps - question on where would this content live? 101 | A: There is an App area on MDN, originally for Firefox OS Apps but it has morphed into general information on web apps. PWA docs would fit here. Currently have a contractor writing tutorials on PWA’s. Having shared definition and documentation on how to implement PWA’s across platforms/vendors would be helpful. 102 | 103 | Question for the PAB: we have ongoing questions about Frameworks - how do things like react fit into modern web development, since many teams are only using react or other frameworks? Deliberately haven’t touched frameworks in the MDN docs, specifically might make sense learning area. Most frameworks already have their own pretty good sets of documentation, don’t want/need to document on MDN. Simply ignoring that the frameworks exist isn’t really the best option. 104 | 105 | PAB conclusion: Introduction to the main concepts would be in scope for MDN. Set up a hard and fast rule - whatever is pure web platform only on MDN, with the exception of learning area which can be more pragmatic. Need to maintain clear distinction between reference and opinionated how to’s, tutorial, learning content. Descriptive vs. normative. 106 | 107 | Q: On MDN, how would users know the materials are up to date 108 | A: We need to have the internal resources/processes to do this. 109 | 110 | Q: (following up): What is the long-term cost of content - creating it but also maintenance. 111 | A: Don't have a formula for determining this. Look into creating a model for it, maybe something like the number of edits over time - content lifecycle. Would be really useful to have this. Lifetime cost lifetime value, could look at timeframe. 112 | 113 | Learning documentation on testing would be really useful- there is a module in the learning area on tools and testing (and it does cover proprietary stuff). 114 | 115 | Priorities not included in the current roadmap: 116 | 117 | Web Bluetooth, Midi going to be priorities for Samsung. Midi specifically isn’t documented on MDN - need to unlink from whether it is supported in Gecko. 118 | 119 | * **ACTION** [Chris]: Review adding Web Bluetooth, Midi to content roadmap 120 | 121 | Note: Messages on reference pages need to have a clearer definition of what “on standards track” means, and also generally what warrants which warnings on a page - should finesse it a bit. 122 | 123 | * **ACTION** [Chris]: Follow up on reconsidering what page banners we show on MDN 124 | 125 | Web Components for Microsoft. Probably be outside of the quarterly meetings, give a heads up about priorities. 126 | 127 | * **ACTION** [Patrick]: Do some triage and get back to us. 128 | 129 | Chrome status - can filter by usage, filter most used API’s for prioritization (chromestatus.com) 130 | 131 | ### PAB Work & Process: 132 | 133 | How do we manage PAB work? 134 | 135 | Question for PAB: Should members come to each meeting with content priorities prepared for discussion? 136 | PAB Decision: Agreed to align content topic areas at quarterly meeting, members will bring priorities. 137 | 138 | Question for PAB: Should we create a PAB repo on MDN GitHub and track work there. Use to publish meeting notes, etc. 139 | PAB Decision: yes, we will do this. 140 | 141 | * **ACTION** [Dom] Create a (temporary) repo for the PAB and invite everyone on the board 142 | * **ACTION** [ Kadir]: migrate temp PAB repo to main MDN. 143 | 144 | MDN team is currently investigating different tools for sprint planning that are closer to the MDN workflow (instead of spreadsheets and kanban-type board). Currently don’t use GitHub for process management. 145 | 146 | Making sure that what comes out of the PAB is rolled into the working cycle of MDN, specifically the opportunity reviews and work prioritization. 147 | 148 | Covering changes to the quarterly priorities that came out of the PAB meeting as a summary could address most people’s concern about the openness of the board 149 | 150 | Also make sure that there is a way for people to surface things they want the board to review/cover/provide feedback on. 151 | 152 | * **ACTION** [ali] Write up an Exec summary of changes or proposals in addition to detailed meeting notes. 153 | * **ACTION** [ali]: provide a mechanism for MDN team/contributors to submit asks for the board ahead of meetings. 154 | 155 | ### PAB Logistics: 156 | 157 | Will compile a set of action items from each time we meet, review each quarter. Final action of each meeting will be distilling action items and assigning owners. 158 | 159 | Keep the action items in backlog for tracking purposes. 160 | 161 | It would be good if there is a process for getting involved in the actual work, which is beyond the scope of the board. For example, an extension could be a personal project vs an MDN platform project. Document in the repo itself what the purpose is and the boundaries are. 162 | 163 | Link to the projects. 164 | 165 | List of lists in the repo 166 | 167 | ## Day 2 - Working Sessions: Friday, January 12,2018 168 | 169 | We did unconference-style breakout sessions on day 2, looking to discuss some of the issues that we thought needed more work. Also reserved time at the end of the day to plan next round of meetings. 170 | 171 | The following sessions were prioritized & scheduled: 172 | 173 | * Browser compat data, with some notes about Chinese browsers. Led by Robert, 1h 174 | * Move MDN's backend functionality to GitHub. Led by Kadir + Meggin, 30 mins. 175 | * Data outside of MDN, including devtools, lighthouse, search result rich snippets. Led by Meggin, 45 mins. 176 | * Membership and revenue. Led by Ali, 45 mins. 177 | * Wordsmithing the MDN mission statement. Led by Kadir, 30 mins. 178 | * Running a joint Webdev conference. Led by Robert, 15 mins. 179 | * W3C and MDN coordination, including W3C explainers, requirements process, notification of spec changes. Led by Dom, 1hr 180 | 181 | The sessions we agreed would be good to potentially do later on are: 182 | 183 | * EPUB docs. Led by Dom, 30 mins 184 | * Localization and translation. Led by Kadir, 30 mins 185 | * MDN as a source of developer feedback. Led by Chris, 30 mins 186 | * Process for technical reviews, including using Google's process of notifying engineers when chrome status is updated. 187 | * User and contributor surveys 188 | * Web for all, best practices process and approach 189 | * Style guides and page titles 190 | * Landing page updates, to allow you to find APIs by task when you don't know what you're looking for 191 | 192 | ## Working Session: Compatibility Data 193 | 194 | ### Update on Chinese browsers by Robert 195 | 196 | Robert have an update on a meeting between MDN (Jean Yves Perrier, Florian Scholz) and Google (Robert Nyman, Philip Jägenstedt (Foolip), Michael Yeung) 197 | 198 | There are some obvious browsers to talk to, e.g. qq, uc 199 | 200 | Worked with Alexis from CanIUse to get Chinese browser support implemented there. It's available now. 201 | 202 | To do full testing, you generally need Chinese phones and browsers available from their app stores. 203 | 204 | Chinese vendors want to feature more in the global space 205 | 206 | Foolip mentioned confluence, a google project to get compat data sorted out. This is like a lighter version of web platform tests, with easier to interpret data. 207 | 208 | Foolip and other google colleagues are going to China soon to talk to them. They will see what data and hooks are available. Also see what they do in their browser — they tend to base their browsers on Chromium, but then do lots of customization, rip out stuff they don't like, etc. The standards support could be markedly different to regular Chrome or Opera. Dom said there had been also talks between W3C China and Chinese browsers vendors. 209 | 210 | * **ACTION** [Kadir/Robert] — see if the people who work on confluence/WPT could output the data in a useful format. 211 | 212 | ### Browser compat data 213 | 214 | MDN Browser Compatibility Data requires a lot of manual labor, especially when adding more browsers. Would like to work out an automation system based on Web platform tests (WPT) and other data sources, and then fix the problems using manual work afterwards. Patrick noted there are A LOT of tests in there, and it would be challenging to see how the test results could be turned into useful data for putting on MDN. 215 | 216 | We want to migrate all the compat data on MDN to machine-readable JSON on GitHub 217 | 218 | We are currently 40% there (HTML, HTTP, JS built-ins all done, CSS mostly done). The large part — WebAPIs — is still mostly not done. 219 | 220 | Original MDN data is hand-written HTML tables, and there are just too many inconsistencies to automate the process of getting them into a database, so it all has to be manual. 221 | 222 | Dan - in the spirit of not wanting to set up a conflict between MDN and caniuse, could we set up links from the MDN tables to the equivalent caniuse page? 223 | 224 | Kadir - ideally we would all eventually just use the same data. It is factual, right? Patrick - yes, but there are opinions on either side in some cases. Even so, it would be good to try to rally around a single source of truth. 225 | 226 | Robert - if confluence could be a useful bridge between MDN and WPT, this would be a good thing. 227 | 228 | Patrick - confluence seems to be meant for browser to browser data, rather than to developers , but it could still be useful. 229 | 230 | Kadir - caniuse could use the MDN BCD to construct their data. We couldn't do it the other way round, as MDN is way more granular. 231 | 232 | Ali - MDN's focus should be on maintaining good data, although we are dogfooding it in MDN compat tables; other people can build other tools based on it. dogfooding needed to build trust. We need a useful feedback mechanism too, on MDN pages and extensions based on the data. For example, simple thumbs down widget that people can click if data they see is wrong. 233 | Ask for the board. For each release we update content and compat data based on new releases. Could we get all browsers to do this? 234 | 235 | Mozilla: well duh 236 | 237 | Chrome: mostly done already 238 | 239 | Edge: Yep, we can, Erika said they were looking into a system to do it, e.g. automated as much as possible. 240 | 241 | Samsung: Probably, need to discuss with team 242 | 243 | * **ACTION** [everyone]: Everyone to check to see what their orgs are actually doing. Implement a system to do this if not. Will report back on this next meeting. 244 | * **ACTION** [ Dan, Patrick/Erika, Meggin]: Designate a point person for compat data pull request reviews 245 | * **ACTION** [Kadir]: Create an opportunity assessment item for adding a feedback mechanism on BCD tables so someone can easily report incorrect data. 246 | 247 | Q: How do we deal with data aggregation? E.g. if a single subfeature is not supported, does it count as the whole feature not being supported? This kind of summary support info is what we want to display on the support summary banners we have been thinking of adding to MDN. 248 | 249 | We should look to define guidelines on what "supported" means. What partial means, etc. 250 | 251 | Core uses, edge case uses? Needs user testing/research? 252 | 253 | * **ACTION** [Kadir] : Share these guidelines with the group (if they exist), get more feedback. 254 | * **ACTION** [PAB follow up, Kadir]: Work out what we need to put in the support summary banners. Write plan, do user testing, etc. 255 | 256 | Noted that few people know or care about specific browser version numbers. People just want to know if they can use it now, if they need a polyfill for browser y, etc. Compatibility data should ideally address this, but also provide detail. 257 | 258 | Ali mentioned that we are doing a Hack on MDN session in Paris in March, working on BCD. It would be great to have as many PAB folks there as possible. Or as least joining in remotely, or multiple office hosting simultaneously. 259 | 260 | Kadir had another ask - we have a PR model for the BCD. Currently only MDN team members can review PRs, but it would be great to have other PAB members and their teams help too. 261 | 262 | Dom made the point that we could check which browser data a PR changes with a GitHub hook, then add tags and assign reviews as appropriate. Prefer if we can flag PR for each browser and get a point person to look at flagged items. 263 | 264 | **ACTION** [Kadir]: Look at how to do this 265 | 266 | ## Working Session: Wordsmith MDN mission statement 267 | 268 | Start: "provide people with the information they need and teach them what they need to know to build delightful experiences on the open web." 269 | 270 | We shouldn't say "browser", as this leaves out things like WoT, Node, etc. 271 | 272 | Provide and teach are somewhat redundant 273 | 274 | Should we say developers? No, as it cuts out other web creatives, eg designers 275 | 276 | * Other suggested words: Inform, guide, teach, lead 277 | * Inform and guide go well together 278 | * Cross platform 279 | * Reference and opinions 280 | * Delightful - no, as this implies UX, awesome, etc. 281 | * Good, Great? Usable? Accessible? First class? Splendid, superb, effective, powerful 282 | 283 | Finish: "Inform and guide people with the most comprehensive information they need to build first class, cross-platform experiences on the open web." 284 | 285 | Plus also provide a definition of first class. 286 | 287 | ## Working Session: Moving MDN's backend functionality to GitHub 288 | 289 | ### Pros 290 | 291 | * Community Engagement (e.g. people can track their MDN contributions, see what they've done eaily, put it on their CV/Resumé). 292 | * Simplify contribution model? 293 | * Removes anxiety about editing pages - changes not being available immediately...better curated. 294 | * PR model allows/enforces reviewing, gets rid of spam. 295 | * Integration with tooling (e.g. issue flagging) 296 | * Easy cross-talk/linking between MDN and other related repos, etc. W3C/WHATWG. 297 | * Discoverability 298 | 299 | ### Cons 300 | * 3rd party dependency. What happens for example if someone buys GitHub or they go out of business? We would need a contingency plan, and develop a relationship with GitHub. 301 | * Raises the bar for casual contributors — might make them less likely to contribute. 302 | * A lot more work needed to get changes published; having to review every change? We could have auto merge for trusted writers 303 | * Raw HTML content might be off-putting for people who want to use markdown, for example. This is being made easier by componentization of content, e.g. the demos, the compat tables. 304 | * Large amount of work for the MDN dev team to do the migration. 305 | * You would lose the instant preview you get of your pages/instant updates. This could be mitigated by further engineering work to create a page preview features - something that could spit out a preview that you can check. 306 | 307 | Generally, all of the cons have mitigations. General consensus is to move forward with investigating. 308 | 309 | Next steps: 310 | 311 | Socialize with the MDN community and investigate what this would take to move forward is there is support. Would not start working on this in the second half of 2018. 312 | 313 | * **ACTION** [ali]: Ali to set up meeting with Meggin's team to discuss what tasks they had to go through when moving a project to GitHub. 314 | * **ACTION** [Erika]: Erika to pull up information on what they went through when moving MS docs to GitHub. 315 | * **ACTION** [Kadir]: Kadir to research pros & cons, including limits to access to Github (China, embargoed countries) 316 | * **ACTION** [Kadir]: Get Meggin links to Kuma source code repo on Github 317 | * **ACTION** [Chris]: Chris to create a write up of this discussion and share these ideas with the MDN team and with the wider MDN community 318 | * **ACTION** [Kadir]: Kadir to scope the work with the dev team 319 | * **ACTION** [Kadir]: Review findings, start process for deciding if we put this on the roadmap. 320 | 321 | ## Working Session: Data outside of MDN 322 | 323 | Opportunities for using data outside of MDN include Including devtools, lighthouse, extensions, search result rich snippets, other? 324 | 325 | Q: What other MDN content could be interesting as standalone data? 326 | A: We want to get into people's workflows. BCD is useful, but what else is useful? We haven't done research on this yet. 327 | 328 | Opportunities: 329 | 330 | * Improve SEO 331 | * Rich snippets. Stack overflow bring their data into snippets, like other answers, popularity. 332 | * Could we include browser compat data? The short summary? 333 | * One box results - magic box in Google or Bing. How do we create those snippets? 334 | * Create cards 335 | 336 | * **ACTION** [Meggin/Robert]: find best practices for structured data for snippets 337 | * **ACTION** [Meggin/Robert]: Find out about search relationship like Wikipedia, talk to Ilya. What would be best to include in a snippet, best data to surface in results. 338 | * **ACTION** [Kadir] - research how we should be presented in search results. See what we could include, what our competitors and other sites include, etc. 339 | * **ACTION** [Dan] - contact Daniel Davis at DuckDuckGo about their snippets - see how they do it. 340 | * **ACTION** [Patrick] - contract Bing to see how they do snippets. 341 | 342 | Other things we could include: 343 | * Syntax sections 344 | * Short description 345 | * Devtools integration - we already have an extension for Fx. 346 | 347 | Kadir showed the group the compat-report add-on by Eduardo Boucas - puts the browser compat data for CSS features inside a Compatibility tab in the devtools 348 | 349 | We could do a shield study to get feedback on the idea from Firefox dev tools developers. 350 | 351 | * **ACTION** [Kadir]: to look into shield study 352 | * **ACTION** [Meggin]: Look into creating Chrome version of the extension. 353 | * **ACTION** [Patrick]: Look into creating Edge version of the extension. 354 | * **ACTION** [Patrick]: intro Kadir to VSCode team 355 | * **ACTION** [Kadir]: Check whether the business logic of the compat-report extension is separate - so it can be shared with other extensions. 356 | Lighthouse tests for browser compat. Sonar is the MS equivalent. Would be really good if we could have broad agreement about the schema for copat data so there could be consistency. 357 | * **ACTION** [Meggin]: Create an issue with the lighthouse team to start discussion about general integration 358 | * **ACTION** [Patrick]: Create an issue with the sonar team to start discussion about general integration 359 | * **ACTION** [Kadir]: Rekindle conversations with other editors like Atom, Sublime, etc. 360 | * **ACTION** [ Kadir] Talk to Fyrd about caniuse and MDN schema, would be great if we could all agree. 361 | 362 | ## Working Session: Membership and revenue 363 | 364 | Mozilla Developer Outreach team (which MDN is a part of) tasked with working out revenue ideas to make both Mozilla and the organization/projects more sustainable. Any revenue generated from MDN we will invest back into MDN (not go into Mozilla general fund). 365 | 366 | Mozilla gives MDN a budget (and headcount) each year. If we want to go beyond that, we need to raise the funds. 367 | 368 | ### Brainstorming: 369 | 370 | Wikipedia-style pop up funding request banner - not paid, but request for contributions 371 | 372 | We'd need a way for people to check where their money has gone. Publish the flow of funds. Some kind of chart - this year, MDN was run on ... 500MB of server space 373 | 374 | If MDN starts asking for payments, it needs to be clear that all that money will completely go to the health and future of MDN and that all volunteer work is valued. 375 | 376 | Q: Could you use contractor money just for platform dev stuff? 377 | A: Yes. We wouldn't want to limit it to this. 378 | 379 | Q: So contractor money could come out of operating budget, not the donations? 380 | A: Yes, theoretically, but the #1 goal is great content, having experts write guides, especially where the MDN team doesn’t have experience, adds value for users. 381 | 382 | Q: Could we pay for volunteer work if they did ENOUGH work? 383 | A: Probably not - very hard to measure and assess. Unfair to the more casual contributors. 384 | 385 | In general, writing contract work is piece work. Write X guide with Y pages. Usually has a deadline (e.g. CSS Grid launch across multiple browsers last summer). 386 | 387 | "Fan club" type thing - $50 membership gets you tshirt, invitations to exclusive events, etc.?General agreement that stores don't tend to work very well. 388 | 389 | MDN could sponsor an event - easier to give money for something that has a definite purpose, than just giving money for no reason. Sponsor Hack on MDN community events? 390 | 391 | Ask if other companies would sponsor MDN? 392 | 393 | Partnerships? 394 | 395 | Corporate training? 396 | 397 | MDN branded workshop days? 398 | 399 | How about crowd-sourcing funding for specific features? 400 | 401 | Feature bounty? 402 | 403 | Backlog that can be paid for if people want them quickly 404 | 405 | Sponsors page - platinum/gold/bronze level 406 | 407 | Some tool creators even cold-call vendors that they know use their tool and ask for money 408 | 409 | Micropayments with web payments (serves as demo + fundraiser). Did this content help you or meet your need? Give a dollar! 410 | 411 | Buy/sponsor an API or feature? 412 | 413 | Advertising in other places for the concept of MDN 414 | 415 | "adopt a writer" $ for coffee 416 | 417 | Reach out to amazon to see if they will sponsor us by paying some of our AWS bills. 418 | 419 | Cross-vendor events 420 | 421 | API card game (include API flashcards/data) - kickstarter to fund. Cute characters for each API. AR stickers. 422 | 423 | * **ACTION** [ali]: Write this up into a format that we can evaluate more effectively. 424 | * **ACTION** [ali]: put it in a doc and allow PAB/others to contribute 425 | 426 | ### Working Session: Joint web developer conference 427 | 428 | Robert has wanted to do this for a long time - all the browser vendor folks are passionate, and care about open web, standards, etc. 429 | 430 | Something around the same size as [View Source](https://viewsourceconf.org/london-2017/), done under the banner of MDN/Mozilla. 431 | 432 | Attendees - who would typically attend this? 433 | 434 | What kind of talks? 435 | 436 | Show agreed-upon movement forward we agree on, e.g. PWAs 437 | 438 | Do unconference sessions - get new ideas and feedback, work out what is and isn't working. 439 | 440 | Present future ideas and technologies 441 | 442 | Andrew Betts' Edge conference was great - half panels, half discussions 443 | 444 | Alternatively we could also invite loads of people and do a fun community-building type conference 445 | 446 | What if we had an unconference of experts combined with students - novices getting access to experts to learn, ask questions, etc. 447 | 448 | It would be nice to present a unified front, rather than having people converging at Chrome's conference, or whatever. 449 | 450 | If we did an unconference, it would be nice to work hard on inclusivity. 451 | 452 | diversity scholarships at FFConf were a good idea. 453 | 454 | We could also do student scholarships 455 | 456 | We could have different tracks for learning material, expert material, future/evolution discussions 457 | 458 | Or break it up into different foci on different days 459 | 460 | * **ACTION** [Robert]: Start thread on PAB email list to carry on with this conversation. 461 | 462 | ### Working Session: Organizing next PAB Meeting 463 | 464 | Original charter was for meeting every quarter, 3 via conference call and one f2f per year (in December or January). 465 | 466 | PAB Consensus: Would prefer to have more than onef2f meeting. 467 | Decision: Alternate the meetings - f2f, virtual, f2f, virtual. Also alternate f2f locations between North America and Europe. 468 | Discussion: Could have f2f meeting at TPAC in October (France), but generally feel this is a little late. 469 | Makes most sense to have the next f2f in July-ish. North America. Most PAB members are wither west Coast or Europe (UK, Germany). Maybe mid-west or east coast (in between for everyone). 470 | 471 | Mozilla has a co-working space in Chicago we could use. 472 | 473 | What about coinciding it with the dev rel summit? 474 | 475 | Seattle could be cool. And we'd get MS folks? 476 | 477 | Bay area might make sense too. 478 | 479 | Dan needs to be in Boston to TAG in July, that could work, too. 480 | 481 | * **ACTION** [ali]:- Start mailing list conversation to lock down July F2F dates and location. Time limit of 2 weeks on it. Specifically July 19 & 20 in Boston. Follow up once location/date are decided: 482 | * **ACTION** [Meggin/Robert]: Find out if Google could host in Boston/Cambridge 483 | * **ACTION** [Ali]: Find out if Mozilla could host if it’s elsewhere 484 | * **ACTION** [Dom/Dan]: Look at hosting options at MIT. 485 | 486 | Suggested next three meetings: 487 | 488 | 1. Late March/early April Telco 489 | 2. Late July F2F in the US 490 | 3. October Telco with optional F2F at TPAC, Lyon 491 | 492 | ### Working Session: W3C explainer docs 493 | 494 | We decided to have a very quick conversation about this 495 | 496 | How standardization changes should be communicated to MDN so we can update the docs 497 | 498 | Lower level - W3C has useful data for docs, e.g. details of URL changes. They can also easily extract things like WebIDL data for use in docs. This would make Jean-Yves' API skeleton pages idea easier to achieve. 499 | 500 | This would also inform better naming conventions for things like API page titles, possibly? Get them straight from the WebIDL. Linting of doc titles? 501 | 502 | Some clarification - we could try to encourage implementers to document concepts on MDN, but we might end up with lots of docs about stuff that will change/rot/not make it into standards. W3C has created primers for technologies, for example. 503 | 504 | Feeding back examples into MDN for example. Or maybe explainer text? 505 | 506 | Rather that hosting explainers on MDN, could we find a suitable way to link back to them? 507 | 508 | Having explainers for things that haven't shipped yet is dangerous. 509 | 510 | If you do put something experimental on MDN, have a button on the experimental banner that allows you to give feedback to the spec writers? Eg. Edge are currently looking at implementing this, they'd love your feedback on the feature. 511 | 512 | What if we used a usability study model on experimental APIs? 513 | 514 | Could we add this stuff to an existing tool or system like bikeshed? 515 | 516 | When you change a spec, you are expected to change the WPTs so that they match the spec. In an ideal world, there would also be the expectation of filing a bug to change the associated MDN page. 517 | 518 | When you write docs, you will often come across bugs in specs, or at least, things that could be designed better. 519 | Even having a simple link on the specs to the relevant MDN pages would improve the feedback loop 520 | 521 | * **ACTION** [Chris]: Think about improving the experimental banner to also ask for feedback. What would this look like? Also, think about how I'd like to see the feedback loop between MDN and specs, e.g. adding more examples back into the specs. 522 | * **ACTION** [Kadir]: Start email item to further discuss getting feedback in APIs/usability studies? 523 | * **ACTION** [Dom]: Set up a meeting to discuss the feedback loop further 524 | * **ACTION** [Chris]: Give Dom ideas on standards/style guides for explanatory text in specs, examples in specs, what constitutes a good example. 525 | -------------------------------------------------------------------------------- /meeting-notes/2018-03-notes.md: -------------------------------------------------------------------------------- 1 | # Meeting notes — MDN PAB video conference, March 14, 2018 2 | 3 | Attendees: Ali Spivak (Mozilla), Dominique Hazael-Massieux (W3C), Chris Mills (Mozilla), Kadir Topal (Mozilla), Daniel Appelquist (Samsung), Erika Doyle Navara (Microsoft), Patrick Kettner (Microsoft), Meggin Kearney (Google), Robert Nyman (Google) + MDN team members: Florian Scholtz, Jean Yves Perrier, Jeremie Patonnier, Janet Swisher (all Mozilla). 4 | 5 | Regrets: Rick Waldron 6 | 7 | ## Logistics 8 | 9 | * Date/Time: Thursday, March 14th 2018, 8am pacific 10 | * Place: Video call 11 | 12 | ## Agenda 13 | 14 | 1. Meeting kick off & agenda review (5 minutes) 15 | 2. Meet the MDN team! We’re all in Paris this week for a work week + Hack on MDN. 16 | 3. Check in on action items from [January meeting](ExecSummary_PAB_Jan.2018.md) 17 | 1. Do GitHub issues work for managing actions? 18 | 2. [Chrome DevTools browser compatibility extension](https://github.com/Meggin/browser-compatibility-extension). 19 | 4. Finalize July meeting dates & location (10 minutes) 20 | 1. Decided! July 31st and August 1, Seattle 21 | 5. Other discussion items (see below) 22 | 23 | ## Discussion Items 24 | 25 | * [Patrick] Discuss policy around contradictions in peer specs 26 | * See [Background twitter discussion](https://twitter.com/chrisdavidmills/status/966419778859610113) 27 | * [Dom] Exploring how to expose W3C-sanctioned best practices in MDN. Should we schedule a call with Chris to figure out the best way for us to propose a concrete action plan? 28 | * [Dom] Whether and how W3C specs can link from their head to the relevant MDN article(s). Would need to identify good-willing groups for an initial experiment). Also, could MDN help drive input to W3C specs redesign process? Who and how? 29 | * [Kadir] Developer needs: Is there research that can be shared about developer needs for the web platform? 30 | * [Kadir] compat data: Can we commit to updating compat data moving forward and for backfilling existing features? 31 | * [Dan] the Paris hack 32 | * [Dan] relationship with JS Foundation? 33 | * [Chris] “Start working group meetings to focus on “generic” PWA definition for MDN” — I’ve written some starter text to get us going on this, need some feedback from others in the group. 34 | 35 | ## Meeting Notes 36 | 37 | Consensus on keeping to use github issues. Ali will ddd missing issues from January + new action items from this meeting & follow up with PAB members on resolution. 38 | 39 | About policy around contradictions in peer specs (specifically when to mark things obsolete/experimental). Noted that WHATWG/W3C relationship process likely to change in coming months, maybe MDN recognizes/notes there are differences. Maybe a way to mark that there is ongoing discussion about the approach for that item? Should set some guidelines for MDN to address. [Chris] take action to propose guidelines, share for review with MDN team & PAB, add real examples in practice. If not obsolete everywhere should have a controversial tag. 40 | 41 | Exploring how to expose W3C-sanctioned best practices in MDN. Should we schedule a call with Chris to figure out the best way for us to propose a concrete action plan? Don’t want to take too much of Chris’ time, but it makes sense to discuss during Hack on MDN this weekend. 42 | 43 | Whether and how W3C specs can link from their head to the relevant MDN article(s). Would need to identify good-willing groups for an initial experiment). 44 | * [Dom] Add github issues for this 45 | * Start with groups that want to do this, longer term discuss making this mandatory with larger W3C. Are there any groups we should reach out to? Can add in the github issue 46 | * Chris - MDN team can start opening PR’s on the specs with links to the MDN docs. Need to first approach 1-2 groups to get their buy in. 47 | * Would be helpful to have some “getting started” templates available for consistency or workflow for spec editors for help starting articles matching their specs. MDN team could use help doing this. [open a github issue] 48 | * Web Platform incubator group? Mostly Chrome? Is this the first visibility on explainers. What goes into explainers, more used because TAG asks for it before they do a review, and possible Chrome is requiring explainer before shipping. Would be good to have a better understanding of the longer trajectory. 49 | * Use MDN audience reach to get more web developer input into the specs. Chris and Kadir like the idea. Questions, how far would the scope of this go? Depends, TC39 can be confusing, examples can help with being able to understand. 50 | * Spec redesign process, W3C has asked university students to work on a redesign project for specs, running a series of interviews. Focusing on design more than content, would be very useful for MDN team to provide input. Dom will send link to the project to Chris, Chris will share with other MDN writers. 51 | 52 | 53 | Developer needs: Is there research that can be shared about developer needs for the web platform? 54 | * Dom: [Closing the gap with native](https://www.w3.org/blog/2013/03/closing-the-gap-with-native-ap/), informal research and report 55 | * Listing existing articles, and surveys 56 | * Robert: We should leverage the reach of MDN. Could influence Google Product Managers. We’re currently winging it a lot, despite having a lot of data. 57 | * Kadir will start working group to figure out what data we want/need to collect from MDN users. Meggin suggested figuring out how to promote to users off MDN, and also partnership with framework providers [e.g. react] to get reach beyond web. 58 | * ⅓ of sites are on wordpress, we should reach out to them. 59 | 60 | 61 | Commitment to updating compatibility data 62 | * Joe Medley has been doing this on the Google side, will be doing this in Paris also with other Google team members. /web articles, make sure the compat data from these articles is represented on MDN? Right now there is a disconnect between blazing new stuff and what goes in stable and on MDN. Joe is trying to fix, can discuss in Paris 63 | * Peter and Ada coming to Paris from Samsung, Peter has been doing updates. Trying to figure out how to make the process more automated (will get more details from Peter this weekend) 64 | * Microsoft has manual process, will be looking into automating in the remote hacking session Friday. 65 | 66 | JS foundation 67 | * If we could get JS foundation to reference MDN docs by policy when creating dev docs within JS foundation projects that might be another win. 68 | 69 | PWA definition working group - will discuss over the weekend in Paris with Ada, Pete and Patrick. 70 | 71 | ## Action items [+assignee] 72 | 73 | * [Ali] get github account fixed, update issues from January & this meeting. 74 | * [Chris] schedule meeting w/ Dom exploring how to expose W3C-sanctioned best practices in MDN & set an action plan 75 | * [Kadir] Start working group on dev survey 76 | * [Ali] Speak to Kris Borchers about JS Foundation MDN cross-promotion and referencing MDN when creating docs. 77 | * [Chris] Propose guidelines/policy around contradictions in peer specs (specifically when to mark things obsolete/experimental), share for review with MDN team & PAB, add real examples in practice. 78 | * [Chris] discuss PWA definition working group this weekend in Paris with Ada, Pete and Patrick, follow up with PAB and wider interest group. 79 | * [Dom] Add github issues for MDN help drive input to W3C specs redesign process. 80 | * [Dom] Send link to the W3C redesign project interviews to Chris, Chris will share with other MDN writers. 81 | * [Dom] Add github issue for asking 1-2 W3C spec groups to link from the spec to the relevant MDN article(s). Needs PAB suggestions for relevant groups for an initial experiment. 82 | * [ali] Follow up with PAB members to plan July in-person meeting. 83 | * [Chris] Follow up with MDN team on creating "getting started" templates for spec editors to help start articles matching their specs. MDN team will need help from PAB members on this. Chris will discuss and follow up. 84 | 85 | ## Next meeting: July 2018 86 | * In-person meeting, July 31st - August 1, 2018, in Seattle. 87 | -------------------------------------------------------------------------------- /meeting-notes/2018-07-notes.md: -------------------------------------------------------------------------------- 1 | # Meeting notes — MDN F2F meeting, July/August 2018 2 | 3 | Attendees: Ali Spivak (Mozilla), Dominique Hazael-Massieux (W3C), Chris Mills (Mozilla), Kadir Topal (Mozilla), Daniel Appelquist (Samsung), Erika Doyle Navara (Microsoft), Patrick Kettner (Microsoft), Meggin Kearney (Google), Robert Nyman (Google). 4 | 5 | Regrets: Rick Waldron (Boucoup) 6 | 7 | ## Logistics 8 | 9 | * Date/Time: July 31-August 1, 2018 10 | * Location: Microsoft Westlake office: 320 Westlake Ave N, Seattle, WA 98109, US 11 | 12 | ### Tuesday, July 30 13 | 14 | * 09:00: Arrive at the Microsoft office & check in 15 | * 09:30: Breakfast, Welcome, & Orientation 16 | * 10:00: 2018 so far - review w/ numbers [Kadir] 17 | * 11:45: Lunch 18 | * 13:30: Content roadmap review & prioritization for the rest of 2018 [Chris] 19 | * 15:00: MDN Revenue deep dive [Ali] 20 | * 16:35: Discuss board impact, suggestions for changes/improvements 21 | 22 | ### Wednesday, August 1 23 | 24 | * 9:30: Set up working sessions 25 | * 10:00: The web platform strategy developers wish we had — introducing the PAB to our technology pipeline idea 26 | * 10:45: Working Sessions 27 | * 11:45: Lunch 28 | * 13:30: Working sessions 29 | * 15:30: Closing, agreements & commitments 30 | * 16:00: "Meet the PAB" happy hour 31 | 32 | 33 | ## Parking Lot 34 | 35 | Ideas that will be discussed if there is time. 36 | 37 | * Business cases for technologies (pros and cons) on MDN (e.g. Service Workers, or "don’t use App Cache"). Guides to modernizing legacy code & how to move off. Want to do this, not sure if it needs in-person discussion (will start email thread [ACTION Ali]) 38 | * Talk to Google folks about how we can get their agreement on the [license change to our data repo](https://github.com/mdn/data/issues/240) 39 | 40 | ## Meeting Notes: Day 1 41 | 42 | ### 2018 so far - review [Kadir] 43 | 44 | MDN is a top-line KPI at mozilla, getting reviewed on a quarterly basis 45 | 46 | #### Discussions on SlashData report 47 | 48 | MDN wins developer’s choice award for documentation and sample code. 49 | 50 | #### MDN growth strategies 51 | 52 | Two growth strategies: reaching developers that are more action-oriented, and bringing MDN content into developer's workflow 53 | 54 | Goals: 55 | 56 | * Get more developers to visit MDN 57 | * Get MDN into Developer’s workflow 58 | 59 | Data: 60 | 61 | * June 30th, 12.6M users, 47% yearly growth target. 62 | * MDN content moved behind CDN (assets have been behind a CDN for a while) - improved page load time by 1 second 63 | * MDN wiki platform only has 3 developers working on it (2 back end, 1 front end). Mostly doing maintenance and legacy fixes. Last year spent most of their time migrating MDN out of an old data center onto the cloud, this year most of their time was spent updating Django. Just about caught up with maintenance work; ready to start looking into new features. 64 | 65 | Goal to reach about ⅔ of web developers by end of 2018: 66 | 67 | * Estimated 11 million professional web devs around the world 68 | * Estimated ½ of MDN traffic is currently web devs (front/back end, fullstack); other half is mixed (IT, admins, students,...) 69 | 70 | MDN data migration into machine readable format, want to reach developers in their workflows. Working with VSCode, integrating CSS, more to come as we migrate more data. 71 | 72 | It's difficult to measure MDN usage in external tools; need to figure out how to do this. NPM packages is currently the only way we are able to measure, which isn’t really useful. 73 | 74 | As we get more data into more tools, there will be a mutual interest in quality content; need to work out what this looks like. 75 | 76 | Provide developers with data on what’s being used. Discussion on good/bad herd mentality. 77 | 78 | ‘Should I use’ vs ‘can I use’ 79 | 80 | #### Ideas on MDN reporting 81 | 82 | We should add reports for managerial people to MDN — data that shows how far something is from reality. 1-pagers for decision makers that explain business value of investing in certain technologies. 83 | 84 | Would be useful to have/create a list of the most trafficked deprecated technologies. 85 | 86 | Google's Lighthouse tool tells you what you are using that is deprecated, and suggests others (use this not that); doing an integration of MDN with this would be interesting. API linkage to MDN from lighthouse could be very interesting. 87 | 88 | #### New writers on MDN 89 | 90 | Added 2 new contract writers to MDN team, Irene Smith is focused on Firefox (and migration of Firefox) and Estelle Weyl is focussed generally on web technologies & APIs. 91 | 92 | #### Performance 93 | 94 | Performance: 90th percentile is at 4.7 seconds during the week, 6 seconds over the weekend 95 | 96 | Weekend numbers explained, China/Asia don’t take weekends like western users do, and those markets experience much slower performance so it changes the numbers significantly on those days. 97 | 98 | W3Schools has much better performance, especially on slow computers. Need to compete or be better; MDN usage in China and India growing and we need to serve these users better. Interactive examples important for performance, people want them. 99 | 100 | For interactive examples, we use a combination of codemirror and proprietary code. Tim Kadlec will be helping us with suggestions and implementation. Interactive examples on MDN are currently in iframes, need to have a better solution for these. 101 | 102 | SEO - most changes have been page by page, very inefficient. Focusing going forward on structured data where we can get more volume. We have guides for new content so best practices will be used. 103 | 104 | MDN home page needs a lot of improvement, search is not good. 105 | 106 | #### Error pages on MDN 107 | 108 | Firefox dev tools integration: last week we finished documenting [CORS errors](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors), will link to these from the Firefox DevTools. We currently link to [JavaScript errors](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors) & that drives a lot of traffic. Would like to have a conversation with others (e.g. Chrome DevTools team) about integration. 109 | 110 | Next set of error docs will be CSP errors. 111 | 112 | #### MDN future content roadmap 113 | 114 | * WebXR - Samsung team (Diego & Ada) can help with this, Diego could possibly help translate into Spanish. In Firefox roughly in release 71, in origin trials in Chrome. 115 | * CSS Houdini - massive set of new CSS API documentation. Started as a loose, collective code name, now it’s become a "real" name for the set of features. The original thought was that it would just become part of CSS. Q: Do developers expect to see Houdini or are we reinforcing this thing we don’t want. Increases jargon and complexity. Pages on MDN should be the APIs themselves. Blog posts, etc. could talk about Houdini but the MDN docs should not. Makes sense to have a tag, landing page/guide, glossary page. More like a SEO keyword, etc. Do the glossary asap. Probably required some amount of bikeshedding to figure out what to actually call it as part of the documentation structure. Chris will own doing this. 116 | * Rust > Web Assembly: apparently already in process of being documented by the Moz WebAssembly team, Chris is waiting to get this. Already have Emscripten documented on MDN. 117 | * Web API interactive examples - trying to figure out how to do this on MDN & what makes the most sense as far as API usage goes. Starting with some DOM stuff, 2D canvas, and other very commonly used APIs. Would WebGL fall under Canvas? Yes, but it’s not as easy to write demos in Raw WebGL — mostly you'd just use a library, and we don't document libraries. 118 | * MDN Performance docs need to be written and what little is there should be improved, Estelle will be working on this. Could be a great Hack on MDN topic to work on both the site and the docs (Toronto would be a great location for this). 119 | * Web Audio - Ruth John will be helping document this (might also do Web MIDI if it gets prioritized). 120 | * Web Payments API - Payment handler API needs to be documented; Chris following up with Moz engineers about this. 121 | * Events documentation is a big mess - laundry list isn’t much use without the context. Need to decide what to do with these (came up when we got to these as part of BCD migration; have left them for now while we sort out what to do with them). 122 | * Web Bluetooth; Samsung team interested in helping with this. 123 | 124 | Other ideas that came up: 125 | 126 | * Web USB - seems odd to ignore documenting this if we’re looking at Web Bluetooth 127 | * [Spatial Navigation](https://github.com/WICG/spatial-navigation) (Daniel) 128 | * Write documentation to make it easier to work across DevTools in browsers - generally if there is already good documentation for a tool we don't write it. Similar to the question of documenting frameworks on MDN, where we just don’t do it. Would drive more traffic, but with limited resources it just can’t be a priority. Whatever decision that is made needs to be deliberate because there will be questions. Need to be able to answer them with a well defined position. 129 | * Stack Exchange data dump — Google is investigating using this data set to discover common questions developers are asking, and also to see if they are getting the right information to use the tools effectively. There may be a cross-browser goal here to help developers solve common problems regardless of the tools. Worth talking about common problems. 130 | 131 | ### MDN Revenue deep dive 132 | Continuing exploration of how to generate revenue from MDN - among other things, MDN currently funded by Firefox, while MDN is a browser-neutral project 133 | 134 | Options: 135 | * Corporate sponsorship / membership 136 | * Membership (not donation): a program where members get something out of their payment - but difficult to determine what the quidproquo should be, and require up-front investment 137 | * supporters program à la Guardian - to ensure continued growth of and improvements to the platform; maybe show list of donors à la GoFundMe 138 | * Looked into job boards, but takes a lot of investment and is hard to make profitable - dropped that direction 139 | * Advertising - but not satisfying and would probably not generate enough revenue - may do a round of testing to validate 140 | 141 | ACTION: Ali to investigate using MDN membership program to create pool of developers willing and able to give direct feedback on spec design (especially having access to devs in different regions). 142 | 143 | ### MDN future location 144 | 145 | We are thinking about putting MDN on a separate domain, with developer.mozilla.org serving as a portal splitting off between Firefox stuff and MDN 146 | 147 | ### Board impact 148 | 149 | How/did did we impact MDN? How can we have more impact? 150 | The conversations between board members and how that has led to joint projects between MDN and browsers. 151 | 152 | * Board membership helps tie together different community engagements into a coherent whole. 153 | * Awareness within standards community to integrate MDN into workflows, considerations 154 | * Forum for finding opportunities for shared wins (e.g., VS Code integration), finding conflicts of interest (browser neutrality), input and validation from industry experts for prioritization of investments 155 | 156 | ## Meeting notes day 2: subject discussions 157 | 158 | ### Developer Needs Survey further discussions 159 | 160 | KEY METRICS 161 | 162 | Availability: percentage of web users running versions of browsers that contain the implementations of a web platform feature. We measure time-to-availability. 163 | 164 | Q: Is this really only % of users? This would mean, in practice, that as long as a feature ships in the dominant browser it counts as being available. Realistically, many developers won’t use something unless it is in more than one browser because they feel that makes it less likely for the feature to be dropped later. 165 | 166 | Adoption: how much a web platform feature is being used on the web. We measure the relative-rate-of-adoption. 167 | 168 | At Microsoft, implementation decisions are made based on a combination of User Voice & interoperability. As far as which standards, it is probably similar to Mozilla. 169 | 170 | There are areas where we know there is activity going on because there is agreement between different vendors, and that is why work is happening in that space (often with a direct product link). In other technical areas you only have 1 org pushing it & it tends to fizzle out. 171 | 172 | There is a cost to making the wrong decisions. 173 | 174 | Chrome Status tracker has helped Google make better decisions, shows what is in development and being proposed. One person built it, and it has had huge impact. 175 | 176 | W3C has a framework to build and maintain roadmap of Web platform features on a given topic, e.g. the [Media on the Web roadmap](https://w3c.github.io/web-roadmaps/media/), including information about current and future implementations. 177 | 178 | Q: Why are we using CSS Grid as an example? Why it is important that it was a coordinated release? Service workers - probably overcomplicated, could have better involved developers. 179 | 180 | Companies like Facebook often want a feature available in 75% of market 181 | 182 | * [Microsoft data on API implementations](https://developer.microsoft.com/en-us/microsoft-edge/platform/catalog/) 183 | * Stats for usage in Chrome: [HTML & JS](https://www.chromestatus.com/metrics/feature/popularity), [CSS](https://www.chromestatus.com/metrics/css/popularity) 184 | 185 | Service Workers, developer adoption still low, could we use MDN to help drive since something is not working. 186 | 187 | Like the idea of the needs survey, but it is difficult to write the right questions, and need to be careful how we use the results. Concerns: might be shortsighted in terms of what is good for the web long term, as opposed to urgency to solve a problem "right now". 188 | 189 | Survey would be the basis for the report but not the entirety of it. 190 | 191 | Would it make sense for MDN to have User Voice like MS is using? It’s interesting, we’d need to build a program on MDN around it. [ACTION] 192 | 193 | It's important to make sure it is representative of a broader input that just developers in Silicon Valley. How to represent a broader set of people and needs, including under represented groups and different geographies, different type of developers including those who don’t use the web? [ACTION] Kadir follow up with Samsung & Google, see if they can help reach a wider group, define targets? 194 | 195 | The Samsung developer conference in November could help to get word out to non-web developers. 196 | 197 | Step 1 is getting the requirements together. 198 | 199 | Is there any empirical data we can pull together to help inform requirements? 200 | 201 | ### Developer Event 202 | 203 | Turn View Source into a joint vendor event, brand MDN View Source. Important to know how we’d brand it, timing, etc. Co-branding. Parity is important. 204 | 205 | * A day of Wonky internals talks could be really fun 206 | * Then 1-2 public days on web technologies 207 | * Pavilions for either companies or specific technologies 208 | * Getting input from developers as opposed to just talking at them would add unique value to the event. Let people "vent" about what is difficult about the web. 209 | 210 | [Action] Ali to send email asking for committee members input, and schedule a follow-up meeting. 211 | 212 | ### Brief TPAC discussion 213 | 214 | [TPAC is in October](https://www.w3.org/2018/10/TPAC/) 215 | 216 | Last year we had a breakout session on MDN, this year the suggestion is for us to organize another breakout to report on what happened in the last year. Ali, Dom, & Dan will be there. 217 | 218 | Monday night dev meetup, Ali presenting on MDN 219 | 220 | Will be asked questions about EPUB# at this session; need an answer (see below discussion). 221 | 222 | ### "Peripheral" technologies (IMSC, EPUB3, etc) 223 | 224 | EPUBS3, IMSC (captioning), feel they would benefit from being documented on MDN, even though they are not implemented in (all/many/most) browsers. Would it make sense to create a “peripheral technologies” section on MDN. 225 | 226 | We will write up a set of rules for additional technology documentation 227 | 228 | * Separate architecture on MDN from core web docs, is useful/interesting for web developers 229 | * Has a community willing to document and maintain the documentation. Agree to 230 | * Is not documented elsewhere 231 | 232 | [ACTION: Chris to write up the rules of engagement for peripheral technologies and information architecture to host them] 233 | 234 | #### Feedback loop on experimental technologies 235 | 236 | It would be cool to have the ability to invite discussion/have early feedback mechanisms included in documentation page. Also have a tag for it? Call out that feedback is important. 237 | 238 | Need to build process around this, 239 | 240 | Maybe have surveys people could answer? 241 | 242 | [ACTION] Chris can try testing this & build macro, think about process and timing for maintaining this content/links 243 | [action] Dom will reach out to find spec groups who are willing to be testers and welcome “outsiders”. Then give a link to Chris. 244 | 245 | ### Making MDN Inclusive 246 | 247 | How do we keep the MDN community open and welcoming to everyone (especially as we add new members/grow users)? What problems actually are there on MDN? 248 | 249 | Our demographics are not great — users tend to be largely white and male, just like most other spaces. 250 | 251 | Great hidden mass of diverse developers, who are using MDN or could be, but they feel it is not for them. 252 | 253 | Are there ways to make the site feel more comfortable for diverse groups? Either by design, by language, by the way we talk about the community? 254 | 255 | Even though the Wiki is fairly easy to use, you need to have a certain comfort in your own skills and confidence to use the edit button and make contributions. 256 | 257 | Getting in touch with the MDN team is daunting, or more daunting than it should be. 258 | 259 | Part of it is that the writing team was traditionally male, but this could change now we have two female tech writers. Our M/F ratio on the team is now 50/50. 260 | 261 | Community management is challenging. 262 | 263 | Let's look at ways to invite more people in to contribute, particularly those from diverse groups. 264 | 265 | Contributions are largely casual, or drive-by. People don’t really stick around. 266 | 267 | Having a conversation with others is more difficult than it should be. 268 | 269 | A lot of contributions turn into turf battles. Places like Wikipedia have seen contributions decline because of this. 270 | 271 | Actions going forward: 272 | 273 | * Let's turn this into a board side project. 274 | * As more content is moved to GitHub, let’s look at how we can build in community involvement tools, pathways, etc. 275 | * A working group to look at this, both branding and representation, and specific design issues. 276 | * And attracting contribution community 277 | * Create sketch/brainstorm by TPAC 278 | 279 | Dan’s team could provide some resources to look into this problem, Meggin really wants to help. 280 | 281 | The homepage could really do with some work. People want unicorns, fun stuff, not corporate 2-color stuff. 282 | 283 | Look at [Glitch](https://glitch.com/) as an example — great at blogging, and their brand is all about inclusion. 284 | Glitch has people’s faces on it. 285 | 286 | As part of the Mozilla survey suggested in another part, we should specifically target universities, code schools, etc. Show specifically how this vertical differs from the MDN audience at large. 287 | 288 | ### MDN -> GitHub technical vision 289 | 290 | Over the last 18 months, we moved (some) CSS data and Compatibility data to MDN. This has been really successful — for example in the [browser-compat-data](https://github.com/mdn/browser-compat-data) repo we’re struggling to keep up with community PR’s. 291 | 292 | However, it’s all been data, not freeform text. 293 | 294 | Main issues here: 295 | 296 | * Localization of the content we store 297 | * Macros in text; how would they work in a GitHub repo? 298 | * What format would we store the content into? 299 | 300 | So questions: 301 | 302 | * How have others solved localization? 303 | * Are there any cautionary tales to share with us? 304 | 305 | Localization is really complex — Google tried to community drive it for some time, and it worked well for some locales, but eventually they hired a localization firm to handle the initial localization, and regular (say once a year) updates. 306 | 307 | Localization tooling? A few years ago, they built the [Google web developer site](https://developers.google.com/web/) with app engine, and published it via GitHub. But then it became complex to get that included inside the main Google site repository when an architectural change was decided on. 308 | 309 | They ended up with a script that finds out what changed, creates bugs and new content, and then pushes the new content to another repo. If all content can live in GitHub, then you are OK. 310 | 311 | For Windows docs it was really hard as some stuff could be public, and some stuff was not for public consumption so had to be kept in a private repo. 312 | 313 | Storing MDN content on GitHub is complex, as MDN is one consumer of the content, but it also needs to be made available in other contexts. 314 | 315 | The PR model is obvious and comfortable for web developers, but localization is a different skillset. Do we expect localizers to use the same toolset? 316 | 317 | Also, we need to manually check and merge each PR. How do we deal with PRs in languages we don’t understand? 318 | 319 | We could use [Pontoon](https://pontoon.mozilla.org/), but then the localized versions would then live inside that, rather than inside the same repo as the English versions. This could become its own community, separate from the English content. 320 | 321 | Google launched the Chinese version of Google Developers, but not much localization of it has happened. 322 | 323 | Localizations get outdated very quickly. After a while it makes more sense to re-translate the English from scratch, rather than trying to work out what changed. Google support has a team that handles translations. 324 | 325 | Need to work out technical details of the l10n. 326 | 327 | Action: Erika to follow up with l10n decision makers to see if they could offer some resources to get the short description localization done, e.g. on behalf of Code. 328 | 329 | Interactive examples tested/linted. Good, because these are the most examples on the page. But there are also other examples that need attention too. 330 | 331 | Possible learning session for future — get us talking to some localization experts. Various members of the group could find people to talk to.[Action] Ali will follow up with Meggin and Erika to figure these out. 332 | 333 | ### Tools & docs integration, concrete next steps 334 | 335 | #### VS code 336 | 337 | * We want VSCode to use data from MDN, but also link back to MDN. 338 | * We don’t know if Code would be interested in this, best next step is to talk to Pine 339 | * And give him the short description plan to look over. 340 | * Also want to start look at JS integration, which would be a different owner — find this owner. (Maybe Chakra/TypeScript teams?) 341 | 342 | #### Observatory/Lighthouse, etc. 343 | 344 | * We have lighthouse best practices (e.g. don’t use document.write()), but the MDN docs don’t reflect these. We’d want to make sure the messaging aligns, or at least check why not, if not. 345 | * Idea - add into lighthouse info on the deprecated features as specified in MDN BCD 346 | * Lighthouse team might want to have links from MDN back to lighthouse, or other things — e.g. what is the value proposition for lighthouse? Chrome DevTools team are very product-focused. 347 | * How to measure MDN data/info usage in external tools 348 | * First need to define what data we need. 349 | * Write document on why we should collect with this data, how it is beneficial to users, how we will use it, how often is it collected (e.g. every mouse over, or what?) 350 | * Would we need an API server, to collect data on run, on open, etc.? 351 | * Convenience methods, ideally server side, make it as easy as possible to 352 | * Endpoint that is capable to deal with spam 353 | * Best practice for devs, why we are doing it. 354 | * Under what circumstances do we want to have data collected 355 | * Bower as an example for one tool that did it 356 | 357 | #### API linkage to MDN from lighthouse 358 | * Ran out of time for this one. 359 | 360 | #### Compat data in Chrome DevTools? 361 | * Would need to look into this. 362 | * Talk to the DevTools folks about integration. 363 | * Start with creating an extension in the same way that we did with the Firefox extension; Eduardo Boucas could create a Chrome version of his extension as a first look. 364 | * Also talk to Chrome folks like Alex Russell, Pavel, etc. 365 | * Integration opportunities with more external dev tools (specifically error messages, but may be more opportunities like short descriptions) 366 | * For Firefox DevTools, we are planning on linking to CORS errors and CSP errors from the errors as they appear in the JS console. 367 | * Could we also get other browser vendors to link to our error message pages? 368 | * Let’s ask Kayce where or if error messages are currently documented. Could we do this on MDN instead, or at least include the Chrome versions of error messages too? We do this on some pages already. For example see the [Invalid_array_length reference page](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors/Invalid_array_length ) 369 | * We are also putting CSS property descriptions into Firefox DevTools at some point. 370 | * For integration with Edge DevTools, i18n would be a hard requirement before we can go anywhere. 371 | 372 | ### Documenting interfaces/Mixins/Dictionaries/Types 373 | 374 | (We ran out time to discuss this, but this is a problem we need to solve ASAP on MDN.) 375 | 376 | #### Dictionaries/Enums/Types 377 | 378 | Used to be just documented on the same page as the constructor (or whatever) they are used in, but more recently they have started being used across more than one feature. 379 | 380 | So we are going to start explicitly documenting them on their own page trees, in the same way as interfaces. 381 | 382 | Example: https://developer.mozilla.org/en-US/docs/Web/API/EffectTiming 383 | 384 | Also need to list dictionaries and types/enums separately in API sidebars 385 | 386 | Interfaces with Inheritance 387 | 388 | Docs are confusing to developers 389 | 390 | Example: https://developer.mozilla.org/en-US/docs/Web/API/DocumentOrShadowRoot 391 | 392 | Inherited by 393 | 394 | https://developer.mozilla.org/en-US/docs/Web/API/Document 395 | https://developer.mozilla.org/en-US/docs/Web/API/ShadowRoot 396 | 397 | Then we include links to the DocumentOrShadowRoot members on each of the above pages. 398 | 399 | But no developer is going to search for say 400 | 401 | DocumentOrShadowRoot.activeElement 402 | 403 | They will search for 404 | 405 | * activeElement 406 | * Document.activeElement 407 | * ShadowRoot.activeElement 408 | 409 | See [Sheppy's idea](https://discourse.mozilla.org/t/documenting-interfaces-with-inheritance/29912) 410 | 411 | have a macro along the lines of {{pageinheritance}} (special version of {{page}}) that takes content from the inherited page and puts it into the inheriting page, e.g. 412 | 413 | DocumentOrShadowRoot.activeElement -> Document.activeElement 414 | 415 | But then finds all special code/pre/a etc. elements that include the inherited interface name and replace them with the inheriting interface. 416 | 417 | So pages would need to be created multiple times, but not the content for those pages. 418 | 419 | Other example: BaseAudioContext -> OfflineAudioContext/AudioContext 420 | 421 | #### Mixins 422 | 423 | Mixin pages would be dealt with in a similar way to inherited interfaces. 424 | 425 | Sheppy also thought we could include a macro to insert information in the page about where a feature is defined: 426 | https://discourse.mozilla.org/t/mixin-presentation-idea/26189 427 | 428 | ## Next PAB meetings 429 | 430 | October meeting? Coincide this with TPAC? 431 | 432 | January meeting? January is good, just like with the previous one. Let’s pencil in the week of the 14th Jan 2019. Ali to send an email to figure out location & host 433 | 434 | Also can we have more regular calls? It would perhaps help us to focus on keeping things moving, keeping things current, stopping them from becoming deprioritised. Should we have a regular monthly call? Or just a regular monthly update? 435 | 436 | Regular six-weekly call 437 | Regular email update before call, plus more discussion around revenue, etc. 438 | 439 | ## PAB Actions going forward 440 | 441 | * [ACTION: Ali] Add a session on Wednesday to look into putting together a coalition of folks from across Google and Microsoft to work on MDN performance. 442 | * [ACTION: Chris] Work on plan for Houdini documentation — what to call it, how to structure it, etc. 443 | * [ACTION: Ali] Suggest Toronto as location and Performance as topic for our 1st 2019 Hack on MDN. 444 | * [ACTION: Ali] Investigate using MDN membership program to create pool of developers willing and able to give direct feedback on spec design (esp having access to devs in different regions). 445 | * [ACTION: Ali] Produce an annual report of the PAB achievements with input from PAB members 446 | * [ACTION: Kadir?] Look into how we could use UserVoice at MDN in a program 447 | * [ACTION: Kadir] Follow up with Samsung & Google, see if they can help reach a wider group, define targets 448 | * [ACTION: Ali] Send email asking for committee members input, and schedule a follow-up meeting. 449 | * [ACTION: Chris] Write up the rules of engagement for peripheral technologies and information architecture to host them] 450 | * [ACTION: Dom] Reach out to find spec groups who are willing to be testers and welcome “outsiders”. Then give a link to Chris. 451 | * [ACTION: Chris] Try testing this & build macro, think about process and timing for maintaining such content/links 452 | * [ACTION: Erika] Follow up with l10n decision makers to see if they could offer some resources to get the short description localization done, e.g. on behalf of Code. 453 | * [ACTION: Ali] Follow up with Meggin and Erika to find localization experts to talk to, to help work out GitHub content localization (related to getting MDN content on GitHub) 454 | * [ACTION: Ali] Write an email to reiterate ideas on MDN D&I and start off the process of making MDN more inclusive and welcoming of a diverse user base. Meggin wants to help, Daniel might also have resources. 455 | * [ACTION: Kadir] Start off this process of looking into how we could get JS docs integration in VSCode (different owner, maybe Chakra/TypeScript teams? Ask Patrick/Erika for help.) 456 | * [ACTION: Meggin] Give Chris link to link of best practices included in Lighthouse. 457 | * [ACTION: Chris] Take list of Lighthouse best practices and see if we cover all of them on MDN. Work out plan for covering the ones we don't cover. 458 | * [ACTION: Kadir] Write document on how/why we should collect usage data of MDN docs/data in external tools...how it is beneficial to users, how we will use it, how often is it collected (e.g. every mouse over, or what?) 459 | * [ACTION: Robert] Talk to Chrome folks like Pavel/Alex Russell about the possibility of including browser compat data in Chrome DevTools. 460 | * [ACTION: Meggin] Talk to Kayce about where or if Chrome error messages are currently documented. Could we do this on MDN instead, or at least include the Chrome versions of error messages too? 461 | * [ACTION: Ali] Send out e-mail to figure out location/host for next PAB F2F. 462 | * [ACTION: Ali] Set up Regular six-weekly call, plus regular email update before call, plus more discussion around revenue, etc. 463 | -------------------------------------------------------------------------------- /meeting-notes/2019-06-notes.md: -------------------------------------------------------------------------------- 1 | # MDN Product Advisory Board F2F Meeting, June 2019 2 | 3 | Attendees: Daniel Appelquist (Samsung), Jory Burson (Bocoup), Kyle Pfug (Microsoft), Dominique Hazael-Massieux (W3C), Meggin Kearney (Google), Chris Mills (Mozilla), Robert Nyman (Google), Ali Spivak (Mozilla), Kadir Topal (Mozilla). 4 | 5 | ## Logistics 6 | * Date/Time: June 4-5, 2019 7 | * Location: Mozilla Berlin office, Schlesische Strasse 27, 10997 Berlin, Germany 8 | 9 | ## Tuesday, June 4 10 | 11 | * 9:00 Arrive at the Mozilla office & breakfast 12 | * 9:30 Welcome & Orientation 13 | * 9.45 Review action items from January 14 | * 10:30 MDN status January-June 15 | * Product (Kadir) 16 | * Content (Chris) 17 | * 12.30 Lunch 18 | * 13:30 MDN H2 content plans 19 | * 15.15 Break 20 | * 15:30 View Source conference discussion (Ali) 21 | * 16:00 Other topics 22 | * TAG: Ethical Web Principles (Dan) 23 | * PWAs discussion (Dan) 24 | 25 | ## Wednesday, June 5 26 | 27 | * 9:00 Arrive at the Mozilla office & breakfast 28 | * 9:45 DNA Survey discussion (Kadir) 29 | * 11:30 Break 30 | * 11:45 MDN Membership update (Ali) 31 | * 12:30 Lunch 32 | * 13:30 Working sessions 33 | * 16:30 Wrap up session 34 | * Action item prioritization 35 | * Decide on next meetings 36 | 37 | ## Action items 38 | 39 | * Update how Edge is referenced in web compat tables: https://github.com/mdn/browser-compat-data/issues/3705 [Kadir] 40 | * Drop Edge mobile from the table rendering on MDN and maybe also from the data? (related issue: https://github.com/mdn/browser-compat-data/issues/3888 ) [Kadir] 41 | * Look into doing a combo View Source/TPAC event in 2020 [Ali] 42 | * See if there is interest in a Developer needs survey results talk at TPAC 2019, also a breakout session soliciting participation from W3C community. [Dom] 43 | * [done] Share screenshots of State of the Web dashboards for India, Indonesia and Japan w/ PAB members [Robert] 44 | * Content collaborations/partnerships - following up on conversations from collab summit & other ideas [Chris] 45 | * Update the experimental spec warning banner to ask for feedback on the spec [Chris]: https://github.com/mdn/pab/issues/58 46 | * Meeting with Google & Mozilla about learnings from migrating docs to GitHub (Ali, Meggin): https://github.com/mdn/pab/issues/37 47 | * Share the MDN Beta performance numbers with React with PAB members [Kadir] 48 | * Connect Kadir w/ Sebastian on React [Robert] 49 | * Figure out what the default set of browsers should be for MDN customization [Kadir] 50 | * Consider using customization w/ framework set [Kadir] 51 | * [done] Follow up w/ Kyle on some possible help with Web Authentication doc overhaul [Chris] 52 | * Updating MDN spec tables [Chris & Dom] 53 | * Keep info on W3C specs up to date on MDN [Dom]: https://github.com/mdn/pab/issues/19. Yes, it would be good to move forward on this 54 | * Next steps: Come up with a plan to agree upon. 55 | * Follow up on framework documentation on MDN [Chris] 56 | * Add an item to our agenda to talk more about MDN and GitHub [Ali] 57 | * Help Kadir w/ connections to the Lighthouse team re: browser compatibility audits 58 | * Original issue Meggin created (that got closed by Lighthouse team): https://github.com/GoogleChrome/lighthouse/issues/4377 59 | * Create a description & goals of conversation areas at View Source [Ali] 60 | * PWA issues: 61 | * [done] Create GDoc to start brainstorming new PWA content [Chris] — see [MDN PWA docs update, 2019](https://docs.google.com/document/d/178hFOHmMsEKh0VJTdC9GttJ_-22-rtQYyf9_SiAFKDQ/edit) 62 | * Form a team & figure out “f2f” working session on PWA’s [Dan & Ali] 63 | * Put together a GTM template & short description of the developer needs survey for partners (blog template description of survey, methodology, who has contributed, how it could be used) [Kadir & Ali] 64 | * Work on guidelines for supplemental/membership content on MDN web docs, curation, etc [Ali] 65 | 66 | ## Suggestions for working session items 67 | 68 | * [done] MDN Q2 update: 69 | * The customized MDN experience: Update on strategy and progress 70 | * High quality browser compatibility data: Automation and crowdsourced feedback. Update on strategy and progress. 71 | * [done] MDN Web Developer Needs Assessment: Early results. 72 | * [done] PWAs discussion - PWAs on different browsers. 73 | * Link to/from [PWA Builder](https://www.pwabuilder.com/) 74 | * [covered yesterday, will follow up on structure of docs] Content collaborations/partnerships - following up on conversations from collab summit & other ideas 75 | * How do we want the new Edge to be represented? Both in the data and in the tables on MDN? (related issues: https://github.com/mdn/browser-compat-data/issues/3705) 76 | * Followup; can we drop Edge mobile from the table rendering on MDN and maybe also from the data? (related issue: https://github.com/mdn/browser-compat-data/issues/3888 ) 77 | * [done] [Ethical Web Principles](https://www.w3.org/2001/tag/doc/ethical-web-principles/) 78 | * [done] PWA documentation 79 | * MDN PAB & cross-standardization orgs needs 80 | * There are a number of topics, etc covered by different (standards) orgs/groups developer relations, discussing how to have a more organized approach. PAB is one area the common need may emerge. 81 | * How specs are represented, how we classify what is experimental, getting feedback on specs, etc. 82 | * Common requirements (for example using GitHub) 83 | * Figuring out how MDN / PAB could fit within this work 84 | * MDN@TPAC 85 | * 2020 TPAC will be in Vancouver, maybe do a combo View Source/TPAC? 86 | * May experiment with opening plenary session up to “public” 87 | * Some sort of joint MDN/TPAC event would be great 88 | * 2019, maybe do a talk on Developer needs survey results, also a breakout session soliciting participation from W3C community. 89 | * 5 minutes from Robert 90 | * State of the web in India/Indonesia and Japan 91 | * Need of feedback loop for new web platform features 92 | * Wordsmithing developer needs survey 93 | 94 | ## Meeting Notes 95 | 96 | ### January action item review 97 | 98 | Items needing follow up: 99 | 100 | * Update the experimental spec warning banner to ask for feedback on the spec [Chris]: https://github.com/mdn/pab/issues/58 101 | * Not done yet - will work with Dom to identify candidate specs 102 | * Keep info on W3C specs up to date on MDN [Dom]: https://github.com/mdn/pab/issues/19. Yes, it would be good to move forward on this. 103 | * Next steps: Chris and Joe will share proposal with PAB & MDN team. Come up with a plan if it is agreed upon. 104 | * Do some triage on Microsoft priorities for Web Component docs and get back to the board members [Patrick]: https://github.com/mdn/pab/issues/6. The [web components docs on MDN](https://developer.mozilla.org/en-US/docs/Web/Web_Components) are fairly cool. Is anything else needed? (closed) 105 | * Discuss getting developer feedback in APIs/usability studies [Kadir]: https://github.com/mdn/pab/issues/59. Another nice-to-have. Did this go anywhere Kadir? [Keep open, will look into this after Developer Needs survey) 106 | * Designate a point person at your org to do compat data pull request reviews [Kadir, everyone]: https://github.com/mdn/pab/issues/32. Yes, we should do this. Again related to BCD governance project Florian is working on. 107 | * IE is one area people are looking for. Can generate a list of what is missing for IE ACTION: [Chris] - follow up w/ Florian to generate the report and follow up with Kyle for inputs 108 | * Close this issue, raise another one on IE compat data 109 | * New plan on getting 100% BCD to be presented later by Kadir 110 | * Everyone to check to see what their orgs are actually doing as far as updating compatibility data after each release. Implement a system to do this if not. Will report back on this next meeting [Daniel, Patrick, Meggin] — https://github.com/mdn/pab/issues/31. 111 | * Next Steps: Chris send around again for PAB members review, approve, get the right point people connected with Florian to move forward. Follow up meeting with point people scheduled. 112 | * Meeting with Google & Mozilla about learnings from migrating docs to GitHub (Ali, Meggin) — https://github.com/mdn/pab/issues/37. This would be a useful exercise. Maybe just do it as an async exercise (get the Google folks to write some thoughts in a doc?) 113 | * Next Steps: Ali will connect Will & Ryan with Meggin (keep open) 114 | 115 | Closed actions: 116 | 117 | * Start conversation with caniuse about MDN schema [Kadir]: https://github.com/mdn/pab/issues/54 118 | * Highlight feedback loop from MDN articles to W3C specs / GitHub repos [Chris]: https://github.com/mdn/pab/issues/25 119 | * JS Foundation MDN cross-promotion [Ali]: https://github.com/mdn/pab/issues/61. 120 | * Provide more information on what "supported" means on MDN [Chris, Florian]: https://github.com/mdn/pab/issues/33. 121 | * Determine if we can automate PR assignments through a GitHub hook [Kadir]: https://github.com/mdn/pab/issues/36 122 | * Look into compatibility data integration with WebHint [Kadir, Dan]: https://github.com/mdn/pab/issues/52 123 | * Happened, generated useful feedback on BCD 124 | 125 | 126 | ### Notes on transitioning MDN content to GitHub 127 | 128 | * Dan noted issues with accessibility on the current built-in MDN Editor. Moving to a more modern platform w/ ability to do more integrations will be helpful. 129 | * Localization = Google is looking into git localize. 130 | * Machine learning vs human translation - challenging 131 | * When we move to git we'll have to pick something. 132 | * Google always prefers to serve a localized version if available, even if it is out of date. Might make sense for the canonical version to be most recent. 133 | * Would-be translators of MDN don’t know where to start. 134 | * We should figure out what is the most important content to translate. Ali - seems like guides, tutorials, etc., would be more important to translate than reference pages. 135 | * W3C - ask translators to wait until specs are finalized before translating, since beforehand there is a lot of change and things can quickly get out-of-date. 136 | * For other content, there is a grace period before translations get pulled out after substantive edits in the original 137 | 138 | 139 | ### MDN review, first half of 2019 140 | 141 | * Mostly covering the last 3 months 142 | * Idea from Jory: Make a blog post on practical dev about the dev needs assessment &/or MDN love story 143 | * ACTION: Chris to share Yari post with PAB folks. DONE 110 | * ACTION: Chris to set up meeting to brainstorm how we can better integrate MDN with other functions such as spec process, via GitHub, to our advantage ([issue #81](https://github.com/mdn/pab/issues/81)) 111 | * ACTION: Chris/Florian to set up shared process for working together on MDN content (This is being done in a separate process, more to share soon) 112 | 113 | 114 | 115 | ## Next meeting 116 | 117 | Video call — January 27 118 | -------------------------------------------------------------------------------- /meeting-notes/2021-01-notes.md: -------------------------------------------------------------------------------- 1 | # MDN Product Advisory Board video meeting, January 2021 2 | 3 | Attendees: Reeza Ali (Microsoft), Dan Appelquist (Samsung), Sukriti Chadha (independant), Daniel Ehrenberg (Igalia), Dominique Hazael-Massieux (W3C), Brian Kardell (Igalia), Chris Mills (Mozilla, Chair), Sheila Moussavi (Bocoup), Robert Nyman (Google), Kyle Pflug (Microsoft), Ali Spivak (independant) 4 | 5 | ## Logistics 6 | * Date/Time: January 27 2021, 09.00 Pacific / 17.00 UK time / 18:00 Europe 7 | * Location: Mozilla Zoom room 8 | 9 | ## Agenda 10 | 11 | 1. Intro round 12 | 1. Updates on action items from last time 13 | 1. [DONE] ACTION: Chris to share Yari post with PAB folks. 14 | 1. ACTION: Chris to brainstorm with Dom using github to simplify spec/docs workflow integration.- ACTION needs to be followed up on; see https://github.com/mdn/pab/issues/81 for further activity 15 | 1. ACTION: Chris/Florian to create process for bringing documentation of new features in MDN docs. Started: Proposal for MDN content collaboration 16 | 1. Work out process and benefits text for PAB memberships: https://github.com/mdn/pab/issues/80 17 | 1. (Dom) RFCs for MDN 18 | 1. (Chris) Updates from Mozilla 19 | 1. (Robert) Short surveys on MDN 20 | 1. (Dom) Following on from previous point — Web DNA 2021 21 | 1. (Robert) Improving BCD presentation on MDN 22 | 1. Traffic lights? 23 | 1. Can I use integration? 24 | 25 | ## Meeting notes 26 | 27 | ### RFCs for MDN 28 | 29 | (Dom, proposed initially by Florian) having a (not necessarily formal, but documented) process to discuss platform evolution would be a useful addition to the MDN community. 30 | 31 | Getting inspiration from the RFC approach that have been successfully used in several communities (python, PHP, Rust to name a few) would allow us to bring iterative feedback and community momentum on these changes. 32 | 33 | With the transition to Yari, I believe a lot of questions on how content is tagged, organized, structured will emerge — right now, I'm assuming they would be discussed as part of the editorial meetings, but I think giving them more visibility and giving more agency to the broader community would be beneficial to MDN. 34 | 35 | Thinking aloud on the topics these RFCs could be applied to: 36 | * "moving off HTML" 37 | * documenting interface mixins 38 | * localization strategies 39 | 40 | For a non-trivial change, write up a public spec that people can then comment on. 41 | 42 | So we need a template, guidelines, a process, and a location to put it all. 43 | 44 | ACTION: Write up proposal for RFCs, including template and process (steal) 45 | Assigned to Dom, also Florian could perhaps help. 46 | 47 | ### Updates from Mozilla 48 | 49 | News: Adam (COO) is leaving Jan 31. Shared last week as well. 50 | Responsible for product focused approach and OWD conversation 51 | MDN now within Mozilla’s marketing org 52 | Not much more communication about next steps yet. More to follow when we get it. 53 | 54 | ### Short surveys on MDN 55 | 56 | We’ve been doing Web DNA for a couple of years; interesting to get high-level pain points info. 57 | 58 | Last year’s survey reaffirmed this, however the major pain points didn’t change much, and probably won’t change much if we do the same kind of survey next year.. 59 | 60 | Instead we’d like to propose shorter surveys, more often. 61 | 62 | * Use MDN task completion survey to give people surveys to fill in 63 | * Instead of 25 minute surveys, do a 2 minute survey once a month, on more specific topics, e.g. CSS layout. 64 | * Smaller surveys, much quicker turnaround. 65 | * Also costs less to run 66 | 67 | Discussed so far at google (Robert/foolip) and Mozilla (Chris/Hermina). Thoughts? 68 | 69 | Sukriti — do we have implicit metrics/understanding to help bolster results, and do we have real time feedback? 70 | 71 | Robert — WebDNA not about MDN as such, more about web problems in general (e.g. compat). MDN as diverse as possible, neutral, etc. 72 | 73 | Dom — supports this, distinguishing between short surveys and longer surveys, and things that can and can’t be captured by these approaches 74 | 75 | Sheila — things like demographic data are hard to catch through short surveys 76 | 77 | Robert — also need to be really careful that we are clear on PII/privacy policy for both types of survey. Make sure we have clear process and definition for designing questions, what PII is needed, what we can ask with PII 78 | 79 | Reeza — how will developers feel about this? Might get annoyed. Need to allow people to opt out. 80 | 81 | Robert — yes, probably need to build in mechanisms to protect people from survey fatigue. Also, different surveys could be rolled out to different percentages of MDN users, and just in different areas, depending on focus and importance. In the future we could even reward people for doing the surveys, in some way. 82 | 83 | Brian — could we make something fairly inconspicuous that is there all the time, then a random sampling of % gets something more prominent at times? Maybe if so it would be good to track which of those two it was as you can expect that the people who do the inconspicuous one is maybe/probably a different kind of involvement. 84 | 85 | Sukriti thoughts on this; we need to: 86 | 87 | * Allow developers to easily dismiss the prompt 88 | * Position it as an opportunity to give feedback
 89 | * Provide an upper bound on time/ developer spent on surveys 90 | 91 | ACTION: Robert/Chris to work more on survey framework, process, make sure it gets PII built in! 92 | 93 | ### Web DNA 2021 94 | 95 | Web DNA 2020 was rushed, and impacted by Mozilla layoffs 96 | 97 | Should come up with plan for this year 98 | 99 | Funding is a big thing. Microsoft/Google to fund this again? 100 | 101 | Kyle — might propose decreasing frequency in current form, 2, 3, 5, years? 102 | 103 | Smaller surveys could have much sharper focus on finding immediate problems. 104 | 105 | if there isn't a DNA 21, we should also let the community know 106 | 107 | ACTION: Wait for above action to be completed, then work out what DNA should do , how it should stand alongside short surveys 108 | 109 | ### Improving BCD presentation on MDN 110 | 111 | MDN compat data tables used to be hand-maintained, but the data is now in its own repo. 112 | 113 | Yari now in GH repo as well. 114 | 115 | Lots of data there now, but there is still a lot of work to be done here. 116 | We need more information about how useful BCD actually is. Is it as useful to MDN readers as it could be? How much is it being used in tools? 117 | 118 | Part of this is a discussion on improving presentation. To make it easier, could we use a traffic lights system? 119 | 120 | And/or could we just use the caniuse presentation actually on MDN? 121 | 122 | Joe — caniuse data; exactly what do we have in mind there? 123 | Caniuse is using BCD data for a lot of its tables now. 124 | Single point of failure (caniuse is just one man) 125 | Yes, would have to mitigate, if MDN goes down this path. 126 | 127 | Chris — we also talked about BCD ribbon on top of page for a while 128 | 129 | Dom — UX research? Yes! 130 | 131 | Chris - we are hiring a UX/designer at the moment 132 | 133 | Brian — in previous minutes, people brought up challenges like methods or properties being experimental. Having this granularity, versus just a traffic light… Existing specs do a some interesting flagging like this: 134 | 135 | ![Spec section — Attributes common to HTML and MathML elements — showing number of tests, and red light green light display to indicate support in different browsers](../assets/browser-support-spec-info.png) 136 | 137 | Chris - yes, granularity, simplified versus complex views? Maybe even an automated code compat tester based on trawling BCD? 138 | 139 | Reeza — how about automated testing of data? 140 | 141 | Robert — perhaps using WPT in the future? But not really right now. 142 | 143 | Would it be good to discuss what users do in terms of using the data? Research testing 144 | 145 | Joe — follow on from Brian’s point. People often assume that the overall spec data is all they need to know, whereas in fact that this is not the case. Need some kind of summary for a spec (or an interface) that explicitly points out where the outliers are, if any. 146 | 147 | ACTION: Need to come up with a plan for better BCD presentation, and share it around for comment. 148 | 149 | 150 | 151 | ### Action items 152 | 153 | * ACTION (Dom, Florian): Write up proposal for RFCs, including template and process to use ([issue #82](https://github.com/mdn/pab/issues/82)) 154 | * ACTION (Robert/Chris): To work more on survey framework, process, make sure it gets PII built in! ([issue #83](https://github.com/mdn/pab/issues/83)) 155 | * ACTION: Wait for above action to be completed, then work out what DNA should do next time around, and how it should stand alongside short surveys ([issue #84](https://github.com/mdn/pab/issues/84)) 156 | * ACTION: Need to come up with a plan for better BCD presentation, and share it around for comment. ([issue #85](https://github.com/mdn/pab/issues/85)) 157 | 158 | 159 | 160 | 161 | ## Next meeting 162 | 163 | Video call — February 24 2021 164 | -------------------------------------------------------------------------------- /meeting-notes/2021-02-notes.md: -------------------------------------------------------------------------------- 1 | # MDN Product Advisory Board video meeting, February 2021 2 | 3 | Attendees: Reeza Ali (Microsoft), Dan Appelquist (Samsung), Sukriti Chadha (independant), Hermina Condei (Mozilla). Daniel Ehrenberg (Igalia), Brian Kardell (Igalia), Joe Medley (Google), Chris Mills (Mozilla, Chair), Sheila Moussavi (Bocoup), Robert Nyman (Google), Kyle Pflug (Microsoft), Ali Spivak (independant) 4 | 5 | ## Logistics 6 | * Date/Time: February 24 2021, 09.00 Pacific / 17.00 UK time / 18:00 Europe 7 | * Location: Mozilla Zoom room 8 | 9 | ## Agenda 10 | 11 | 1. Moving forward on action items (Chris) 12 | 1. Web Platform Compatibility updates on MDN (Robert) 13 | 1. Compat is a massive issue for developers 14 | 1. Looking at top focus areas going forward (e.g. flexbox) 15 | 1. Roadmap prototype (Sukriti) 16 | 1. MDN Update at Mozilla (Hermina) 17 | 18 | 19 | ## Meeting notes 20 | 21 | ### Moving forward on action items 22 | 23 | Chris — everyone is busy, I totally get that, but it’d be nice to start making a bit more progress on the [pab GitHub issues](https://github.com/mdn/pab/issues) that were recorded from action items in the past. 24 | 25 | Ali — in the list of action items in each meeting, run through list of open GitHub issues, or perhaps just look at priorities (which would need some triaging first). 26 | 27 | Chris — Spend half the meeting looking at previous items? 28 | 29 | Dan — in the W3C TAG, we use a script to put issues from GitHub using the GitHub API to pull up issues, and who is assigned, etc., and generate markdown. 30 | 31 | ACTION: CHRIS triage some issues, send mail round, ask people to update on the issues they are assigned to, and grab ones they are interested in. 32 | 33 | ### Web Platform Compatibilty updates on MDN 34 | 35 | Robert — From research, compat issues are by far the biggest problems for developers. 36 | 37 | Browser vendors want to spend time fixing the biggest compat problem areas, for example flexbox (complete priority list to follow later on). Google and MS already working together on this, also speaking to Mozilla about getting involved. 38 | 39 | The idea would be to fix the biggest issues, and then broadcast to developers that we are responding to their needs. 40 | 41 | Also, when we reach milestones (e.g. all bugs fixed for flexbox), we could broadcast this info via blogs, RSS, MDN including MDN accounts? Personalized BCD type stuff? 42 | 43 | Dan — One concern here; I would be slightly worried about this from the PoV of a "minority browser". Wouldn't it reinforce bias? 44 | 45 | Would this make sense on MDN? 46 | 47 | Hermina — we did a survey on this recently, and asked about personalized BCD; not many people said they would care about BCD. But the survey was aimed at junior developers. 48 | 49 | Pros might be more interested 50 | 51 | Brian — I realize it is unscientific, but a twitter poll might be an interesting data point on this ? 52 | 53 | Hermina — I don’t think it’s unscientific (or I don’t think it matters:) but yes, definitely. A secondary data point is always a good idea. Let’s do this. We can use the MDN twitter account, unless you have other ideas? 54 | 55 | Also, it’s a moving target — e.g. this feature is widely supported by browsers, but what does that mean? What bugs are relevant? 56 | 57 | Robert — we are collecting all the bugs from WPT, and then working against those. It is not necessarily about 100% effectiveness, but about fixing an area to a point where it is completely usable by a developer. 58 | 59 | Joe — the magic here is in the design. E.g. for a feature to be developed it has to add to an existing feature. Getting rid of this churn would be key. 60 | 61 | Chris — yes, I was interested in this, exact location is in question, but yes. RSS feed, blog posts, make sure BCD is up to date. 62 | 63 | Reeza — how often would you envisage one of these milestone articles being written? Some areas are much bigger than others. 64 | 65 | Robert — we would have a dashboard to show progress, developers tend to want feature completeness. Would there be key milestones inside each major area? Report on each one. 66 | 67 | Joe — saying something is supported across all browsers latest version...is that still useful? Rollout to all people will still take a while. We would need to factor this into the reporting. 68 | 69 | Also maybe an incentive for people to upgrade their browsers. Especially interesting for folks using ESR versions. 70 | 71 | Provide geography-aware data? E.g. it is available in 90% of browsers worldwide, but what about India, or China? 72 | 73 | Dan — that kind of personalization would be more useful. E.g. My users are in China, what browsers do I need to support? 74 | 75 | ACTION: Robert and others to meet to discuss more about where this should live, how to communicate this, etc. Build this into a project. Robert to set up a meeting, or maybe brainstorm in a doc. 76 | 77 | ### Web standards implementation roadmap 78 | 79 | Sukriti made a [prototype](https://trello.com/b/yj8mdLsW/mdn-product-roadmap) ! 80 | ACTION: Chris include in process 81 | Others to give feedback 82 | 83 | ### MDN Mozilla update 84 | 85 | Hermina — We are having an UX designer join our team 86 | 87 | We will be having Gregor Weber rejoin us for 3 months while Florian D is on paternity leave 88 | 89 | We will be having another full-time writer coming on board soon 90 | 91 | MDN now under marketing...there is interest to figure out proper place for MDN in Mozilla 92 | 93 | 94 | ### Action items 95 | 96 | * ACTION: CHRIS triage some issues, send mail round, ask people to update the issues they are assigned to, and grab ones they are interested in. DONE, Chris has set up regular time on a Monday to do triaging on the content and pab repos 97 | * ACTION: ROBERT and others to meet to discuss more about where web compatibility updates should live (on MDN, Insights, etc), how to communicate this, etc. Build this into a project. Robert to set up a meeting, or maybe brainstorm in a doc. ([issue #86](https://github.com/mdn/pab/issues/86)) 98 | * ACTION: Chris to include Sukriti's web standards implementation roadmap prototype in process docs, others to give feedback. DONE, included in notes that Chris will use to write up process very soon. 99 | 100 | 101 | ## Next meeting 102 | 103 | Video call — March 17 2021 104 | -------------------------------------------------------------------------------- /meeting-notes/2021-03-notes.md: -------------------------------------------------------------------------------- 1 | # MDN Product Advisory Board video meeting, March 2021 2 | 3 | Attendees: Reeza Ali (Microsoft), Dan Appelquist (Samsung), Sukriti Chadha (independent), Daniel Ehrenberg (Igalia), Dominique Hazael-Massieux (W3C), Brian Kardell (Igalia), Joe Medley (Google), Chris Mills (Mozilla, Chair), Sheila Moussavi (Bocoup), Robert Nyman (Google), Kyle Pflug (Microsoft), Ali Spivak (independant) 4 | 5 | ## Logistics 6 | * Date/Time: March 17 2021, 09.00 Pacific / 17.00 UK time / 18:00 Europe 7 | * Location: Mozilla Zoom room 8 | 9 | ## Agenda 10 | 11 | 1. Updates on active issues 12 | 1. (Robert) [Discuss more about where web compatibility updates should live](https://github.com/mdn/pab/issues/86) 13 | 1. Some decisions to make, more discussion to have? 14 | 1. Major areas of focus being blogged on Monday by MS and Google. 15 | 1. This provides a way to show that we've listened to your feedback e.g. in MDN Web DNA. 16 | 1. It provides a positive feedback loop 17 | 1. A bigger item here is to try to move forward with the browser compat data ribbon idea. We should start by writing up an RFC on what the BCD ribbon should look like, what it should do, etc. ACTION ITEM 18 | 1. Dom — we also discussed having some kind of celebration when particular milestones are reached. What to do here? 19 | 1. What role does MDN play here? 20 | 1. Tweet successes on MozDevNet? 21 | 1. Show the latest progress on MDN? Embedded dashboards? 22 | 1. If we ask for feedback, we are obliged to show what happened as a result. 23 | 1. ACTION ITEM: Brainstorm milestone success broadcasting ideas 24 | 1. (no assignee) [Write plan for better BCD presentation](https://github.com/mdn/pab/issues/85) 25 | 1. Chris [wrote these ideas down](https://docs.google.com/document/d/1Q_ZKB61ktPXm3St6tm9OZRYQfx8SoAb8yD2YlFGHR4w/edit) for possible BCD improvements. 26 | 1. ACTION ITEM, ALL: Provide feedback on Chris's ideas. 27 | 1. (Robert, Chris) [Write proposal for plan and process for Web DNA survey 2021](https://github.com/mdn/pab/issues/84), [Work on process and framework for MDN short surveys](https://github.com/mdn/pab/issues/83] 28 | 1. ACTION ITEM, ALL: Provide feedback on Robert's docs! 29 | 1. [Short surveys on MDN: Process](https://docs.google.com/document/d/1XTGkGG-zeXvKk0W-C4srqYeMH6Kk0m4yd1r7KJKDhs8/) 30 | 1. [Short surveys on MDN: Guidelines](https://docs.google.com/document/d/1JVdK-f8j3tGnyeBff0O22MnlTHw_r4WAYKJPKjYC5ek/) 31 | 1. [Short surveys on MDN: Technical requirements](https://docs.google.com/document/d/18Sv9nEzLuzgbR2sp4sMmfHaW7-47vVhrfQ30h5v6cMs/) 32 | 1. (Dom, FlorianS) [Write up proposal for MDN RFCs](https://github.com/mdn/pab/issues/82) 33 | 1. Largely done, just needs process and format documentation? 34 | 1. We also need to think about the process of getting RFCs improved/approved. Who should review these? related standards communities, etc.? Guidance on where to broadcast, and where to distribute them for review should be included in the documentation. 35 | 1. ACTION ITEM, CHRIS: Document the process of writing up the RFCs. 36 | 1. [Brainstorm how we can better integrate MDN with other GH-based functions such as spec process](https://github.com/mdn/pab/issues/81) 37 | 1. A lot of interest on this one; could do with someone looking through all the old discussions, consolidating, and writing a plan for what we should do moving forward. 38 | 1. Most obvious first step is to write a suggested update of the [TAG explainer template](https://github.com/w3ctag/w3ctag.github.io/blob/master/explainers.md) that would make it more transferable onto MDN when the time is right. Joe already has something like this, so let's look at using that first rather than write another one. 39 | 1. Also, consolidate this with other similar issues: 40 | 1. https://github.com/mdn/pab/issues/23 41 | 1. https://github.com/mdn/pab/issues/26 42 | 1. https://github.com/mdn/pab/issues/65 43 | 1. Dom — Not just in early life of spec, but also would be good to figure out how to signal requirements for new items to be documented. 44 | 1. some (very) recent work Dom did in seeing MDN gaps in evolution of WebAuthn (which is going to be published as Level 2 Rec very soon) https://lists.w3.org/Archives/Public/public-webauthn-adoption/2021Mar/0003.html 45 | 1. Joe — tried to change the form of explainers from within Google. 46 | 1. Explainer writers all tended to say that their explainers only contain pseudocode, and are only supposed to give a rough idea of what the spec is for 47 | 1. Also a political thing — TAG wouldn't let Joe in to discuss this 48 | 1. New specs are highly volatile. 49 | 1. Reeza ideas 50 | 1. It sounds like there's a relationship between a spec being available and docs get written/updated. Do we have "milestones" when a spec needs to get documented or updated? Can we use GitHub labels to flag when a spec was created/updated, and the docs needs to get written/updated? 51 | 1. Could we get something more browser neutral? 52 | 1. in W3C, reaching Candidate Rec is probably a good milestone to check whether documentation exists (docs can naturally exist well before; but not having it at CR is probably a bug) 53 | 1. Many would agree here 54 | 1. ACTION ITEM: Would generally be nice to have someone write up a clear plan here with action items, and consolidate the different issues 55 | 1. ACTION ITEM: Joe to send around his proposal for the TAG explainer rewrite, to see if we can make use of it. 56 | 1. BRIAN - A bunch of new things now start inside WICG/Open UI, so maybe that is a good place to discuss this? 57 | 1. ACTION ITEM: Brian to see if these groups could help (possibly, not sure if this is a definite action item). 58 | 1. [Create proposal for new membership process and make it clear what they can get out of the membership](https://github.com/mdn/pab/issues/80) 59 | 1. This is really on me (Chris) to do, but I'd like someone to check my proposal at least 60 | 1. ACTION ITEM: Chris to write this up and put it on MDN. 61 | 1. [Looking into MDN compatibility data integration with Lighthouse](https://github.com/mdn/pab/issues/51) 62 | 1. This is pretty interesting still... 63 | 1. [Contact Bing to see how they do snippets](https://github.com/mdn/pab/issues/47) 64 | 1. Still useful to consider, with Bing and other search engines? 65 | 1. Also related: https://github.com/mdn/pab/issues/43 66 | 1. Also: https://github.com/mdn/pab/issues/45 67 | 1. (Robert) The relationship between this meeting and all the other ones, such as Editorial, Opportunity Assessment, BCD and OWD meetings? 68 | 1. This is for Chris/Hermina really. 69 | 1. There are lots of different touch points now, lots of meetings. There are different constellations of people, some overlap in meeting discussions, and sometimes important people are missing from various discussions 70 | 1. Where does PAB fit into all of this now? 71 | 1. Could we merge some meetings, or do we just need to be a bit more careful about where things are discussed, e.g. make sure BCD topics are discussed in the BCD meeting? 72 | 1. Chris: Probably more like the latter, as all the meetings do have distinct purposes: 73 | 1. MDN editorial meeting (Mondays, 9am PST): A weekly standup meeting for MDN content creators to talk about work they are doing right now, and bring up issues/concerns. Usefully, some of the MDN dev team attend this meeting, so it is also a good place to talk to them about issues that may require dev input. 74 | 1. MDN content opportunity assessment (once per month, Wednesday, 9am PST): This is where we discuss new opportunity assessments, see what we feel about them, and rank them against other opportunity assessments, to see what the strongest contenders are for being added to the roadmap in the next quarter. 75 | 1. BCD meeting (once every 2 weeks, Wednesday, 9am PST): This can be considered to be a regular project meeting for the BCD project. Normally you have a regular project meeting for active projects, but BCD is always happening, and always important, so. This is for discussing issues specific to BCD. 76 | 1. OWD editorial steering committee meeting (every week, Wednesdays, 8.30am PST): This is for updates with the OWD project content work, and has possible overlap with the MDN editorial meeting, but that's OK. 77 | 1. PAB meeting (once per month, Wednesday, 9am PST, this meeting): High-level strategic discussions on MDN's future. 78 | 1. Kyle — not 100% clear how much of the current overlap between e.g. PAB meetings / OWD / various high-touch content workstream is deliberate vs. coincidence. There may be places to consolidate if the audiences/topics are common. All of these are valuable but right now it’s a lot of similar groups wearing different hats at different times. 79 | 1. ACTION ITEM, CHRIS - Look at meetings, be deliberate about summarizing overlap 80 | 81 | ### Action items 82 | 83 | * ??: Brainstorm milestone success broadcasting ideas for web compatibility updates. 84 | * ALL: Provide feedback on [Chris' ideas](https://docs.google.com/document/d/1Q_ZKB61ktPXm3St6tm9OZRYQfx8SoAb8yD2YlFGHR4w/edit ) for possible BCD improvements. 85 | * ALL: Provide feedback on Robert's docs for short surveys on MDN: 86 | * [Short surveys on MDN: Process](https://docs.google.com/document/d/1Q_ZKB61ktPXm3St6tm9OZRYQfx8SoAb8yD2YlFGHR4w/edit ) 87 | * [Short surveys on MDN: Guidelines](https://docs.google.com/document/d/1Q_ZKB61ktPXm3St6tm9OZRYQfx8SoAb8yD2YlFGHR4w/edit ) 88 | * [Short surveys on MDN: Technical requirements](https://docs.google.com/document/d/18Sv9nEzLuzgbR2sp4sMmfHaW7-47vVhrfQ30h5v6cMs/) 89 | * CHRIS: Document the process of writing up the RFCs, and soliciting feedback on them. DONE 90 | * ??: Get someone to write up a clear plan for integrating MDN with other GH-based functions such as spec process, with action items, and consolidate the different issues 91 | * Joe: Send around his proposal for the TAG explainer rewrite, to see if we can make use of it. DONE 92 | * BRIAN (MAYBE?): See if the WICG and Open UI groups could help with MDN/Spec touchpoints (possibly, not sure if this is a definite action item). 93 | * Chris: Write up PAB membership process and put it on MDN. DONE, checking with Mozilla legal to make sure wording is OK before sharing it with PAB. 94 | * CHRIS: Look at potential meeting overlap and distribution of discussion topics, think about being more deliberate about summarizing overlap. 95 | 96 | ## Next meeting 97 | 98 | Video call — April 21 2021 99 | -------------------------------------------------------------------------------- /meeting-notes/ExecSummary_PAB_Jan.2018.md: -------------------------------------------------------------------------------- 1 | # MDN Product Advisory Board Meeting — Executive Summary 2 | 3 | You can read the [detailed meeting notes here](2018-01-notes.md). 4 | 5 | The first in-person MDN Product Advisory board meeting took place over 2 days (11 & 12 January, 2018) in London. 6 | 7 | Presented the final MDN 2017 metrics. Most questions revolved around localization and understanding the global audience of MDN (including growth potential), volunteer contribution, and what content on MDN gets the most traffic. Moved on to the draft 2018 roadmap, and Kadir went into depth on several core themes for the year: 8 | 9 | * Moved code samples to the top of the page and introduced interactive examples for JavaScript in 2017. 2018 will focus on completing interactive samples for HTML, CSS and Web APIs. 10 | * 80% of MDN traffic comes through search; improving results pages will have a huge impact. In 2017, we did SEO audit and experiments. 2018 will execute successful SEO experiments and focus on performance, including a performance audit and exploring using a CDN. Look into making code samples available in rich search results across browsers, with help from PAB members. 11 | * Explore making it easier for users to search, browse and learn if they don’t know the specific method, property, API they are looking for (also could include use case browsing). Don’t have a specific plan or set of topics yet. 12 | * Potential to incorporate compatibility data in browser dev tools, editors, or enable developers to create tools based on this data. 13 | * MDN had 50-60% traffic and contribution growth in 2017 but Mozilla staff and program budget were static (same in 2018, too). Looking for ways to fund MDN beyond what Mozilla invests today. 14 | * Discuss benefits and challenges of moving to GitHub as the backend for all of MDN. Compatibility data, interactive samples, and macros/scripts are currently on GitHub, so we have experimented successfully with this. 15 | 16 | Currently, 9 Mozilla paid staff work full time on MDN: a product manager, 3 developers, 4 content writers (including a content lead), and a project manager (who also does content reviews). ~USD$500k program budget. Staff uses “agile” process; a 12 day sprint then 3 days to plan next sprint goals, do a retrospective, and have a “breather” day. MDN also uses an opportunity assessment process. PAB input is expected to be rolled into this system— Mozilla team owns prioritization. 17 | 18 | Start working group on “generic” PWA definition for MDN. Discussed frameworks documentation; decided it’s fine to introduce the main concepts in the learning area but not document the frameworks themselves. Based on feedback from Samsung, will review adding Web Bluetooth and Web MIDI to content roadmap. Web Components are a priority for Microsoft; Patrick will do some triage and give priorities. Finally, we decided members will come to each meeting with content priorities prepared for discussion. 19 | 20 | Created a PAB repo on GitHub to track work, publish meeting notes, etc. 21 | Day 2 started with setting up unconference-style breakout sessions to discuss some of the issues that we thought needed more work. 22 | 23 | ## Session 1: Compatibility Data. 24 | Google team going to China soon. Robert will follow up with findings when they get back. 25 | Currently migrating compat data from hand-written HTML tables to machine-readable JSON. 40% there (HTML, HTTP, JS built-ins all done, CSS mostly done). WebAPIs are the largest content area and will be done in 2018. Maintaining MDN Browser Compatibility Data requires manual labor (dues to hand witten HTML). Will investigate (with help from Google & MS) automatic comparisons based on Web Platform Tests (WPT). 26 | Asked the board to commit to updating data after each browser release. Members will check what their orgs are actually doing and implement a system to do updates if not doing already. Everyone will report back on this next meeting. Asked PAB members and their teams for help reviewing compatibility data PRs. General willingness to help. 27 | 28 | ## Session 2: Wordsmith MDN mission statement 29 | Start: "provide people with the information they need and teach them what they need to know to build delightful experiences on the open web." Finish: "Inform and guide people with the most comprehensive information they need to build first class, cross-platform experiences on the open web." 30 | 31 | ## Session 3 : Moving MDN's backend functionality to GitHub 32 | Discussed pros and cons, decided the cons have mitigations. General consensus is to move forward with investigating. Next steps will be to socialize with the MDN community and investigate what this would take to move forward. Would not start working on this until the second half of 2018. 33 | 34 | ## Session 4: Data outside of MDN 35 | Opportunities for using data outside of MDN include data in various browser devtools, Lighthouse/Sonar, extensions, search result rich snippets. Meggin is working on a Chrome extension using the current browser compatibility data, Patrick took actions to start discussion about general integration with the MS Sonar team and explore creating Edge version of the extension. Members took various action items around investigating including browser compat data short summary and/or code samples in Google or Bing search results. 36 | 37 | ## Session 5: Membership and revenue 38 | Mozilla gives MDN a budget and headcount each year, but if we want to speed up implementation of specific capabilities or content we will have generate additional, external funding for it. Any revenue generated from MDN will be invested back into MDN (not go into Mozilla general fund). Members brainstormed a lot of ideas. Action item taken to spend time to formulate these a little more before presenting as opportunities. 39 | 40 | ## Session 6: Next PAB Meeting 41 | Original charter called for a meeting every quarter, 3 via conference call and one in-person per year (in December or January). Members want more than one in-person meeting per year, so will have 2 in-person meetings each year (one in Europe, one in North America). Next virtual meeting in March, next face-to-face in July. 42 | 43 | ## Session 7: W3C & MDN 44 | Had a quick conversation about how standardization changes should be communicated to MDN writers. In an ideal world, there would be the expectation of filing a bug to change the associated MDN page. Will set up meeting with W3C to discuss. Also of interest is the concept of API skeleton pages and adding a button on the experimental banner that allows users to give feedback to the spec writers 45 | 46 | ## Asks of the MDN team from the Board: 47 | * Board members would like to see additional metrics: 48 | * Comparison US vs. Europe as a whole 49 | * Numbers of mdn visitors compared to % of developer population per country 50 | * Metrics by language as opposed to by country 51 | * Would like to be able to see/track how specific things (new content, functionality rollouts, design changes, etc.) drive traffic increases 52 | * Request to get a better understanding of MDN audience growth opportunities across the globe. 53 | * Could use better sources of data on global developer population. If anyone has suggestions we’d love to all use the same metrics (no real answer here) 54 | * Request to publish public guidelines on how/why MDN engages contractors for content and dev work. 55 | * Request to make sure that what comes out of the PAB is rolled into the working cycle of MDN, specifically the opportunity reviews and work prioritization. Figure out how to get PAB members at the weekly opportunity assessment meeting (maybe special edition after PAB meetings to specifically discuss new opportunities brought up by the board?). Clarified that the Mozilla team will continue to own prioritization of the requests. Google team was interested in learning more about how MDN opportunity assessment model; Kadir will set up some time to share with the Google team 56 | * Board requested more information and raw data from the results of remote user testing sessions. Kadir will see if future user terms/agreement can be updated to allow sharing interview videos with the board. 57 | * Requested a view of the long-term cost of content - creating it but also maintenance. Chris Mills committed to figuring out a formula for determining lifetime cost & lifetime value. 58 | * Create a summary doc that covers changes to the quarterly priorities that came out of the PAB meeting that is shared publicly. Also make sure that there is a way for people to surface things they want the board to review/cover/provide feedback on. 59 | * Need a process for getting involved in the actual work, which is beyond the scope of the board. For example, an extension could be a personal project vs an MDN platform project. Document in the repo itself what the purpose is and the boundaries are, and include link to the projects. 60 | 61 | ## Commitments made by board members: 62 | * Meggin (Google) is working on a compatibility data extension for Chrome, similar to the one built by a contributor for Firefox. Patrick will look into possibility of extension for Edge. 63 | * Ask for the board. For each Firefox release Mozilla updates content and compat data based on what’s new in the release. Ask representatives from the other browsers to do this, too. Members from MS, Google, Samsung will check to see what their orgs are actually doing and implement a system to do this if not. Will report back on this next meeting on process and point person. 64 | * Request made to board members to help recruit remote user testing participants outside of/beyond MDN. Will add as an action item for members and follow up on the mailing list; review in next PAB meeting to check up on outcome. 65 | * Ask for the board: PAB members and their teams help review browser compatibility data PR’s. 66 | * Board members committed to investigate Chrome and Edge versions of the Firefox compatibility extension. 67 | * Board members committed to investigating lighthouse & sonar tests for browser compat. Sonar is the MS equivalent. 68 | * Board members committed to helping generate and evaluate ideas for generating revenue on/from MDN. 69 | * Board will explore idea of a joint conference under the MDN brand. 70 | * Board decided to have 2 face to face board meetings each year, as opposed to only one as proposed in the original charter. Charter will be updated. 71 | 72 | ## Opportunities/Proposals from the board: 73 | * Opportunity to review (in Q2): Exploring use-case driven content on MDN, didn't create a specific proposal here but will bring back up at the next in-person PAB meeting. 74 | * Opportunity to review: Suggested CDN for MDN to help with performance (note: this is already being considered as an opportunity by the MDN team). Will start with a performance audit in Q1, and then scope what it will take to implement CDN in 2018. Will review results of audit in Q2 meeting, then present at opportunity review for prioritization. This is a large effort that will fully occupy MDN’s dev resources. 75 | * Opportunity to review: Building samples into structured data for search results 76 | * Opportunity to review: Figure out how to track success for data usage in external tools/apps. Maybe getting consent/approval for sharing usage data with Mozilla could help here, or we could look at coverage via specific tools. Will most likely require more qualitative data. Can see extension users, could use it at least for getting started. 77 | * Opportunity to review: Board supports a proposal to explore moving to github as the backend for all of MDN, including content. Google has hybrid content publishing model using github, will schedule time to discuss with broader MDN and Google teams. 78 | * Opportunity to review: Having shared definition and documentation on how to implement PWA’s across platforms/vendors would be helpful. There was some discussion in October (separately/outside of MDN PAB group, but including a few members) about creating a working group to figure out a shared definition of PWA’s between Mozilla, Samsung, Google, and Microsoft, PAB decided to try to make this happen. Chris Mills will reach out to the original group and see if progress can be made on this. 79 | * Opportunity to review: Web Bluetooth, Midi are priorities for Samsung. Midi specifically isn’t documented on MDN, so will look into adding Web Bluetooth, Web Midi to content roadmap. 80 | * Opportunity to review: Messages on reference pages need to have a clearer definition of what “on standards track” means, and also generally what warrants which warnings on a page. 81 | * Opportunity to review: Web Components are priority for Microsoft. Probably be outside of the quarterly meetings, get back with a heads up about priorities. 82 | * Opportunity to review: Explore possibility of automation of compatibility information based on Web platform tests (WPT) and other data sources, and then fix the problems using manual work afterwards. Evaluate using Google Confluence as a bridge between MDN and WPT. 83 | * Opportunity to assess: Add a useful feedback mechanism on MDN pages and extensions based on the data. For example, simple thumbs down widget that people can click if data is incorrect. 84 | * Opportunity to review: We should look to define guidelines on what "supported" means for aggregate features. What partial means, etc. E.g. if a single subfeature is not supported, does it count as the whole feature not being supported? Core uses, edge case uses? Needs user testing/research? 85 | * Opportunity to review: MDN backend move to github. Start by socializinh concept with the MDN community and investigate what this would take to move forward is there is support. Need to prioritize deeper investigation and scoping. 86 | * Opportunity to review: using data outside of MDN include Including devtools, lighthouse, extensions, search result rich snippets (browser compat data, short summary, code samples). Board members committed to investigating best practices for various browsers 87 | * Opportunity to review: Drive to get broad agreement about the schema for copat data so there could be consistency between various sources of information to developers (e.g. MDN and caniuse) 88 | * Opportunity to Review: If you do put something experimental on MDN, have a button on the experimental banner that allows you to give feedback to the spec writers? Eg. Edge are currently looking at implementing this, they'd love your feedback on the feature. 89 | * Opportunity to review: check which browser data a PR changes with a GitHub hook, then add tags and assign reviews as appropriate. Flag PR for each browser and the vendors would assign a point person to look at flagged items. 90 | 91 | ## ACTION ITEMS 92 | * - done ACTION [Ali] Add localization as a working session topic to dive deeper tomorrow 93 | * ACTION [Kadir]: Get metrics by language as opposed to by country 94 | * ACTION [Kadir]: For metrics, comparison US vs. Europe as a whole would be helpful 95 | * - done- ACTION [ali]: Add working session for MDN mission statement wording. 96 | * - done- ACTION [ali]: Add structured data in search results to working session list… 97 | * ACTION [Kadir]: Look into getting permission to share remote user testing interviews with board members 98 | * ACTION [Kadir] Share current opportunity backlog 99 | * ACTION [Kadir]: Share opportunity assessment model with Google team 100 | * ACTION [Chris]: Review adding Web Bluetooth, Midi to content roadmap 101 | * ACTION [Chris]: Follow up on reviewing the current banners we show on reference pages; need to have a clearer definition of what “on standards track” means, and also generally what warrants which warnings on a page. 102 | * ACTION [Patrick]: Do some triage on priorities for Web component docs and get back to us. 103 | * -done- ACTION [Dom] Create a (temporary) repo for the PAB and invite everyone on the board 104 | * ACTION [Chris]: Get info on how to migrate temp PAB repo to main MDN. 105 | * ACTION: [Chris]: Start working group to focus on “generic” PWA definition for MDN 106 | * ACTION [ali] Write up an Exec summary of changes or proposals in addition to detailed meeting notes. 107 | * ACTION [ali]: provide a mechanism for MDN team/contributors to submit asks for the board ahead of meetings. 108 | * ACTION [Robert]: report back on outcome of Google meeting in China 109 | * ACTION [Kadir/Robert] — see if the people who work on confluence/WPT could output the data in a useful format. 110 | * ACTION [everyone]: Everyone to check to see what their orgs are actually doing as far as updating compatibility data after each release. Implement a system to do this if not. Will report back on this next meeting. 111 | * ACTION [ Dan, Patrick/Erika, Meggin]: Designate a point person for compat data pull request reviews 112 | * ACTION [Kadir]: Create an opportunity assessment item for adding a feedback mechanism on BCD tables so someone can easily report incorrect data. 113 | * ACTION [Kadir] : (if they exist, share guidelines on what "supported" means with the group, get more feedback. 114 | * ACTION [PAB follow up, Kadir]: Work out what we need to put in the support summary banners. Write plan, do user testing, etc. 115 | * ACTION [ali]: Share Hack on MDN info with PAB. 116 | * ACTION [Kadir] follow up with PAB members and their teams on reviewing compat data PR’s 117 | * ACTION [Kadir]: Look at how to could check which browser data a PR changes with a GitHub hook, then add tags and assign reviews as appropriate. 118 | * ACTION [ali]: Ali to set up meeting with Meggin's team to discuss what tasks they had to go through when moving a project to GitHub. 119 | * ACTION [Erika]: Erika to pull up information on what they went through when moving MS docs to GitHub. 120 | * ACTION [Kadir]: Kadir to research deeper on migration (pros and cons), including limits to access to Github (China, embargoed countries) 121 | * ACTION [Kadir]: Get Meggin links to Kuma source code repo on Github 122 | * ACTION [Chris]: Chris to create a write up of this discussion and share these ideas with the MDN team and with the wider MDN community 123 | * ACTION [Kadir]: Kadir to scope github migration work with the dev team 124 | * ACTION [Kadir]: Review findings, start process for deciding if we put github platform migration on the roadmap. 125 | * ACTION [Meggin/Robert]: find best practices for structured data for snippets 126 | * ACTION [Meggin/Robert]: Find out about search relationship like Wikipedia, talk to Ilya. What would be best to include in a snippet, best data to surface in results. 127 | * ACTION [Kadir] - research how we should be presented in search results. See what we could include, what our competitors and other sites include, etc. 128 | * ACTION [Dan] - contact Daniel Davis at DuckDuckGo about their snippets - see how they do it. 129 | * ACTION [Patrick] - contract Bing to see how they do snippets. 130 | * ACTION [Kadir]: to look into shield study 131 | * ACTION [Meggin]: Look into creating Chrome version of the compat extension. 132 | * ACTION [Patrick]: Look into creating Edge version of the compat extension. 133 | * ACTION [Patrick]: intro Kadir to VSCode team 134 | * ACTION [Kadir]: Check whether the business logic of the compat-report extension is separate - so it can be shared with other extensions. 135 | * ACTION [Meggin]: Create an issue with the lighthouse team to start discussion about compatibility data integration 136 | * ACTION [Patrick]: Create an issue with the sonar team to start discussion about compatibility data integration 137 | * ACTION [Kadir]: Rekindle conversations about including compat data in their products with editors like Atom, Sublime, etc. 138 | * ACTION [ Kadir] Talk to Fyrd about caniuse and MDN schema, would be great if we could all agree. 139 | * ACTION [ali]: Write up revenue ideas into a format that we can evaluate more effectively and allow PAB/others to contribute to fleshing ideas out more in depth. 140 | * ACTION [Robert]: Start thread on PAB email list to carry on with conversation about joint developer event under MDN brand. 141 | * ACTION [ali]:- Start mailing list conversation to lock down July F2F dates and location. Time limit of 2 weeks on it. Specifically July 19 & 20 in Boston. 142 | * ACTION [Chris]: Think about improving the experimental spec warning banner to also ask for feedback. What would this look like? Also, think about how I'd like to see the feedback loop between MDN and specs, e.g. adding more examples back into the specs. 143 | * ACTION [Kadir]: Start email item to further discuss getting developer feedback in APIs/usability studies? 144 | * ACTION [Dom]: Set up a meeting to discuss the W3C changes feedback loop further 145 | * ACTION [Chris]: Give Dom ideas on standards/style guides for explanatory text in specs, examples in specs, what constitutes a good example. 146 | 147 | ## Attendees 148 | Ali Spivak (Mozilla), Kadir Topal (Mozilla), Chris Mills (Mozilla), Robert Nyman (Google), Meggin Kearney(Google), Dominique Hazael-Massieux (W3C), Erika Doyle Navara (Microsoft), Daniel Appelquist (Samsung), Patrick Kettner (Microsoft). 149 | -------------------------------------------------------------------------------- /membership.md: -------------------------------------------------------------------------------- 1 | # Product Advisory Board Charter & Membership 2 | 3 | ## 1. Purpose and Objectives 4 | 5 | The primary purpose of the PAB is to provide advice, input, and feedback on content strategy, content prioritization, strategic direction, and platform/site features to MDN's Product Manager and Content Lead. Mozilla will consider input and advice from the PAB; however PAB input and recommendations are non-binding. The primary objectives of the PAB are: 6 | 7 | - Provide feedback into content strategy and prioritization of standards documentation 8 | - Help define product strategy, roadmap, and priorities including: 9 | 10 | - Suggest and comment on Objectives and Key Results (OKRs) 11 | - Suggest and comment on yearly and quarterly content roadmaps 12 | 13 | - Make organizational and individual commitments to contribute to MDN based on the defined strategies, roadmaps and priorities 14 | - Represent and promote user requirements, ensuring that MDN continues to evolve and meet users' needs and challenges 15 | - Suggest and give feedback on new opportunities 16 | - Provide feedback on recruiting and retaining contributors (both corporate and individual) 17 | - Share experience and best practices 18 | 19 | ## 2. Membership Selection and Termination 20 | 21 | a. The PAB shall consist of 10 to 12 Members (as defined in the MDN Product Advisory Board Agreement and including those individuals representing a Member organization), to be selected by Mozilla. 22 | 23 | b. There are two types of membership: organizational and individual. Organizations who meet the membership criteria and are accepted as member organizations may nominate up to 2 individuals to serve as their representatives ("Member Representatives" as defined in the MDN Product Advisory Board Agreement) on the PAB. 24 | 25 | c. Organizations/individuals who wish to become PAB members must submit a MDN Product Advisory Board Interest Form. Membership will be subject to review and approval by Mozilla, and notification will be sent to the applicant within 30 days of application. 26 | 27 | d. Membership start dates will be based upon review meeting schedules; any new Members will begin their term on the PAB at the next scheduled review meeting. 28 | 29 | e. Members of the PAB will serve terms of 1 year, renewed automatically for up to 3 years (unless terminated by either party). At the end of the 1-year term, the PAB Member and Mozilla will review membership and decide whether to continue Member participation. 30 | 31 | f. Members may resign in writing, via email to the PAB mailing list. Member organizations can nominate replacements for resigned members before the start of the next review meeting. 32 | 33 | g. Mozilla may terminate a Member in the case of violation of the MDN Advisory Board Agreement, violation of the MDN PAB Code of Conduct, violation of the Antitrust Policy, or if the Member fails to participate in two consecutive review meetings without notice. At that time, a notice will be sent to the principal contact stating that they have been removed as a Member. 34 | 35 | ## 3. PAB Membership Qualifications 36 | 37 | a. PAB Members have in-depth industry knowledge and expertise. Members will be knowledgeable about web standards, with the ability and experience to align MDN's overall strategic goals and content plans with evolution of web standards, industry direction, and the needs of developers using MDN's documentation. 38 | 39 | b. Membership in the PAB is limited to organizations and individuals who make significant contributions to MDN and/or the advancement, development, and implementation of web standards. 40 | 41 | c. Member organizations must play a significant role in the creation, implementation, or adoption of Web standards and guidelines. It is also preferred that PAB Member organizations be members of an established Web standards group, such as W3C. Member organizations may nominate up to 2 individual representatives to serve on the board. 42 | 43 | d. Individual Members of the PAB must have at least one of the following qualifications: 44 | 45 | - Plays a significant role in the creation, implementation, or adoption of Web standards; 46 | - Participates in a Web standards group dedicated to the development of specifications for features implemented in a Web browser or used in Web content that is sent to browsers. Participation in W3C or a similar standards group is preferred but not required. Individual Members may also meet this qualification by having served on a standards working group or as an invited expert on an established Web standards working group; 47 | - Is a member of a Web-focused Developer Relations team; 48 | - Works as part of a group doing technical documentation of Web standards; or 49 | - Makes significant, sustained contributions to MDN Web standards documentation as a volunteer. 50 | 51 | ## 4. Member Responsibilities and Commitments 52 | 53 | a. Members are expected to provide feedback and responses in a timely manner, and attend a minimum number of review meetings. Participation is welcome from all over the world. Members' expectations include: 54 | 55 | Provide feedback on scheduling annual and quarterly meetings; 56 | 57 | - Attend annual meeting; 58 | - Attend at least 2 quarterly reviews per year; 59 | - Review proposals and provide feedback; 60 | - Join the PAB mailing list; 61 | - and Agree not to promote a specific corporate or individual agenda, particularly in the creation or editing of content on MDN. 62 | 63 | b. Members may be required to provide personal information and material (bios, etc.) for analyst, press, and/or trade publications and press releases. 64 | 65 | c. All Members must sign the MDN Product Advisory Board Agreement and agree to the MDN PAB [Code of Conduct](https://www.mozilla.org/en-US/about/governance/policies/participation/) and Antitrust Policy. 66 | 67 | ## 5. MDN PAB Member Benefits 68 | 69 | It is anticipated that PAB membership will have the following benefits: 70 | 71 | - Impact content strategy and priorities for MDN; 72 | - Influence the strategic direction of MDN; Have advance knowledge of MDN plans and development; 73 | - Make suggestions for features and platform improvements to grow MDN audience and contribution; and 74 | - Provide feedback and technical reviews of content. 75 | 76 | ## 6. Scheduled and Ad Hoc Meetings 77 | 78 | a. Members will be invited to the following meetings: 79 | 80 | - Annual Product Strategy review meetings to take place between October and December of each calendar year; 81 | - Quarterly content strategy and prioritization review meetings ("Quarterly Reviews); and 82 | - Ad hoc product review/check-in meetings, which can be initiated by Mozilla or any Member as needed ("Ad Hoc Meetings"). 83 | 84 | b. Annual Product Strategy review meetings will review the previous year's progress and make recommendations for MDN's strategy and objectives for the following year. 85 | 86 | c. Annual Product Strategy review meetings can take place in Mozilla headquarters or worldwide office, the offices of a Member, or external locations, as determined by vote of the PAB. Virtual attendance will be accommodated for Members who are unable to attend in person. 87 | 88 | d. Quarterly Reviews and Ad Hoc Meetings will primarily be held via video/conference call, although in-person attendance will be possible at the discretion of Members. 89 | 90 | e. Ad Hoc Meeting dates will depend upon the work in development. Review points will have a specific emphasis such as coordination around product release dates and major features or new specs and standards reaching broad release that require more in-depth coordination and planning beyond the Quarterly Review. 91 | 92 | ## 7. Time Commitment and Costs 93 | 94 | a. Members are asked to make a commitment to the PAB for at least 12 months. 95 | 96 | b. Members are asked to commit the time to prepare for, attend (sometimes in person), and participate in regularly scheduled and ad hoc PAB meetings. 97 | 98 | c. Costs for participant travel and living expenses or other involvement are to be paid by the individual board member or the sponsoring organization. 99 | --------------------------------------------------------------------------------