BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Sabre//Sabre VObject 4.5.8//EN
CALSCALE:GREGORIAN
LAST-MODIFIED:20241002T122509Z
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
X-MICROSOFT-CDO-TZID:13
BEGIN:STANDARD
DTSTART:20231105T090000
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
END:STANDARD
BEGIN:STANDARD
DTSTART:20241103T090000
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20240310T100000
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:149479a7-9125-4287-99ba-618acacaffbb
DTSTAMP:20241002T122509Z
SUMMARY:Curating the web platform's data and documentation
DTSTART;TZID=America/Los_Angeles:20240925T111500
DTEND;TZID=America/Los_Angeles:20240925T121500
DESCRIPTION:https://www.w3.org/events/meetings/149479a7-9125-4287-99ba-618a
 cacaffbb/\n\n[Open Web Docs](https://openwebdocs.org) is a nonprofit open 
 collective that curates web platform documentation and data for the benefi
 t of web developers and the ecosystem's tooling. In this session we want t
 o talk about how we work and how you (as a spec editor or implementer) can
  collaborate with us.\n\nWe want to talk about how specs and web platform 
 features go through a "pipeline" of repositories and why that is important
  for us as documentation and data curators.\n\n1. A new spec gets authored
  and picked up by: https://github.com/w3c/browser-specs \n2. Spec definiti
 ons and in particular IDL definitions get parsed by reffy and https://gith
 ub.com/w3c/webref\n3. Web platform features get identified from webref and
  continuously tested by https://github.com/openwebdocs/mdn-bcd-collector\n
 4. If a browser ships an identified feature\, https://github.com/openwebdo
 cs/mdn-bcd-collector signals that to https://github.com/mdn/browser-compat
 -data\n5. https://github.com/mdn/browser-compat-data gets released and spr
 eads the information to MDN\, caniuse\, caniwebview\, linters\, specs\, ot
 her tooling and reporting.\n6. At this stage\, the feature is also marked 
 in need of technical documentation via https://openwebdocs.github.io/web-d
 ocs-backlog/\n7. https://github.com/web-platform-dx/web-features defines a
  feature id for the new feature and calculates a "baseline" status allowin
 g it to be talked about in a consistent way in even more places.\n8.  Web 
 developers start using the feature more broadly and adapt it as the featur
 e hopefully transitions to "baseline high" over the course of the next few
  months.\n9. (if the feature gets deprecated and we take steps to signal t
 o users to move off of it again)\n\nThere is probably more to it but this 
 should give you an idea of our "pipeline". The above is sort of the "golde
 n path". Of course\, things can go sideways in several ways and\, in the w
 orst case\, that will lead to non-existing docs and compat data:\n\n- Spec
 s don't make it into the browser-specs repo or don't have standing: good\n
 - Browsers implement things without a spec and we have to maintain custom 
 IDL files and document features as non-standard\n- Features are specced bu
 t never see implementation (we shy away from curating these\, "spec fictio
 n").\n- Features sit behind a flag for a long time (and change drastically
 \, so we don't curate docs and data until we have been promised with _some
 _ stability)\n- Bugs in any of the above repositories\n- Shortage of maint
 ainers\, technical writers\, developers\, curators\, in any of the reposit
 ories.\n\nAgenda\n\n**Chairs:**\nFlorian Scholz\, Will Bamberg\, Estelle W
 eyl\, Vinyl Da.i'gyu-Kazotetsu\n\n**Description:**\n[Open Web Docs](https:
 //openwebdocs.org) is a nonprofit open collective that curates web platfor
 m documentation and data for the benefit of web developers and the ecosyst
 em's tooling. In this session we want to talk about how we work and how yo
 u (as a spec editor or implementer) can collaborate with us.\n\nWe want to
  talk about how specs and web platform features go through a "pipeline" of
  repositories and why that is important for us as documentation and data c
 urators.\n\n1. A new spec gets authored and picked up by: https://github.c
 om/w3c/browser-specs \n2. Spec definitions and in particular IDL definitio
 ns get parsed by reffy and https://github.com/w3c/webref\n3. Web platform 
 features get identified from webref and continuously tested by https://git
 hub.com/openwebdocs/mdn-bcd-collector\n4. If a browser ships an identified
  feature\, https://github.com/openwebdocs/mdn-bcd-collector signals that t
 o https://github.com/mdn/browser-compat-data\n5. https://github.com/mdn/br
 owser-compat-data gets released and spreads the information to MDN\, caniu
 se\, caniwebview\, linters\, specs\, other tooling and reporting.\n6. At t
 his stage\, the feature is also marked in need of technical documentation 
 via https://openwebdocs.github.io/web-docs-backlog/\n7. https://github.com
 /web-platform-dx/web-features defines a feature id for the new feature and
  calculates a "baseline" status allowing it to be talked about in a consis
 tent way in even more places.\n8.  Web developers start using the feature 
 more broadly and adapt it as the feature hopefully transitions to "baselin
 e high" over the course of the next few months.\n9. (if the feature gets d
 eprecated and we take steps to signal to users to move off of it again)\n\
 nThere is probably more to it but this should give you an idea of our "pip
 eline". The above is sort of the "golden path". Of course\, things can go 
 sideways in several ways and\, in the worst case\, that will lead to non-e
 xisting docs and compat data:\n\n- Specs don't make it into the browser-sp
 ecs repo or don't have standing: good\n- Browsers implement things without
  a spec and we have to maintain custom IDL files and document features as 
 non-standard\n- Features are specced but never see implementation (we shy 
 away from curating these\, "spec fiction").\n- Features sit behind a flag 
 for a long time (and change drastically\, so we don't curate docs and data
  until we have been promised with _some_ stability)\n- Bugs in any of the 
 above repositories\n- Shortage of maintainers\, technical writers\, develo
 pers\, curators\, in any of the repositories.\n\n**Goal(s):**\nDiscussing 
 curation of documentation\, compatibility data. Exchanging feedback among 
 repo maintainers\n\n\n**Agenda:**\n1. Short presentation about OWD's web p
 latform data and documentation curation pipeline\n2. Discussion\n\n**Mater
 ials:**\n- [minutes](https://www.w3.org/2024/09/25-openwebdocs-minutes.htm
 l)\n- [Session proposal on GitHub](https://github.com/w3c/tpac2024-breakou
 ts/issues/34)\n\n**Track(s):**\n- Feature lifecycle
STATUS:CONFIRMED
CREATED:20240916T215143Z
LAST-MODIFIED:20241002T122509Z
SEQUENCE:1
ORGANIZER;CN=W3C Calendar;PARTSTAT=ACCEPTED;ROLE=NON-PARTICIPANT:mailto:nor
 eply@w3.org
LOCATION:-1 Lower Level - Catalina 1
CATEGORIES:TPAC 2024,Breakout Sessions
END:VEVENT
END:VCALENDAR