<jorydotcom> @dom I have not gotten an email / link with the call info - is there somewhere I should be looking?
<jorydotcom> thank you!
<dom> OWD Impact and Transparency Report 2021
[Jory reviews https://
Jennie: thanks for the great intro
… how do you integrate Digital Accessibility best practices that you're producing?
… do you have a tagged version of the PDF available for review
Jory: we will make that available shortly - the version published was done in a rush
<Jennie2> Making Content Usable for People with Cognitive Disabilities: https://
Jennie: I'm part of the cognitive accessibility task force in W3C
… we've created documents on how to create more usable content for users with cognitive disabilities
… is that part of your approach?
jory: we've taken into account localization for instance - this is something we can add to our conversations in developing our project plans
dom: no systematic approach on this - clearly aligned with OWD charter https://
… some work done on information architecture is going in that direction, but this needs more attention
Jean-Yves: the move to github in markdown will help in identify systematic issues in the content
… we've already received contributions that remove assumption that something is "simple" thanks to the github setup
anssi: great work
… there is a lot of exciting opportunities to integrate W3C spec work and related documents incl MDN
… here is a concrete use case: a developer looking for info on an in-development API
… the info is scattered around: explainers, draft specs (with various level of introductory material), perhaps some early MDN documentation
… are there opportunities to re-use content
… geared towards understanding a new feature?
… sometimes there is duplication across these different efforts
jory: one of the things we ask a lot is at what point is it appropriate to start documenting something on MDN
… there is a risk to document things too early - then the documentation might be out of date quickly creating confusion
anssi: should there some sort of label for experimental features?
… MDN is the reference for many developers - if it doesn't exist there, it doesn't exist
… which may push people toward vendor-specific web sites
… whereas MDN or W3C would provide vendor neutral info
… I understand the cost of tracking experimental features
dom: this discussion comes up often.
… reuse of explainers in specs, but more rethinking to be done instead of copy-paste
… there has been early discussions in keeping track of what's happening in browser compat, keep track of the specs' status, etc.
… so, clearly there is work towards this direction
ericM: did you have a particular feature in mind?
anssi: not one in particular - but there are a number of new features where e.g. web.dev gets lots of search engine visibility
… I would prefer they get visibility in a more vendor neutral space
ericM: +1 on having MDN being the trusted foundation vs any one browser
… there is been a lot of discussions around this
… it hasn't gone live on MDN because until very recently there wasn't even experimental support in any browser
… it has just shipped behind a flag in safari
… there was a period where I had browser compat data that was just all "false"
… there was a strong sense that if it's not supported anywhere it shouldn't be in MDN
… to the risk that developers would assume MDN documents any "pie-of-the-sky" idea
… but how much implementation should exist before we start publishing documentation
… we're getting there with Temporal
… there is a real question of whether this is the point where we should put up that reference information
… as it becomes more and more supported, people are going to search looking for this
… more an art than a science
… might get earlier than a CSS feature only available in one preview browser without much interest from other vendors
… this has to be balanced with MDN being the place of reference where people want to find info on Web technologies, incl new ones
… no formal way to decide this
… As a contributor to MDN and an OWD SC, I would say that opening an issue on the mdn/content repo is probably the best way to raise a flag that MDN should document something
… this will prompt the right discussion and information gathering to happen
… and get a conclusion to emerge
anssi: another idea
… at early stage specs work, getting early feedback from developers can be a struggle
… would MDN be part of the solution in surfacing this and asking for developers feedback
dom: that's another topic discussed in MDN which outcome has been an accepted proposal: run short surveys for developers
… but this mechanism has not been used yet
… need to restart conversations
… yesterday, we had an intro to the dev council which is actually what you are trying to accomplish
… OWD does not have a direct say on what feedback mechanism could be put up on MDN.
… SC discussions to get going
jory: the MDN DNA survey couldn't run in 2021
… what Anssi is looking for wouldn't be part of what the DNA survey would collect
… we can bring this up with the MDN product team
… having ongoing shorter surveys would be a good way to go in that direction
… generally speaking, we work closely with the MDN product team - but naturally they have the final call on MDN
jory: thank you all for joining today and for the discussion
… please reach out to us on github or twitter, carrier pigeons - we'd love to have you more involved in open web docs