Too long? You can also read an Executive summary of the January notes.
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).
ACTION [Kadir]: For metrics, comparison US vs. Europe as a whole would be helpful
Q: Can we get numbers of % of developer population per country? 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) 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)
Q: Does the MDN team know what are the growth opportunities across the globe? 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
- ACTION [Ali] Add localization as a working session topic to dive deeper tomorrow
- ACTION [Kadir]: Get metrics by language as opposed to by country
Q: What are the most trafficked content areas on MDN? A: JavaScript is the most trafficked part of MDN
- Not just web developers look at the docs, e.g. node links to MDN
- CSS growth - combination of moving samples to the top of pages & CSS Grid launch and docs being written by Rachel Andrew
- HTML traffic growth mostly came from updating input type
- Learning Area on MDN, launched last year, driven growth (over 1 million per month visitors).
- 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)
Q: How do you talk to contributors? 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).
Q: Do we survey contributors through their accounts (email)? A: Yes, but it requires legal permission to email account holders. Been a year+ since we last did a contributor survey.
Q: Do we know specific things that drive traffic increases? 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.
Topic: Looking forward at 2018
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.
- ACTION [ali]: Add working session for MDN mission statement wording.
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.
Q: Is there a difference between use case oriented and action oriented? 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.
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.
Build samples into structured data for search results?
- ACTION [ali]: Add structured data in search results to working session list…
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
Theme for 2018: Making structured data available off of MDN (e.g. compatibility data).
Meggin is working on making a compatibility data extension for Chrome, similar to the one built by a contributor for Firefox. 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.
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.
Theme for 2018: Sustainability 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.
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.
MDN work structure
~10 Mozilla paid staff, 3 developers, product manager, content lead/writer, 3 content writers, project manager. ~ 1M$US budget Use budget for contractors, events, travel, etc.
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.
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.
Each sprint aims at delivering value (as - deployed on mdn), but features typically require several sprints for completion.
Also have an opportunity assessment process. The submission form is open to anyone, but mostly used by MDN contributors, also sometimes by other Mozilla employees. There is a weekly meeting 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.
The PAB input process is expected to be rolled into this existing system - with the Mozilla team owning the prioritization of the requests. One difficulty is how to include external contributors (especially volunteers) in sprints (mostly an issue for content, rather than the platform).
- ACTION [kadir] Share current opportunity backlog
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. Share sprint model with Google team
Q: Progressive Web Apps - question on where would this content live? 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.
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.
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.
Q: On MDN, how would users know the materials are up to date A: We need to have the internal resources/processes to do this.
Q: (following up): What is the long-term cost of content - creating it but also maintenance. 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.
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).
Priorities not included in the current roadmap:
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.
- ACTION [Chris]: Review adding Web Bluetooth, Midi to content roadmap
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.
- ACTION [Chris]: Follow up on reconsidering what page banners we show on MDN
Web Components for Microsoft. Probably be outside of the quarterly meetings, give a heads up about priorities.
- ACTION [Patrick]: Do some triage and get back to us.
Chrome status - can filter by usage, filter most used API’s for prioritization (chromestatus.com)
How do we manage PAB work?
Question for PAB: Should members come to each meeting with content priorities prepared for discussion? PAB Decision: Agreed to align content topic areas at quarterly meeting, members will bring priorities.
Question for PAB: Should we create a PAB repo on MDN GitHub and track work there. Use to publish meeting notes, etc. PAB Decision: yes, we will do this.
- ACTION [Dom] Create a (temporary) repo for the PAB and invite everyone on the board
- ACTION [ Kadir]: migrate temp PAB repo to main MDN.
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.
Making sure that what comes out of the PAB is rolled into the working cycle of MDN, specifically the opportunity reviews and work prioritization.
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
Also make sure that there is a way for people to surface things they want the board to review/cover/provide feedback on.
- ACTION [ali] Write up an Exec summary of changes or proposals in addition to detailed meeting notes.
- ACTION [ali]: provide a mechanism for MDN team/contributors to submit asks for the board ahead of meetings.
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.
Keep the action items in backlog for tracking purposes.
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.
Link to the projects.
List of lists in the repo
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.
The following sessions were prioritized & scheduled:
- Browser compat data, with some notes about Chinese browsers. Led by Robert, 1h
- Move MDN's backend functionality to GitHub. Led by Kadir + Meggin, 30 mins.
- Data outside of MDN, including devtools, lighthouse, search result rich snippets. Led by Meggin, 45 mins.
- Membership and revenue. Led by Ali, 45 mins.
- Wordsmithing the MDN mission statement. Led by Kadir, 30 mins.
- Running a joint Webdev conference. Led by Robert, 15 mins.
- W3C and MDN coordination, including W3C explainers, requirements process, notification of spec changes. Led by Dom, 1hr
The sessions we agreed would be good to potentially do later on are:
- EPUB docs. Led by Dom, 30 mins
- Localization and translation. Led by Kadir, 30 mins
- MDN as a source of developer feedback. Led by Chris, 30 mins
- Process for technical reviews, including using Google's process of notifying engineers when chrome status is updated.
- User and contributor surveys
- Web for all, best practices process and approach
- Style guides and page titles
- Landing page updates, to allow you to find APIs by task when you don't know what you're looking for
Robert have an update on a meeting between MDN (Jean Yves Perrier, Florian Scholz) and Google (Robert Nyman, Philip Jägenstedt (Foolip), Michael Yeung)
There are some obvious browsers to talk to, e.g. qq, uc
Worked with Alexis from CanIUse to get Chinese browser support implemented there. It's available now.
To do full testing, you generally need Chinese phones and browsers available from their app stores.
Chinese vendors want to feature more in the global space
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.
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.
- ACTION [Kadir/Robert] — see if the people who work on confluence/WPT could output the data in a useful format.
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.
We want to migrate all the compat data on MDN to machine-readable JSON on GitHub
We are currently 40% there (HTML, HTTP, JS built-ins all done, CSS mostly done). The large part — WebAPIs — is still mostly not done.
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.
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?
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.
Robert - if confluence could be a useful bridge between MDN and WPT, this would be a good thing.
Patrick - confluence seems to be meant for browser to browser data, rather than to developers , but it could still be useful.
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.
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. 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?
Mozilla: well duh
Chrome: mostly done already
Edge: Yep, we can, Erika said they were looking into a system to do it, e.g. automated as much as possible.
Samsung: Probably, need to discuss with team
- 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.
- ACTION [ Dan, Patrick/Erika, Meggin]: Designate a point person for compat data pull request reviews
- ACTION [Kadir]: Create an opportunity assessment item for adding a feedback mechanism on BCD tables so someone can easily report incorrect data.
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.
We should look to define guidelines on what "supported" means. What partial means, etc.
Core uses, edge case uses? Needs user testing/research?
- ACTION [Kadir] : Share these guidelines with the group (if they exist), get more feedback.
- ACTION [PAB follow up, Kadir]: Work out what we need to put in the support summary banners. Write plan, do user testing, etc.
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.
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.
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.
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.
ACTION [Kadir]: Look at how to do this
Start: "provide people with the information they need and teach them what they need to know to build delightful experiences on the open web."
We shouldn't say "browser", as this leaves out things like WoT, Node, etc.
Provide and teach are somewhat redundant
Should we say developers? No, as it cuts out other web creatives, eg designers
- Other suggested words: Inform, guide, teach, lead
- Inform and guide go well together
- Cross platform
- Reference and opinions
- Delightful - no, as this implies UX, awesome, etc.
- Good, Great? Usable? Accessible? First class? Splendid, superb, effective, powerful
Finish: "Inform and guide people with the most comprehensive information they need to build first class, cross-platform experiences on the open web."
Plus also provide a definition of first class.
- Community Engagement (e.g. people can track their MDN contributions, see what they've done eaily, put it on their CV/Resumé).
- Simplify contribution model?
- Removes anxiety about editing pages - changes not being available immediately...better curated.
- PR model allows/enforces reviewing, gets rid of spam.
- Integration with tooling (e.g. issue flagging)
- Easy cross-talk/linking between MDN and other related repos, etc. W3C/WHATWG.
- Discoverability
- 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.
- Raises the bar for casual contributors — might make them less likely to contribute.
- A lot more work needed to get changes published; having to review every change? We could have auto merge for trusted writers
- 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.
- Large amount of work for the MDN dev team to do the migration.
- 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.
Generally, all of the cons have mitigations. General consensus is to move forward with investigating.
Next steps:
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.
- 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.
- ACTION [Erika]: Erika to pull up information on what they went through when moving MS docs to GitHub.
- ACTION [Kadir]: Kadir to research pros & cons, including limits to access to Github (China, embargoed countries)
- ACTION [Kadir]: Get Meggin links to Kuma source code repo on Github
- 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
- ACTION [Kadir]: Kadir to scope the work with the dev team
- ACTION [Kadir]: Review findings, start process for deciding if we put this on the roadmap.
Opportunities for using data outside of MDN include Including devtools, lighthouse, extensions, search result rich snippets, other?
Q: What other MDN content could be interesting as standalone data? 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.
Opportunities:
-
Improve SEO
-
Rich snippets. Stack overflow bring their data into snippets, like other answers, popularity.
-
Could we include browser compat data? The short summary?
-
One box results - magic box in Google or Bing. How do we create those snippets?
-
Create cards
-
ACTION [Meggin/Robert]: find best practices for structured data for snippets
-
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.
-
ACTION [Kadir] - research how we should be presented in search results. See what we could include, what our competitors and other sites include, etc.
-
ACTION [Dan] - contact Daniel Davis at DuckDuckGo about their snippets - see how they do it.
-
ACTION [Patrick] - contract Bing to see how they do snippets.
Other things we could include:
- Syntax sections
- Short description
- Devtools integration - we already have an extension for Fx.
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
We could do a shield study to get feedback on the idea from Firefox dev tools developers.
- ACTION [Kadir]: to look into shield study
- ACTION [Meggin]: Look into creating Chrome version of the extension.
- ACTION [Patrick]: Look into creating Edge version of the extension.
- ACTION [Patrick]: intro Kadir to VSCode team
- ACTION [Kadir]: Check whether the business logic of the compat-report extension is separate - so it can be shared with other extensions. 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.
- ACTION [Meggin]: Create an issue with the lighthouse team to start discussion about general integration
- ACTION [Patrick]: Create an issue with the sonar team to start discussion about general integration
- ACTION [Kadir]: Rekindle conversations with other editors like Atom, Sublime, etc.
- ACTION [ Kadir] Talk to Fyrd about caniuse and MDN schema, would be great if we could all agree.
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).
Mozilla gives MDN a budget (and headcount) each year. If we want to go beyond that, we need to raise the funds.
Wikipedia-style pop up funding request banner - not paid, but request for contributions
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
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.
Q: Could you use contractor money just for platform dev stuff? A: Yes. We wouldn't want to limit it to this.
Q: So contractor money could come out of operating budget, not the donations? 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.
Q: Could we pay for volunteer work if they did ENOUGH work? A: Probably not - very hard to measure and assess. Unfair to the more casual contributors.
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).
"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.
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?
Ask if other companies would sponsor MDN?
Partnerships?
Corporate training?
MDN branded workshop days?
How about crowd-sourcing funding for specific features?
Feature bounty?
Backlog that can be paid for if people want them quickly
Sponsors page - platinum/gold/bronze level
Some tool creators even cold-call vendors that they know use their tool and ask for money
Micropayments with web payments (serves as demo + fundraiser). Did this content help you or meet your need? Give a dollar!
Buy/sponsor an API or feature?
Advertising in other places for the concept of MDN
"adopt a writer" $ for coffee
Reach out to amazon to see if they will sponsor us by paying some of our AWS bills.
Cross-vendor events
API card game (include API flashcards/data) - kickstarter to fund. Cute characters for each API. AR stickers.
- ACTION [ali]: Write this up into a format that we can evaluate more effectively.
- ACTION [ali]: put it in a doc and allow PAB/others to contribute
Robert has wanted to do this for a long time - all the browser vendor folks are passionate, and care about open web, standards, etc.
Something around the same size as View Source, done under the banner of MDN/Mozilla.
Attendees - who would typically attend this?
What kind of talks?
Show agreed-upon movement forward we agree on, e.g. PWAs
Do unconference sessions - get new ideas and feedback, work out what is and isn't working.
Present future ideas and technologies
Andrew Betts' Edge conference was great - half panels, half discussions
Alternatively we could also invite loads of people and do a fun community-building type conference
What if we had an unconference of experts combined with students - novices getting access to experts to learn, ask questions, etc.
It would be nice to present a unified front, rather than having people converging at Chrome's conference, or whatever.
If we did an unconference, it would be nice to work hard on inclusivity.
diversity scholarships at FFConf were a good idea.
We could also do student scholarships
We could have different tracks for learning material, expert material, future/evolution discussions
Or break it up into different foci on different days
- ACTION [Robert]: Start thread on PAB email list to carry on with this conversation.
Original charter was for meeting every quarter, 3 via conference call and one f2f per year (in December or January).
PAB Consensus: Would prefer to have more than onef2f meeting. Decision: Alternate the meetings - f2f, virtual, f2f, virtual. Also alternate f2f locations between North America and Europe. Discussion: Could have f2f meeting at TPAC in October (France), but generally feel this is a little late. 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).
Mozilla has a co-working space in Chicago we could use.
What about coinciding it with the dev rel summit?
Seattle could be cool. And we'd get MS folks?
Bay area might make sense too.
Dan needs to be in Boston to TAG in July, that could work, too.
- 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:
- ACTION [Meggin/Robert]: Find out if Google could host in Boston/Cambridge
- ACTION [Ali]: Find out if Mozilla could host if it’s elsewhere
- ACTION [Dom/Dan]: Look at hosting options at MIT.
Suggested next three meetings:
- Late March/early April Telco
- Late July F2F in the US
- October Telco with optional F2F at TPAC, Lyon
We decided to have a very quick conversation about this
How standardization changes should be communicated to MDN so we can update the docs
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.
This would also inform better naming conventions for things like API page titles, possibly? Get them straight from the WebIDL. Linting of doc titles?
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.
Feeding back examples into MDN for example. Or maybe explainer text?
Rather that hosting explainers on MDN, could we find a suitable way to link back to them?
Having explainers for things that haven't shipped yet is dangerous.
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.
What if we used a usability study model on experimental APIs?
Could we add this stuff to an existing tool or system like bikeshed?
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.
When you write docs, you will often come across bugs in specs, or at least, things that could be designed better. Even having a simple link on the specs to the relevant MDN pages would improve the feedback loop
- 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.
- ACTION [Kadir]: Start email item to further discuss getting feedback in APIs/usability studies?
- ACTION [Dom]: Set up a meeting to discuss the feedback loop further
- ACTION [Chris]: Give Dom ideas on standards/style guides for explanatory text in specs, examples in specs, what constitutes a good example.