<scribe> scribenick: addison
(intros)
ali: explain the advisory
board
... what it does now
... save time for discussion
... as MDN transitions to be canonical web stds doc
... makes sense to bring in other groups in industry
... content prioritization and such on MDN site
... formed board a year ago
... google, msft, samsung, broader internet
... w3c, mozilla
... added bocoup
... purpose was mostly prioritization
... represent browser vendors and others
... board puts feelers out into other communities
... for example microsoft, or google team to get more content
into tools like lighthouse
... pull web paltform tests into documentation
... specifically with w3c
... work with andreas specifically
... talking to IMSC and epubs
... various specs and technologies
... good unforeseen effect
... areas we can make improvements in mdn
... have set of priorities personally
... "all have our own agendas" (nods to I18N)
... chinese use of mdn has grown exponentially
... 150-170% yoy growth
... want to better serve chinese community
... browser vendors but also users
... broadly internationalizing site more
... platform level stuff to make better experience than wiki
editing
patrick: microsoft excited
becayse like shared tests
... tabularized data at bottom or machine readible
... can have pop up that says "not supported in borwsers
targetted"
alex: that's overview
dom: w3c, one perspective
... understanding how we creat closer coordination
... between spec dev and documentation
... make sure doc refers to the right one
... some standards not covered in MDN
... made interesting progress
... interested in getting feedback o nhow to create closer
coord
... two faces of same coin
Boaz: work on PAB see canonical
mapping of webdev features to standards
... MDN holds framing how devs talk about it
... talk about webplat in different terms
... at Bocou talk about standards in diff way
@@@: any JS standard reference has a link back to the specific thing
scribe: is there something beyond that?
Boaz: no, that's what I'm looking
for
... might expose in a more like API
dom: first level, data about linking between specs
Joe: sort of
... only connection is table in MDN
... human readable not machine read
alex: we're puttinga plan
together for next year
... things to support Machine read
... piecemeal migrating chunks
... code samples.
... scannable
... broadly helpful
patrick: way to note request?
alex: file issue
<alis> https://github.com/mdn/pab
Joe: connecting features to spec does not feel like a BCD
alis: put link to advisory
board
... had all meeting notes
... also has issues
<dom> https://github.com/mdn/pab
MikeSmith: API requested, not
getting soon?
... team has priorites set for a while
... best long term is API
... did some work, forked BCD, all of it
... write script to scrape MDN
... extract links to specs
... under w3.org in github which has all spec urls
... loriann schultz, one spec / BCD feature
... methods with mutliple signatures, how you document that in
BCD without multiple spec URLS
<xfq> https://github.com/w3c/mdn-spec-links
<xfq> https://github.com/w3c/browser-compat-data
MikeSmith: talked about with
xxx
... for each js feature
... has 4 refs
... don't care about spec archaoology
... one canonical spec
joe: sounds good in theory
... features covered by multiple currently active specs
MikeSmith: out of englightened
self interest
... inject as part of build process
... inject from spec back to MDN
... 761 injected into HTML
... not just link to MDN
... but also the BCD table, support matrix not for every
browser but for same subset
... biz benefits
... look at coverage
... next step takes bcd and make json file in 210 specs
... a lot using tools, bikeshed, respec
... open automation so users don't have to do anything
... tool uses data from bcd
... get from tools for free
... all without API
... built on scraping
... as up to date as the scraper
... don't know how long to get away with it
alis: encourage skunkworks
joe: have pinged mdn urls
alis: on resource side mostly
solving that
... one thing we're looking at, how we fund mdn
... how we fund
... uping specifically how we get more machine-readable
... more mdn to github
... vs. wiki
... current wiki plaf is so unstable that everyone dedciated to
keeping running
... getting an actual API to data
... have to get to a state
... by end of 2019 have big chunk of data
boaz: that's cool
... semantic linking
... invest in how to maintain reationships
... between specs and docs
... we do a lot, specs to tests
... specifically for js
... in test262
... lot of submit info
... have feature tags which would be good to interop be same as
concepts in mdn
... not sure necessarily not just docs
... valuable diff spec and test writing entities
... this kind of mapping data set
... reflected in data set
rachel: one thing I do at MDN is
update contact data
... do on specs I know about well or am working on
... some specs better than others
... great if in MDN change made because test update
... know about layout and do ones I know about less good than
having relationship
... expose tests exists in MDN
... let devs know test exist, spur contribs
joe: doesn't just say T/F, but
specific version
... webplat tests may not provide?
boaz: do collect that data
joe: want to talk offline
boaz: not in github, we have
joe: have similar tool
... confluence
<dom> https://web-confluence.appspot.com/
boaz: more existential tests,
sees if API exists but not test surface area
... about 5-10% there
joe: chat offline
patrick: exposing tests
... hesistant, some have like 10K tests
... some have like 4 tests
... quality is all over map (general laughter)
... 10K but 9999 wrong or inconsequential
... as a non-chrome browser, hard to have a large red
number
... when not sure what means
<Zakim> r12a, you wanted to discuss i18n/a11y stuff
patrick: wptfyi proxy as quality a concern
joe: known issue with
confluence
... getting enormous number of false positive on chrome
... on chrome42
... traced to internal change in 42
boaz: can I respond?
dom: offline
alis: have conversation about
webplat tests everyt ime we meet
... lot of infra work needed
... great offline topic
rachel: if something chagnes
patrick: make a note
... reach out on github
... if you're not on all the time
<r12a> https://www.w3.org/International/articlelist
<Zakim> r12a-fallback, you wanted to discuss i18n/a11y stuff
<r12a> https://www.w3.org/International/techniques/authoring-html
richard: lots of articles in I18N
WG
... here's a list
... thing in second URL which is organized by task
... get lists of dos/don'ts
... docs we have (most that WE have)
... that help understand more
<r12a> https://www.w3.org/International/articles/vertical-text/index
richard: here's an example of how
to vertical text in CJKM
... we think this is good
... MDN may be unaware of it
... some things could use more of it
... want to direct authors to it
... we think web for all important and need more expose
... point to our articles, we have a review process and think
they are authoritative
... because a11y and i18n are things you should know
about
... not jsut "some links you could look at"
... really should know
... s o have proposal
<r12a> https://github.com/mdn/pab/issues/1
richard: possible me making this
go slow at moment
... it is issue #1 on your list (!!)
... like to set links on things like @dir and writing modes
property
... and to do so in section that's recognizable like "web for
all"
patrick: as separate section?
richard: having an extra box at bottom (penalty box)
patrick: concerned that it's be
unexpaned
... had a11y recently and got lots of feedback
... relegated to weird corner not helpful
richard: want to make clear is
can't put everythign in our articles into MDN page
... how do I do X or Y
... whether that's in body I'm open to discussion
alis: on one side, asked content
lead to put i18n on roadmpa
... doc on RTL is terrible
... enough changes that it makes sense to reexamine
... scope piece to figure out
patrick: chris mills has more
article like structure, good for posts on i18n
... more of a mindset rather than specifici api
rachel: did some guides on like CSS
alis: how to approach
... tutorials beyond just approach to specific specs
... so need multiple approaches not buried in one place
... get prioritized
... hack an MDN, did one in sept. for a11y
<rachelandrew> https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_Layout guides linked from the sidebar
alis: schedule a year of small
hack sessions at a11y confs
... one way to kickstart, actually schedule an i18n hacking
weekened
... 2-3 days to get bones in
... plaf pieces, get relevant people in room to get start
... some is pre-work
... defining the theme works well to get fron theory to
actual
patrick: having a contact point
<rachelandrew> another possibility, I've been doing a "CSS Layout Cookbook", quite nice for pulling together concepts based on real things people need to do https://developer.mozilla.org/en-US/docs/Web/CSS/Layout_cookbook
alis: chris and I will talk about
this and early coord and content writing
... 2 people on MDN team
richard: initial contact is just
me
... thx
patrick: lots of infra
comments
... how to handle i18n versions
alis: don't want to sacrifice i18n while moving to github
@@u: few months ago worked with MDN team
scribe: experience super good
helpful
... can also see resources are limited
... thought about how to amplify
... useful link for w3c to mdn
... lot of people can kick off
... does it make sense to give guidance or workshop?
... teach more people at once?
alis: good idea
... suspect some barrier is wiki itself
... it's challenging
... if you don't do MDN consistently it is daunting
... it's old and funky
... once moved to github we get vast increase in contribs
... also on code samples
... that's where people are comfortable
... shifting, one is machine read and two is
contributaiton
... get more people, linking between w3c and MDN, if all using
github easier
joe: those of us who have to keep
track, the shift from handbuilt tables to json files in a
github db
... I could quality check everyting
... fixed a lot of errors
... in MDN data this year
mikesmith: if we could talk about
going forward
... ideas about how to formalize "responsibilities"
... have a lot of people, a few editing
... take CSS, small number of editors
... lots in WG who look to contrib
... want to mvoe work forward
... if we could get WGs to assign resources
... get people to work on MDN docs for WGs
... few characteristics that are better contrib oppty
... also work on web tests
... learning curve is very large
... and review process is really tough
... like writing test but even scares me away
... as a contrib, in MDN no review process, just post
contrib
... with a like Chris Mills go fix something
... makes it easier
... editing a spec is a huge commitment
... chairing, writing tests, etc.
... have a lot of peope who could contri
... many people we could measure as a success metric
... comes down to webdevs using
... come to tpac and sit through entire session
... don't know how it'll solve
... but MDN can show how can actually use
... exploit oppts
... while learning, document
... many we can draw on
joe: one thing I'm doing to help
quality
... involve engineers in writing/review of features
... more frequently than you like engineer who wants to
editorialize
<alis> ali: for follow up or more questions/suggestions my contact info is aspivak@mozilla.com
boaz: feature policy and dev docs
examples in spec
... echo that
alis: dropped contact info in IRC
dom: also happy to be a
contact
... and Dan for TAG
... and patrick
... not end of conversation!