BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Sabre//Sabre VObject 4.5.8//EN
CALSCALE:GREGORIAN
LAST-MODIFIED:20230921T103632Z
BEGIN:VTIMEZONE
TZID:Europe/Madrid
BEGIN:STANDARD
DTSTART:20221030T010000
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
END:STANDARD
BEGIN:STANDARD
DTSTART:20231029T010000
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20230326T010000
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:6047d4b8-20ae-4909-8868-696b14a213ff
DTSTAMP:20230921T103632Z
SUMMARY:Tracking spec maintenance
DTSTART;TZID=Europe/Madrid:20230913T121500
DTEND;TZID=Europe/Madrid:20230913T131500
DESCRIPTION:https://www.w3.org/events/meetings/6047d4b8-20ae-4909-8868-696b
 14a213ff/\n\nThe web platform includes [lots of specifications](https://gi
 thub.com/w3c/browser-specs/blob/main/specs.json)\, and we don't have an ea
 sy way of distinguishing the ones that are adequately maintained\, vs the 
 ones that need more investment. \n\n\n\nSome considerations include (but a
 ren't limited to):\n\n\n\n* Stable specs might not need much investment fo
 r long periods of time.\n\n* We should include specs that have only one im
 plementation\, so that:\n\n   * If a group starts showing interest in writ
 ing a second implementation\, their issues should be very visible.\n\n* Sp
 ecs should triage issues fairly quickly\, but it could be ok for low prior
 ity issues to sit around.\n\n* We probably need a [consistent set of label
 s](https://w3c.github.io/issue-metadata.html).\n\n* Chrome needs to do a l
 ot of the maintenance\, but the whole community should buy into the system
  and see the results.\n\n\n\nFuture discussion will happen on the [spec-pr
 od@w3.org mailing list](https://lists.w3.org/Archives/Public/spec-prod/).\
 n\nAgenda: https://github.com/jyasskin/spec-maintenance/blob/main/meetings
 /2023-tpac/agenda.md\n\nAgenda\n\n**Chairs:**\nJeffrey Yasskin\n\n**Descri
 ption:**\nThe web platform includes [lots of specifications](https://githu
 b.com/w3c/browser-specs/blob/main/specs.json)\, and we don't have an easy 
 way of distinguishing the ones that are adequately maintained\, vs the one
 s that need more investment. \n\n\n\nSome considerations include (but aren
 't limited to):\n\n\n\n* Stable specs might not need much investment for l
 ong periods of time.\n\n* We should include specs that have only one imple
 mentation\, so that:\n\n   * If a group starts showing interest in writing
  a second implementation\, their issues should be very visible.\n\n* Specs
  should triage issues fairly quickly\, but it could be ok for low priority
  issues to sit around.\n\n* We probably need a [consistent set of labels](
 https://w3c.github.io/issue-metadata.html).\n\n* Chrome needs to do a lot 
 of the maintenance\, but the whole community should buy into the system an
 d see the results.\n\n\n\nFuture discussion will happen on the [spec-prod@
 w3.org mailing list](https://lists.w3.org/Archives/Public/spec-prod/).\n\n
 **Goal(s):**\nSketch a plan to sustainably identify specs that are falling
  behind on their maintenance needs\n\n\n**Materials:**\n- [slides](https:/
 /jyasskin.github.io/spec-maintenance/meetings/2023-tpac/slides.html)\n- [m
 inutes](https://www.w3.org/2023/09/13-spec-maintenance-minutes.html)\n- [b
 rainstorming results](https://github.com/jyasskin/spec-maintenance/blob/ma
 in/meetings/2023-tpac/brainstorm.md)\n- [Session proposal on GitHub](https
 ://github.com/w3c/tpac2023-breakouts/issues/59)\n\n**Track(s):**\n- gettin
 g work done
STATUS:CONFIRMED
CREATED:20230905T054029Z
LAST-MODIFIED:20230921T103632Z
SEQUENCE:1
ORGANIZER;CN=W3C Calendar;PARTSTAT=ACCEPTED;ROLE=NON-PARTICIPANT:mailto:nor
 eply@w3.org
LOCATION:Magnolia - Low Level
CATEGORIES:TPAC 2023,Breakout Sessions
END:VEVENT
END:VCALENDAR