https://www.w3.org/wiki/api.php?action=feedcontributions&feedformat=atom&user=PlehegarW3C Wiki - User contributions [en]2024-03-29T10:48:50ZUser contributionsMediaWiki 1.41.0https://www.w3.org/wiki/index.php?title=TPAC/2022/SessionIdeas&diff=115037TPAC/2022/SessionIdeas2022-09-01T20:17:48Z<p>Plehegar: /* Antifraud Discussion */</p>
<hr />
<div>You are invited to propose [https://www.w3.org/2022/09/TPAC/ TPAC 2022] '''Breakout Sessions''' in advance of breakout day on September 14, 2022. <br />
Please contact dom@w3.org for any question regarding the organization of TPAC breakouts.<br />
<br />
TPAC 2022 is a hybrid meeting: all breakouts will have both a physical and a virtual component: they'll each be assigned a room in the event venue, and will be assigned a Zoom teleconference plugged into that room. <br/><br />
Breakouts that are requested to be public will be open to anyone to join remotely, free of charge, without a TPAC registration. The public can (but doesn't have) to [https://ti.to/w3c/tpac-2022-public-breakouts register online] to be kept up to date on new information about breakouts (including when their schedules will be finalized).<br />
<br />
<div style="float:right;clear:right">__TOC__</div><br />
<br />
== How to use this page ==<br />
<br />
Please use this page to:<br />
<br />
* Propose sessions you wish to lead<br />
* '''Please place new proposals at the bottom of this document'''<br />
<br />
== Breakouts scheduling ==<br />
Breakouts are scheduled the Vancouver-time afternoon of September 14, 2022. There are 4 x 1h-slots (11:15am, 1:30pm, 3pm, 4:30pm PT), with up to 15 sessions possible during each slot, for a total of 60 potential breakouts.<br />
<br />
The exact time of each breakout will be determined by the staff to reduce overlap of sessions with similar expected participants. We expect an initial schedule of submitted breakouts to be made available on September 9.<br />
<br />
== How to propose a session ==<br />
<br />
Please provide:<br />
<ul class="show_items"><br />
* session name (as a === subhead === )<br />
* session facilitators and speakers and which will be physically present vs remote<br />
* one sentence session summary<br />
* type of session: (e.g.: open discussion, talk, panel, tutorial, demo, etc.)<br />
* goals of session - what outcomes can session participants expect?<br />
* is this breakout only for TPAC participants or should it be open to anyone? (public TPAC breakouts can be attended remotely free of charge by anyone)<br />
* a shortname that can be used to associate an IRC channel to your breakout<br />
* Optional: constraints on timeslots (11:15am, 1:30pm, 3pm, 4:30pm Pacific Time)<br />
</ul><br />
<br />
== Breakout facilitator preparation ==<br />
<br />
If you are organizing a TPAC breakout, you may benefit from the following materials to get ready:<br />
* [https://www.w3.org/2021/10/TPAC/breakouts.html Proceedings from TPAC 2021 breakouts] [https://www.w3.org/2020/10/TPAC/breakout-schedule.html#details 2020] [https://w3c.github.io/tpac-breakouts/sessions.html 2019]<br />
* [https://www.w3.org/WAI/teach-advocate/accessible-presentations/ How to Make Your Presentations and Meetings Accessible to All ]<br />
* [https://www.w3.org/2021/10/TPAC/demos/inclusive-facilitation.html Inclusive Facilitation Training]<br />
== Proposed sessions ==<br />
<br />
=== Web Components Community Group API and Specs Report 2022 ===<br />
* facilitators: Westbrook Johnson, Owen Buckley, Rob Eisenberg<br />
* summary: The Web Components CG will facilitate a discussion with implementers and community members about filling browser gaps in agreed upon features and moving forward with the next wave of top priority features.<br />
* type of session: open discussion<br />
* goals of session:<br />
** Getting APIs missing full x-browser support into the "Interop 2023" campaign?<br />
** Discuss how we can work more closely on high important capabilities: cross shadow root Aria, scoped registries, DSD<br />
** Expand implementer and developer partnerships around bringing APIs & specs to the browser.<br />
* open to public<br />
* shortname: webcomponent-cg<br />
* preferred time: 4:30pm Pacific Time<br />
<br />
=== Network State/Cache Partitioning Designs ===<br />
* facilitators: Mike Taylor, Artur Janc (both physically there)<br />
* type of session (e.g.: open discussion, talk, panel, etc.): presenting some data from recent triple-key experiments for network state partitioning in Chrome followed by discussion<br />
* goals of session: discuss the security, privacy, and performance implications from partitioning the HTTP cache and shared network connections, and seek input from other implementer's experience<br />
* open to the public<br />
* shortname: nsp-designs<br />
<br />
=== IP address privacy ===<br />
* Summary (one-sentence or so): IP address is a highly identifiable signal used for cross-site identity joining i.e. tracking users. A proposal for mitigation.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): short talk followed by discussion<br />
* Goals: share Chrome's high-level early thinking on IP protection, and get feedback<br />
* ip-privacy<br />
* Additional speakers/panelists: jongibson@google.com<br />
* open to the public<br />
<br />
=== Accessibility at the Edge ===<br />
* Proposer: Janina Sajka<br />
* Email address of proposer: janina@rednote.net<br />
* session facilitators Janina Sajka, Lionel Wolberger (Both present)<br />
* Other Panelists: Manu Sporny (present); Ken Nakata, Alisa Smith (Remote); Others TBD<br />
* Summary: A feerless overview of current and prospective edge technologies application to enhance accessibility (including those highly controversial overlays)<br />
* type of session: Brief panel remarks followed by open discussion<br />
* goals of session: Kick-off event for the new A11yEdge Community Group; What we will address, what we hope to achieve <br />
* Open to the public<br />
* Shortname: A11yEdge<br />
<br />
=== Page transitions in the browser (Shared Element Transitions) ===<br />
* Proposer: Jake Archibald<br />
* Email address of proposer: jakearchibald@google.com<br />
* Summary: Chromium folks have been working within the CSSWG to give developers an easy way to create page transitions. We'd like to show how it works, and get feedback from implementers, spec folks, and other interested parties.<br />
* Type of session: Open discussion, but can be a talk if the audience would rather.<br />
* Goals: Get feedback.<br />
* shortname: pagetransitions<br />
* [optional] Additional speakers/panelists:<br />
* Open to the public<br />
<br />
=== Web of Things (WoT) Status Update and Demos ===<br />
* Proposer: [[User:Mmccool|Michael McCool]] ([[User talk:Mmccool|talk]]) 17:17, 16 August 2022 (UTC)<br />
* Email address of proposer: michael.mccool@intel.com<br />
* Summary (one-sentence or so): Present the current status of the Web of Things in the WoT IG/WG and CGs, and showcase a number of application demonstrations.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): sequence of short presentations (status, then 3-4 demos)<br />
* Goals: Introduce people to WoT and showcase application experience.<br />
* wot-demo (used for minting an IRC channel for the breakout)<br />
* limited to TPAC participants or open to the public? Open to the public.<br />
* Timeslot constraints: 3pm PT strongly preferred (note: many of our speakers will be remote and calling in from Asia and Europe. This is the only slot that is not horribly early or late in Asia or Europe)<br />
<br />
=== Breaking the web responsibly ===<br />
* Proposer: Greg Whitworth<br />
* Email address of proposer: gwhitworth@salesforce.com<br />
* Summary (one-sentence or so): Go over how User Agent breaking changes can have adverse effects on users due to the time needed for sites to adjust to the changes.<br />
* Type of session (e.g.: open discussion, talk, panel, etc): Talk + Open Discussion<br />
* Goals: How can the community work together to responsibly rollout impactful changes<br />
* shortname (used for minting an IRC channel for the breakout): ua-impactful-changes<br />
* limited to TPAC participants or open to the public?<br />
* Timeslot constraints: 1:30PM<br />
<br />
=== Open UI update on style-able & extensible HTML controls/components ===<br />
* Proposer: Greg Whitworth<br />
* Email address of proposer: gwhitworth@salesforce.com<br />
* Summary (one-sentence or so): One of the largest developer pain points is styling/modifying the content of the controls/components that ship natively with the user-agent. Open UI will provide an update on the progress on new elements and primitives to improve this.<br />
* Type of session (e.g.: open discussion, talk, panel, etc): Talk<br />
* Goals: Give an overview of Open UI it's goals and the progress over the past year.<br />
* shortname (used for minting an IRC channel for the breakout): openui<br />
* limited to TPAC participants or open to the public?<br />
* Additional speakers/panelists: Mason Freed, Brian Kardell, Daniel Clark<br />
* Timeslot constraints: 3:30PM<br />
<br />
=== Children's Accessibility Needs Require Specific Consideration ===<br />
* Proposer: [[User:Suzanne|Suzanne Taylor]] ([[User talk:Suzanne|talk]]) 19:26, 16 August 2022 (UTC)<br />
* Email address of proposer: Suzanne.Taylor@ThingsEntertainment.net and maud.stiernet@alittleliningcomes.com <br />
* Summary (one-sentence or so): We will share the 6 main reasons that children with disabilities will benefit from specific consideration in next-generation accessibility standards.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): 30-minute talk followed by 30 minutes for discussion<br />
* Goals: Provide an update on the work and goals of the Accessibility for Children Community Group, which has been active for about a year. Share the 6 main reasons that children with disabilities will benefit from specific consideration in next-generation accessibility standards.<br />
* a11y4kids<br />
* Additional speakers/panelists: Maud Stiernet<br />
* Open to Public<br />
* Timeslot constraints: Because Maud will be in Belgium, 1:30 pm PT would work best<br />
<br />
=== The Future of Cookies ===<br />
* Proposer: [[User:Johannh|Johann Hofmann]] ([[User talk:Johannh|talk]]) 19:47, 16 August 2022 (UTC)<br />
* Email address of proposer: johannhof@chromium.org<br />
* Summary (one-sentence or so): Some big changes to how cookies work in browsers make us rethink how Fetch and HTML integrate with the cookies RFC and whether more cookie behavior could be defined in browser land. Join us to learn about and discuss the future of cookies in standards!<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Short talk + open discussion<br />
* Goals: Give an overview of recent and upcoming cookies changes and get feedback on our ideas for evolving cookie specification across organizations.<br />
* shortname (used for minting an IRC channel for the breakout): cookie-future<br />
* Additional speakers/panelists: Steven Bingler, Anne van Kesteren, others TBC<br />
* limited to TPAC participants or open to the public? Open to public<br />
* [optional] Timeslot constraints: (3 possible slots: 1:30pm PT, 3pm PT, 4:30pm PT) 3pm, should not conflict with "Same Party Federation"<br />
<br />
=== Policy Protected Data Access for Untrusted Components ===<br />
* Proposer: [[User:Sarahheimlich|Sarah Heimlich]] ([[User talk:Sarahheimlich|talk]]) 23:58, 16 August 2022 (UTC)<br />
* Email address of proposer: sarahheimlich@google.com<br />
* Summary (one-sentence or so): Discussion on a system where untrusted modular components can access private user data through policy protection and enforcement. Join us to play with prototypes and learn more!<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Open Discussion<br />
* Goals: Give an overview of the system through demos/prototypes and get feedback on our ideas for a policy-driven privacy framework.<br />
* shortname: policy-privacy<br />
* [optional] Additional speakers/panelists: Maria Kleiner, Ray Cromwell, and Bernhard Seefeld<br />
* limited to TPAC participants or open to the public?: Open to the public<br />
* [optional] Timeslot constraints: None<br />
<br />
=== Member Support by W3C ===<br />
* Proposer: [[User:Naomi|Naomi Yoshizawa]] ([[User talk:Naomi|talk]]) 03:15, 17 August 2022 (UTC)Naomi Yoshizawa<br />
* Email address of proposer: naomi@w3.org<br />
* Summary (one-sentence or so): Introducing W3C member support activities to date and brainstorm what type of member support will be required at the new W3C to hear members' voices.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): short talks followed by panel and open discussion<br />
* Goals: Discover the form of member support that W3C, a membership organization, should achieve.<br />
* shortname (used for minting an IRC channel for the breakout): member-support<br />
* [optional] Additional speakers/panelists: Giorgio Mazzucchelli, Amanda Mace, Rachel Yager, Wonsuk Lee<br />
* limited to TPAC participants or open to the public?: TPAC participants<br />
* [optional] Timeslot constraints: can't specify as remote participants gather from all over the world<br />
<br />
=== W3C Accessibility Maturity Model ===<br />
* Proposer: [[User:Helixopp|David Fazio]] ([[User talk:Helixopp|talk]]) 05:45, 17 August 2022 (UTC) <br />
* Email address of proposer: dfazio@helixopp.com <br />
* Summary: Presentation of the W3C Accessibility Maturity Model First Public Working Draft. <br />
* Type of session: Presentation and Open Discussion <br />
* Goals:<br />
* shortname: a11y Maturity<br />
* [optional] Additional speakers/panelists: DAVID FAZIO, Janina Sajka, Sheri Byrne-Haber<br />
* Open to the public.<br />
* Timeslot constraints: None<br />
<br />
=== Web Monetization ===<br />
* Proposer: [[User:laka|Alex Lakatos]]<br />
* Email address of proposer: alex@interledger.org<br />
* Summary: Very short presentation of the changes to the Web Monetization community specification draft and gather feedback.<br />
* Type of session: Short Presentation and Open Discussion <br />
* Goals: Consulting W3C Members & gathering feedback for the new spec.<br />
* Open to the public.<br />
* shortname: web-monetization<br />
<br />
=== Trusted Internet ===<br />
* Proposer: [[User:takuya|Takuya Sakamoto]] ([[User talk:takuya|talk]]), [[User:shigeya|Shigeya Suzuki]] 01:21, 18 August 2022 (UTC)<br />
* Email address of proposer: takuya@fujitsu.com, shigeya@wide.ad.jp<br />
* Summary: Give short presentation of overview on Trusted Internet that makes arbitrary data verifiable on the Internet, discuss and gather feedback.<br />
* Type of session: Presentation and Open Discussion <br />
* Goals: To find partners to discuss it with.<br />
* Open to the public.<br />
* shortname: trusted-internet<br />
* Timeslot constraints: 4:30pm preferred<br />
<br />
=== Architecting for Privacy, Media Accessibility and Product development: the video element ===<br />
<br />
* Proposer: [[User:nigelmegitt|Nigel Megitt]], email: nigel.megitt@bbc.co.uk<br />
* Summary: Think about architectural models for allowing user accessibility choices while maintaining privacy and providing data to support product development, with reference to the video element in particular.<br />
* Type of session: Short talk and presentation followed by open discussion<br />
* Goals: Understand what architectural pattern(s) can allow user choices without exposing additional fingerprinting vectors or increasing privacy risks, while also providing usable product data.<br />
* Open to anyone<br />
* shortname: private-a11y<br />
* Constraints on timeslots: none so far<br />
<br />
=== U.S. Digital Accessibility Apprenticeship Program ===<br />
* Proposer: [[User:Helixopp|David Fazio]] ([[User talk:Helixopp|talk]]) 18:01, 18 August 2022 (UTC) <br />
* Email address of proposer: dfazio@helixopp.com <br />
* Summary: Presentation & tutorial on the ne Digital Accessibility Apprenticeship Program, funded, and governed by the U.S. Department of Labor. <br />
* Type of session: Presentation, Tutorial, and Open Discussion <br />
* Goals: Demystify what Apprenticeship means, funding available, how companies can participate. Present the newly established Digital Accessibility Apprenticeship, developed by Helix Opportunity with the U.S Department of Labor.<br />
* shortname: a11y Maturity<br />
* [optional] Additional speakers/panelists: David Fazio, Representative from the Division of Apprenticeship Standards <br />
* Open to the public.<br />
* Timeslot constraints: None<br />
<br />
=== Web-based Digital Twins for Smart Cities ===<br />
* Proposer: Kazuyuki Ashimura<br />
* Email address of proposer: ashimura@w3.org<br />
* Summary (one-sentence or so): Discussion on Digital-twin services for Smart Cities specifilally about (1) what is already done by whom (SDOs, vendors, governments, etc.) in which area, (2) what is still missing for expected Web-based Smart Cities, and (3) who and how to lead the discussion to resolve the gaps.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): talk + open discussion<br />
* Goals: Identify the most important categories of problems to implement actual Smart Cities based on the exisitng and near future Web standards<br />
* shortname: smartcities<br />
* limited to TPAC participants or open to the public? Open to the public.<br />
* Timeslot constraints: 4:30pm strongly preferred<br />
** many of our speakers will be remote and calling in from Asia and Europe.<br />
** Also need to avoid the overlap with the [https://www.w3.org/wiki/TPAC/2022/SessionIdeas#Web_of_Things_.28WoT.29_Status_Update_and_Demos WoT demo session].<br />
<br />
=== WAI-Adapt Candidate Recommendation of Content Module 1.0: Overview ===<br />
* Proposer: [[User:Lwolberg|Lionel Wolberger]]<br />
* Email address of proposer: lionel@userway.org<br />
* Summary: WAI-Adapt Content specification enables web content authors to support persons with various cognitive and learning disabilities, including users who need from more familiar icons (and other graphical symbols) in order to comprehend page content, require a simplified page in order to interact successfully, and/or communicate using symbolic languages generally known as Augmentative and Alternative Communications (AAC).<br />
* Type of session: short talk followed by discussion<br />
* Goals: socialize the specification as we are in Candidate Recommendation status<br />
* Additional speakers/panelists: TBD<br />
* open to the public<br />
<br />
=== VTT-based Audio Descriptions for Media Accessibility ===<br />
<br />
* Proposer: Eric Carlson (in-person), [[User:jcraig|James Craig]] (in-person), <br />
* Summary: Both Chromium and WebKit are prototyping support for text-based audio descriptions published as VTT. Come view a demo, discuss known issues, and share your feedback, opinions, and advice on this emerging technology.<br />
* Type of session: Brief preso and prototype demo, followed by open discussion.<br />
* Goals: Seeking opinions on technology and implementation, including usability feedback and opinions from regular users of audio description.<br />
* Open to anyone<br />
* IRC Channel: #audio-descriptions <br />
* Constraints on timeslots: Session should not conflict with other media captions/descriptions/video breakouts, like Nigel's listed above. Perhaps also the "Edge" discussion.<br />
<br />
=== FedCM: where we are and what comes next ===<br />
<br />
* Proposer: Sam Goto<br />
* Invited: FedID CG, Privacy CG, WICG <br />
* Email address of proposer: goto@google.com<br />
* Summary: a report on where things are (production experience, browser interoperability, ecosystem feedback), some immediate next steps (the timing attack problem, multiple IDP account choosers) and some paths we could take (e.g. same party federation? see session below) <br />
* type of session: presentation followed by open discussion<br />
* goals of session: raise awareness and discussions across community groups (Storage Access API, First Party Sets, Login Status API, mDL API, VCs, DIDs, etc), understand where browser vendors stand (e.g. mozilla started implementing, safari is generally supportive - what's next, edge/brave/opera?) and how to help each other (e.g. any concerns? suggestions? recommendations? web platform tests?), <br />
* Open to the public.<br />
* Timeslot constraints: not conflict with the Same Party Federation Session. <br />
* Shortname: FedCM<br />
<br />
=== Same Party Federation (SSO) ===<br />
<br />
* Proposer: Sam Goto / Johann Hofmann<br />
* Invited: FedID CG, Privacy CG, WICG<br />
* Email address of proposer: goto@google.com<br />
* Summary: Short and long term, how should login to X with (an associated) Y work? e.g. login to instagram.com with facebook.com, audible.com with amazon.com, youtube.com with google.com and xbox.com/office.com with microsoft.com. Explicitly out of scope of the discussion: ccTLDs X/Y (e.g. login to example.ca with example.co.uk) and other FPS subsets.<br />
* type of session: open discussion<br />
* goals of session: gather UX considerations (prompts? auto-grant?), API considerations (e.g. Storage Access API?, First Party Sets?, FedCM?) and deployment considerations (e.g. what's the cardinality of these sets?).<br />
* Open to the public.<br />
* Timeslot constraints: 1:30pm, not conflicting with the FedCM breakout or the Future of Cookies session.<br />
* Shortname: SamePartyFederation<br />
<br />
=== Migrating Multi-Screen Window Placement Spec Content ===<br />
<br />
* Facilitator: [[User:msw|Mike Wasserman]], email: <msw@google.com> (physically present)<br />
* Invited: Second Screen WG & CG, CSS WG, anyone familiar with WHATWG's HTML and Fullscreen Specs<br />
* Summary: The [Multi-Screen Window Placement](https://w3c.github.io/window-placement/) spec extends CSSOM-View, Fullscreen, and HTML definitions for multi-screen visual workspace support. We'll discuss alignment and migration of spec content to existing established specifications.<br />
* type of session: short presentation and open discussion<br />
* goals of session: Socialize [https://w3c.github.io/window-placement multi-screen window placement] spec content, explore alignment with established specs, define followup work items and opportunities.<br />
* Open to anyone<br />
* Shortname: window-placement (or multi-screen, or multi-screen-window-placement)<br />
* Timeslot constraints: Not conflicting with Second Screen WG nor CSS WG meetings.<br />
<br />
=== WebViews - Usages & Challenges ===<br />
<br />
* Proposer: Rayan Kanso<br />
* Email address of proposer: rayankans@google.com<br />
* Session facilitators: rayankans@google.com (present), anqing.aq@alibaba-inc.com (remote)<br />
* Summary: Present the findings of the WebView CG & have an open discussion on further use-cases and challenges<br />
* Type: brief presentation + open discussion<br />
* Goals: Collect opinions & feedback on the report.<br />
* Open to the public<br />
* Shortname: webview-cg<br />
* Timeslot constraints: None<br />
<br />
=== Common Impact Data Standard ===<br />
<br />
* Proposer: Alicia Richins<br />
* Email: alicia.richins@commonapproach.org<br />
* Summary: An introduction to the Common Impact Data Standard (CIDS), including an overview of the impact measurement space, the social purpose ecosystem and the challenges that CIDS is designed to solve. We will discuss the technical specification and the possibility of a dedicated Working Group.<br />
* Type: presentation + open discussion<br />
* Goals: Gathering input and feedback on the standard; Drumming up interest in our proposed draft Working Group Charter; Identifying synergies with other W3C work/groups<br />
*Additional speakers: Mark Fox<br />
* Open to the public<br />
* Shortname: cids<br />
* Timeslot constraints: 1:30pm PT<br />
<br />
=== File System ===<br />
<br />
* Proposer: [[User:Asully|Austin Sullivan]] (physically present)<br />
* Email address of proposer: asully@google.com<br />
* Summary: Discussion of current and upcoming work on the [https://github.com/whatwg/fs File System Standard], including the high-performance Access Handles API.<br />
* Type: Open discussion<br />
* Goals: See https://github.com/whatwg/fs/issues/45<br />
* Open to the public<br />
* Shortname: fs<br />
* Timeslot constraints: None<br />
<br />
=== Project Fugu đĄ: What we have enabled ===<br />
* Proposer: [[User:Tsteiner|Thomas Steiner]] ([[User talk:Tsteiner|talk]]) (physically present)<br />
* Email address of proposer: tomac@google.com<br />
* Summary: A reflection of the apps that Project Fugu APIs have enabled, including a brief exploration of the present, the future of some of the enabling APIs, and our vision and dreams for the future.<br />
* Type of session: talk, followed by open discussion.<br />
* Goals: Reflect back and look forward.<br />
* Shortname (used for minting an IRC channel for the breakout): project-fugu<br />
* Additional speakers/panelists: [[User:Benmorss|Ben Morss]] (physically present)<br />
* Even more additional speakers/panelists: Edit this Wiki and add yourself!<br />
* Limited to TPAC participants or open to the public: Open to the public.<br />
<br />
=== The upcoming navigation and session history rewrite ===<br />
* Proposer: Domenic Denicola (physically present)<br />
* Email address of proposer: d@domenic.me<br />
* Summary: Foundational parts of the HTML Standard, regarding navigation and session history, [https://github.com/whatwg/html/pull/6315 are being rewritten]. Come find out why this is necessary, and what it means for your specs. If you've ever dealt with browsing contexts, iframes, etc., this might be relevant!<br />
* Type of session: brief talk with slides, followed by open discussion.<br />
* Goals: Make people familiar with these upcoming changes, and disseminate knowledge about these difficult areas.<br />
* Shortname (used for minting an IRC channel for the breakout): navigation-rewrite<br />
* Additional speakers/panelists: Jake Archibald; Dominic Farolino<br />
* Limited to TPAC participants or open to the public: Open to the public.<br />
<br />
=== From Open Standards to Strategic Innovation in Products and Services ===<br />
* Proposer: Rachel Yager (physically present)<br />
* Email address of proposer: ryager@w3.org or rachel@fortunetimesgroup.com<br />
* Summary: Innovation is the key to success in today's fast-paced, competitive marketplace. To be successful, companies must continuously create new and better products and services. But how can they do this? One answer is to embrace open standards. This Panel Session discusses Innovation best practices that allow companies to share knowledge, ideas, data, and code. We discuss strategies to promote collaboration and enable companies to leverage each other's Innovation Processes. Expert Speakers share enterprise success factors of adopting open standards to speed up the Innovation process, creating better products and services faster.<br />
* Type of session: Invited Panel Speakers with Open Discussion.<br />
* Goals: Innovation best practices and strategies.<br />
* Shortname (used for minting an IRC channel for the breakout): strategic-innovation<br />
* Limited to TPAC participants or open to the public: Open to the public.<br />
<br />
=== Device APIs (Bluetooth, HID, Serial, USB) ===<br />
* Proposer: Vincent Scheib (Google)<br />
* Email address of proposer: scheib@google.com<br />
* Summary: Low level [https://web.dev/devices/ device APIs] in incubation address a range of needs in education, industrial, small business, and enterprise. Many peripherals people expect to work with computers have become available to web applications. Chrome, Edge, and Samsung browsers have enabled Bluetooth, HID, Serial, and USB. We will discuss the [https://developer.chrome.com/blog/fugu-showcase/?api=webbluetooth adoption] & [https://twitter.com/Vincent_Scheib/timelines/1207046778916237312 developer interest] to date, answer questions, and discuss opportunities for the web to serve more needs.<br />
* Type of session: Presentation and discussion.<br />
* Goals: Build awareness, share what has been learned, answer questions. Solicit working group interest.<br />
* Shortname (used for minting an IRC channel for the breakout): device-apis<br />
* Limited to TPAC participants or open to the public: Open to the public.<br />
* Constraints on timeslots: 1:30pm preferred to enable some remote attendees.<br />
<br />
=== Fenced Frames API ===<br />
* Proposer: Dominic Farolino (physically present), Shivani Sharma (remotely present)<br />
* Email address of proposer: dom@chromium.org<br />
* Summary: A new web API for framing web content in a manner that's isolated from its embedder<br />
* Type of session: Brief talk with slides, followed by open discussion and opinion gathering<br />
* Goals: Make the community aware of fenced frames/its API shape, discuss the difficulties in this area, and and collect feedback from other engineers & partners<br />
* Shortname (used for minting an IRC channel for the breakout): fenced-frames<br />
* Additional speakers/panelists: Shivani Sharma (shivanisha@chromium.org)<br />
* Limited to TPAC participants or open to the public: Open to the public.<br />
<br />
=== Maximising Back/Forward Cache hit-rate ===<br />
<br />
* Proposer: Fergal Daly<br />
* Email address of proposer: fergal@chromium.org<br />
* Summary: [https://web.dev/bfcache BFCache] provides a big performance win for navigation but there are obstacles to pages successfully being cached - Cache-Control: no-store header, unload handlers, in-the-wild telemetry for cache misses. This covers proposals for solving these.<br />
* type of session: presentation and open discussion<br />
* goals of session: Get feedback on proposals for [https://github.com/w3c/webappsec-permissions-policy/issues/444 unload], [https://github.com/fergald/explainer-bfcache-ccns/ Cache-control: no-store] and [https://github.com/rubberyuzu/bfcache-not-retored-reason/blob/main/NotRestoredReason.md not-restored reasons] and any other ideas to improve hit-rate.<br />
* Open to anyone<br />
* Shortname: bfcache-hit-rate<br />
* Timeslot constraints: 4:30pm (presenters are in Tokyo).<br />
<br />
=== Allowing public resources to opt-out of privacy protections ===<br />
<br />
* Proposer: Noam Rosenthal<br />
* Email address of proposer: nrosenthal@chromium.org<br />
* Summary: The abundance of privacy protection mechanisms (CORS, TAO & CORP to name a few) are great for protecting private user data, but make services jump through hoops when they want to serve resources that do not require privacy protection at all - public resources, such as free-for-all images on CDNs. This is an open discussion on how to make serving such content easier and more future proof.<br />
* Open to anyone<br />
* type of session: presentation and open discussion<br />
* goals of session: Get feedback on [https://github.com/whatwg/html/issues/8143 CORS, CORP, TAO and "public static resource" metadata]. Reach a consensus on direction.<br />
* Shortname: access-control-public<br />
* Timeslot contraints: 1:30pm (presenter in Israel)<br />
<br />
=== CNAMEs as a privacy tool for the web ===<br />
* Proposer: Johann Hofmann, Greg Whitworth<br />
* Email address of proposer: johannhof@chromium.org<br />
* Summary (one-sentence or so): CNAME records have a reputation as a tool to circumvent resource-blocking and specific privacy measures. However, if used properly, they can help websites integrate third-party services without requiring third-party cookies, providing a great privacy benefit. We want to discuss how browsers could support privacy-preserving usage of CNAMEs while preventing potential abuse.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): open discussion<br />
* Goals: Hear about developer use cases and user concerns, kick off an open-minded discussion on the utility of CNAMEs. Maybe get some agreement across browsers on next steps.<br />
* shortname (used for minting an IRC channel for the breakout): cname-privacy<br />
* Additional speakers/panelists: Kaustubha Govind, Kris Chapman<br />
* limited to TPAC participants or open to the public? Open to public<br />
* [optional] Timeslot constraints: (3 possible slots: 1:30pm PT, 3pm PT, 4:30pm PT) 4:30pm<br />
<br />
=== Antifraud Discussion ===<br />
* Proposer: Steven Valdez<br />
* Email address of proposer: svaldez@google.com<br />
* Summary (one-sentence or so): The Antifraud CG will use this breakout for further discussion about ad and payments fraud on the Web that arises during the joint meeting of multiple groups on Tuesday; details to follow.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): open discussion<br />
* Goals: Continue discussion from joint session<br />
* shortname (used for minting an IRC channel for the breakout): antifraud<br />
* limited to TPAC participants or open to the public? Open to public<br />
* [optional] Timeslot constraints: Please avoid programming at the same time as the "IP address privacy" session<br />
<br />
=== Independent Interoperable Implementation and going beyond Candidate Recommendation ===<br />
* Proposer: Philippe Le Hegaret<br />
* Email address of proposer: plh@w3.org<br />
* Summary (one-sentence or so): The W3C Process requires adequate implementation experience to be able to transition a document beyond Candidate Recommendation. Some of the past transitions raised concerns about how this should be interpreted. This session is intended to help the community get a better grip on the 3 Big Is â interoperable, independent, implementation.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): open discussion<br />
* Goals: Continue discussion from joint session<br />
* shortname (used for minting an IRC channel for the breakout): iii<br />
* limited to TPAC participants or open to the public? Open to public<br />
* [optional] Timeslot constraints: none</div>Plehegarhttps://www.w3.org/wiki/index.php?title=Registries&diff=114697Registries2022-07-06T16:22:24Z<p>Plehegar: Historical purposes</p>
<hr />
<div><span style='color: red'>NOTE: This article is preserved for historical purposes only. Process 2021 contains a [https://www.w3.org/2021/Process-20211102/#registries Registry Track].<br />
<br />
= Background discussion =<br />
<br />
This is a close companion to the [[Living Standards]] question. (Previously called Repositories, but Registries is a more common industry term).<br />
<br />
There is a [https://github.com/w3c/w3process/issues/168 Process CG Issue] open.<br />
<br />
A registry is a place where people can request to have something stored for sharing among the community. This differentiates it from a specification, which is produced by a group of some sort.<br />
<br />
The purposes of a registry include at least<br />
* non-collision. Avoiding the problem of two organizations using the same code-point value with different semantics.<br />
* non-duplication. Avoiding the problem of having two or more different code-points in use with the same semantics.<br />
* information. Providing a central reference/dispatch place where anyone can find out what a code-point means and what its formal definition is (and where it is).<br />
* ease of adding new terms<br />
* new stakeholders can add new terms<br />
* a clear consensus of the community on the terms<br />
<br />
There are various terms used in the industry to describe those items that require registries. These include:<br />
* Registries<br />
* [https://github.com/w3c/w3process/issues/79#issuecomment-373119666 Accessibility API Mappings]<br />
* Vocabularies<br />
* Classification schemes<br />
<br />
A registry typically contains a set of values for a specific 'slot' in some format. There are many examples of registries. [http://wwww.iana.org/ IANA] is perhaps one of the more famous sites hosting a number of registries. [http://mp4ra.github.io/mp4ra/ MP4RA] is another, hosting code-points for MP4-family box-structured files.<br />
<br />
In an Accessibility API Mapping, a W3C specifications "maps" W3C-specified elements and attributes to platform accessibility APIs such as NSAccessibility (macOS and iOS); ATK (GNU/Linux); IAccessible2 and UIAutomation (Windows). <br />
<br />
[http://www.w3.org/standards/semanticweb/ontology Vocabularies] may be used to disambiguate terms used in different datasets.<br />
<br />
It is rare for Registries to have IPR policies; however, a lot depends on the requirements on implementations (see below).<br />
<br />
= Registries vs. specification tables =<br />
<br />
Not every table in a specification is a potential registry. If the intent or effect is that the table enumerates all the possibilities the authors of the specification expect or envisage, then the table by itself is enough. Similarly if the table is managed by the working group and only updated as part of specification update, then the complexities of 3rd-party registration applications and rules are not needed.<br />
<br />
= Requirements on implementations =<br />
<br />
A lot depends on what the expected implementation requirements of a registry are. Possibilities include:<br />
<br />
* every implementation of the specification that embeds the registry is expected to recognize and implement the effect/semantics of all registered values;<br />
* every implementation of the specification that embeds the registry is expected to recognize all registered values, but can choose which to implement;<br />
* the registry or specification has two or more 'classes' â required code-points that all must implement, and extension code-points that are optional<br />
* the registry and specification merely document existence, and it's for external constraints or other specifications, or for implementers, to decide which to implement.<br />
* a registry might be independent of a particular specification, but document registered values that could relate to multiple specifications.<br />
<br />
An example of a code-point that all must implement would be one that identifies the compression or format of a datatransfer, such as transfer-encoding in HTTP and MIME. It's useless if a new value is used by a source, and the sink does not recognize it; the protocol then fails.<br />
<br />
An example of a code-point that is optional is the MP4 registration of codecs. There is no expectation that every multimedia player will implement all possible codecs; what is actually required is set by vertical or application specifications.<br />
<br />
A registry which is independent of a particular specification could be a vocabulary which is utilized by multiple specifications.<br />
<br />
Clearly the licensing status needed varies greatly depending on what expectation is placed on implementations; if something must be implemented, we may want the IPR policy applying to the specification that embeds the registry to apply also to the registry - if indeed there are any IPR issues.<br />
<br />
= Admission criteria =<br />
<br />
== Introduction ==<br />
<br />
We must address the question of 'how do I get a new value into a registry?' When there is a relevant Working Group it would play a major role. When there is no Working Group (either because it spans Working Groups or because the WG is out of Charter) we need to determine who has the responsibility for this. It could be the W3C Team, a Community Group (although there is weak structure there), or we may create a lightweight registry Group. <br />
<br />
== Review Requirements ==<br />
<br />
For tables embedded in specifications, the implied answer is "persuade the owners of the specification â the WG at W3C â to do an update". Since adding a code-point would generally be considered a 'substantive change', this is moderately slow and painful, involving, for an existing Recommendation, a trip around the rec-track process. A [[Living Standards]] process might be more suitable.<br />
<br />
IANA requires (and marks every code-point with) an explicit declaration of what is required to get a new code-point in a table. <br />
<br />
Possibilities include, from the W3C point of view:<br />
* Full Rec-track process; WG approval, wide review and community consensus, AC review, and Director's approval (i.e. equivalent to updating a table in the recommendation)<br />
* Some subset of the Rec-track, herein referred to as a registry Group: one likely popular option would be WG review<br />
* no review required<br />
<br />
== Other Requirements ==<br />
<br />
For entry into registries, there may be other requirements (in addition to the obvious ones of non-collision and non-duplication):<br />
* that the specification of the semantics of the code-point, and where to find it, be identified<br />
* that the specification be publicly available<br />
* that the specification be freely available<br />
* that there is evidence of implementability, implementation, and interoperability<br />
* that the code-point be implementable with specific licensing requirements (e.g. RAND, Royalty-free, etc.)<br />
<br />
= Development hosting and other considerations =<br />
<br />
IANA takes some maintenance, as does the MP4RA. How registries outside their specification are hosted, backed-up, and maintained, needs consideration. We could, for example, explicitly ask IANA to host: but many people find IANA rather bureaucratic, and the IANA site rather hard to navigate. An alternative is to create a place in /TR where these are hosted.<br />
<br />
It can be important to be able to trace the history of a registry: when code-points were entered, and so on. There may be aspects of registration requests (e.g. personal or corporate contact information) that are required for a request but that should not be made publicly visible.<br />
<br />
It should be noted that GitHub natively presents CSV (comma-separated-value) files as tables; if a registry can be represented by one or more tables, this may be a simple hosting option, as history is automatically kept.<br />
<br />
= Proposed Process Text â Registries = <br />
<br />
(This section is proposed as an addition to the Process. It is deliberately both short (example-free) and as unconstraining as possible; it makes sense to read it along with the guidelines on implementation.)<br />
<br />
== Definition ==<br />
<br />
A Registry is a data set that documents logically independent 'atoms'; conceptually a table with independent rows, and rules for the values in the columns (e.g. that values in a column be drawn from a defined set). <br />
<br />
There are four conceptual elements in a Registry:<br />
# Registries are always owned by, or incorporated directly into, a ''Referencing Document'' (though the registry may be referenced by other documents as well, fo course). (Roughly, the spec. that has some aspect (e.g. a field, an attribute value) for which registration of new values needs to be possible.)<br />
# Registries are defined by a ''Registry Definition''. Contains the definition of and requirements for the registry values. <br />
# ''Published Registry'' values. The formal published location, which URLs referring to registry values (e.g. notably from the Referencing Document) point to.<br />
# ''Registry values management''. This is where the registry values are maintained, and so on.<br />
<br />
Published Registry values MUST be in /TR (the place we publish all formal publications of the W3C), and are purely documentational and contain no requirements on implementers. They are updated following the (approved) process for that registry as defined in the Registry definition.<br />
<br />
The W3C may publish a list of W3C Registries.<br />
<br />
== Combined Publication ==<br />
<br />
We are currently discussing which of these elements can be combined. Examples include:<br />
<br />
1+2) Referencing Document + Registry Definition, and have a pointer to the Published Registry. (This is like the IETF, where RFCs typically document a technology, and say which fields are open to registration, and under what conditions, but the registry values themselves are at IANA). (Some do not like this practice, others do).<br />
<br />
2+3) Registry Definition + Published Registry. This would be the case where it makes sense to define a registry as a stand-alone Recommendation in its own right. <br />
<br />
1+2+3) Referencing Document + Registry Definition + Published Registry. This would be suitable for âsmallâ tables for which the current values and the definitions can easily be inlined into the spec. (âthing-type: a value drawn from the thing-type registry; current values and the procedures for registering a new thing-type can be found in Annex Gâ). You could insert the Published Registry as an iframe, for example.<br />
<br />
== Referencing Document requirements ==<br />
<br />
The Referencing Document <br />
# MUST contain all normative statements and information that affect implementations and the conformance of implementations. It must not be possible that a change to the Registry values affect the conformance of implementations to the Referencing document; if there are values that must be implemented, or any other such restrictions, they must be documented in the document without reference to the registry.<br />
# may either contain the registry or have a reference to the registry, where to view it<br />
<br />
== Registry Definition requirements ==<br />
<br />
The Registry definition must:<br />
# contain a section defining the registry that must <br />
## state that it is a Registry per the W3C Process, <br />
## identify the Custodian. The Custodian can be the W3C group that owns the Referencing Document, the team if no such W3C group exists, or some other entity.<br />
## define the fields of its table of items, <br />
## define the policy and procedure for changes (additions, and deletions or modifications if they are permitted); how to request a registration, what information is required, and what criteria must be met<br />
# contain ''all'' requirements and normative language related to the registry; the rules for values (logically, the column values) in each entry (e.g. uniqueness, matching to a value from some other specification or registry, etc.)<br />
# contain documentation on the policy and mechanisms for changes to existing entries: <br />
## can entries be retired (deleted) or deprecated?<br />
## can entries be changed after being published?<br />
## if entries can be deleted, can any code-points be re-used, or are they 'reserved' indefinitely?<br />
# provide the location of the published Registry values, and the Registry management.<br />
# provide any restrictions on links to other publications, e.g. that the specification be<br />
## publicly available (as opposed to company-private, for example)<br />
## freely available (no cost)<br />
## published by a recognized standards body<br />
## a W3C publication<br />
# document any requirements of evidence of implementability, implementation, interoperability, etc.<br />
<br />
Hence changes to the Registry other than managing entries are all controlled by the update process for the Registry definition. Registry definitions are approved through the same, or stronger, process as the Referencing Document for that registry (i.e. and specifically, if the Referencing Document is a W3C Recommendation, then the Registry Definition is also a Recommendation, while a W3C Referencing Document that is a Note may, of course, have a Registry Definition that is a Recommendation).<br />
<br />
If the defined process is followed, changes to the values, and publication to the registry values, should be automatic and rapid.<br />
<br />
== Published Registry values requirements ==<br />
<br />
The Registry values <br />
# must only be updated when conforming to the rules in the associated Registry Definition.<br />
# must not contain any normative statements (must, should, etc.).<br />
# if it is not embedded in the referencing document or registry definition, must contain a link back to the registry definition (which contains the rules etc.) and should contain a link back to the referencing document (for which it is a registry), if that document is separate;<br />
# may contain informative material, including descriptions of the various values ('columns') and their meaning<br />
# must contain or reference the information on how to request updates (a new entry or any other permitted changes).<br />
# may contain a machine-readable copy (e.g. CSV file) which MUST match the human-readable copy of the same version of the Published registry<br />
<br />
== Registry management requirements ==<br />
<br />
(Note that this probably should apply to the development of any W3C publication. The general rules are currently unstated.)<br />
<br />
The Registry management must be a location that is suitable for development of a W3C publication. The rules are currently unstated but probably should be stated for the general case, and not specifically for registries. Registry management must<br />
* have the ability to file bug reports (aka issues)<br />
* support history tracking (so we can see what was changed when, by whom, etc.)<br />
* have backups maintained by the W3C (so if there is a disc crash or the service goes down, we don't lose)<br />
* must be setup in such a way that review (cross-functional, wide, AC, review for example) can be managed using automatic notifications, e.g. sending notifications and periodic summaries to interested populations;<br />
* be such that the development tool/site are to be accessible (a) to those needing accessible access and (b) to our community internationally.<br />
<br />
(A scrapable Wiki may be suitable here, while a Wiki is probably not suitable for document management generally.)<br />
<br />
= Proposed supporting text â Guidelines on Implementation of Registries =<br />
<br />
Registries exist to:<br />
* list possibilities<br />
* document meanings (so an implementer can ask "what does Pfoogle mean?")<br />
* avoid code-point collision (two 'rows' never share the same code-value)<br />
* avoid duplication (two 'rows' with the same meaning but different code-points)<br />
<br />
Many registries assign a meaning to code-points (e.g. "the value 1 means the identity matrix"). <br />
<br />
The requirements are set such that there can be no essential IPR or other normative effect caused by any change to the registry; all requirements have to be evident from reading the Referencing Document without recourse to the Registry. The rules therefore are those of the IPR policy that applies to the referencing document.<br />
<br />
Registration requests could be via a Github issue, email, or other suitable means of communicating with the Custodian.<br />
<br />
Registration requirements might include that the value is documented in a publicly available specification, that it's implemented, that it doesn't contravene any laws, etc.<br />
<br />
Examples of ways to host a W3C registry include:<br />
* a dedicated section within the Referencing Document ('embedded');<br />
* a separate HTML document;<br />
* a data file such as CSV, JSON, RDF, XML etc., supported by some suitable framework to make it viewable;<br />
* an API-accessible resource;<br />
* a database-backed system, etc.<br />
<br />
All of these must be able to publish to /TR (ideally, automatically) for the formal published Registry values.<br />
<br />
Examples of management and publication tools for file based registries are Github repos, or a scrapable Wiki, or a database-backed system.<br />
<br />
Where Registry elements are combined, they must nonetheless be in distinct sections or otherwise clearly separated. (E.g. "This annex contains the definition of the XX Registry." "Table 1 contains the values of the XX Registry, and is dynamically updated as changes occur.")<br />
<br />
<span style='color: red'>NOTE: This article is preserved for historical purposes only. Process 2021 contains a [https://www.w3.org/2021/Process-20211102/#registries Registry Track].</div>Plehegarhttps://www.w3.org/wiki/index.php?title=TPAC/2022&diff=114678TPAC/20222022-06-29T19:51:39Z<p>Plehegar: </p>
<hr />
<div>{{stub}}<br />
<br />
[https://www.w3.org/2022/09/TPAC/ TPAC 2022] will be in Vancouver on 12-16 September. For more information, see the [https://www.w3.org/2022/09/TPAC/ TPAC 2022] site.<br />
<br />
== Covid precautions ==<br />
See here for now:<br />
* https://github.com/w3c/TPAC2022-Health-rules<br />
<br />
== Plan to be there ==<br />
* [[/Demos_and_Group_updates|Demos and Group updates]]<br />
* Developer meetup (Tuesday 13 September 2022)<br />
* ... your TPAC 2022 Working Group meeting announcement here ...<br />
<br />
== See Also ==<br />
* Previously: [[TPAC/2021]]<br />
* [[TPAC]] - list of past TPACs</div>Plehegarhttps://www.w3.org/wiki/index.php?title=TPAC/2022&diff=114677TPAC/20222022-06-29T19:51:14Z<p>Plehegar: </p>
<hr />
<div>{{stub}}<br />
<br />
[https://www.w3.org/2022/09/TPAC/ TPAC 2022] will be in Vancouver on 12-16 September!<br />
<br />
For more information, see the [https://www.w3.org/2022/09/TPAC/ TPAC 2022] pages!<br />
<br />
== Covid precautions ==<br />
See here for now:<br />
* https://github.com/w3c/TPAC2022-Health-rules<br />
<br />
== Plan to be there ==<br />
* [[/Demos_and_Group_updates|Demos and Group updates]]<br />
* Developer meetup (Tuesday 13 September 2022)<br />
* ... your TPAC 2022 Working Group meeting announcement here ...<br />
<br />
== See Also ==<br />
* Previously: [[TPAC/2021]]<br />
* [[TPAC]] - list of past TPACs</div>Plehegarhttps://www.w3.org/wiki/index.php?title=TPAC/2022&diff=114676TPAC/20222022-06-29T19:48:15Z<p>Plehegar: </p>
<hr />
<div>{{stub}}<br />
<br />
[https://www.w3.org/2022/09/TPAC/ TPAC 2022] will be in Vancouver on 12-16 September!<br />
<br />
== Covid precautions ==<br />
See here for now:<br />
* https://github.com/w3c/TPAC2022-Health-rules<br />
<br />
== Plan to be there ==<br />
* [[/Demos_and_Group_updates|Demos and Group updates]]<br />
* Developer meetup (Tuesday 13 September 2022)<br />
* ... your TPAC 2022 Working Group meeting announcement here ...<br />
<br />
== See Also ==<br />
* Previously: [[TPAC/2021]]<br />
* [[TPAC]] - list of past TPACs</div>Plehegarhttps://www.w3.org/wiki/index.php?title=TPAC/2021/GroupMeetings&diff=114243TPAC/2021/GroupMeetings2021-10-25T16:18:28Z<p>Plehegar: Fixed Dataset Working Group time</p>
<hr />
<div>==Introduction ==<br />
<br />
Due to uncertainties in the health and sanitary situation, TPAC 2021 will be a fully remote event. You will find below the schedule:<br />
<br />
* 12 October: AC Meeting<br />
* 18 - 22 October : Breakout sessions <br />
* '''25 - 29 October : WG/IG/BG/CG meetings and Joint Group Meetings<br />
'''<br />
The usual TPAC objectives remain:<br />
<br />
* Groups schedule a Group meeting to which observers are invited so that members of our community have the opportunity to see the work of the W3C groups.<br />
* Groups schedule joint meetings with other Groups<br />
* Breakout sessions will discuss specific topics of interest.<br />
<br />
We also invite you to read further details about goals, opportunities and good practices in organizing [https://www.w3.org/Guide/meetings/tpac.html '''TPAC group and Joint Meetings''']<br />
<br />
Those who are eligible to attend the group and joint meetings are:<br />
<br />
* a participant in a W3C Working, Interest, Business or Community Group scheduled to meet for TPAC<br />
* a W3C Member Advisory Committee Representative<br />
* a participant on the Advisory Board or the TAG<br />
* an employee of a W3C member organization<br />
* an invited Guest<br />
* a W3C Evangelist<br />
* W3C staff or W3C Office chapter<br />
<br />
Observer and Guest Attendance: Eligible participants may request to attend as an Observer via the registration form. <br /><br />
Community Group Participants: Any participant of a CG scheduled to meet will be able to attend other group meetings if one of the above criteria is fulfilled.<br />
<br />
'''Group chairs, please read the details below and fill in the appropriate table(s). <br />'''<br />
There are three different tables for the following meetings:<br />
* Working Group [WG], Interest Group [IG], Business Group [BG] Meetings<br />
* Community Group [CG] Meetings<br />
* Joint Group Meetings<br />
<br />
'''The meeting scheduling process is as follows:'''<br />
<br />
* Until 10 September please fill in the tables below with your preferred meeting dates and time. If flexible, please state a second option<br />
* The W3C Events Team will make sure that the meetings are well distributed within the week and will contact group to confirm the options they stated<br />
* 17 September: Group schedule confirmed<br />
* 20 September: Meeting registration opens<br />
<br />
Please do your best to select times that will allow a broad participation among meeting attendees and observers all around the globe.<br />
<br />
== Joint Group meetings ==<br />
<br />
Group Chairs, <br />
please coordinate with the groups you would like to meet with and fill in the following table.<br />
{| class="wikitable"<br />
|-<br />
! '''Chair name''' !! '''Group name''' !! '''OPTION 1: Date and times in [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20201001T140000 UTC]''' !! '''OPTION 2: Date and times in [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20201001T140000 UTC]''' !! '''With which groups there should be no overlap''' !! '''Link to agenda''' See "Group meetings attendance section" || '''Link to Meeting coordinates (service, code, password)''' See "Group meetings attendance section|| CONFIRMED date and times by W3C<br />
|-<br />
| Addison Phillips, Alan Stearns, Rossen Atanassov || CSS + Internationalization || Wed 27 Oct 1600 UTC to 1700 UTC || â || â || https://github.com/w3c/csswg-drafts/projects/24 || https://lists.w3.org/Archives/Member/member-i18n-core/2021Oct/0022.html || '''OPTION 1 CONFIRMED''' 27 Oct. 16:00-17:00UTC<br />
|-<br />
| Addison Phillips || Internationalization || Thu 28 October 1400 UTC to 1600 UTC || â || â || https://www.w3.org/wiki/I18N_2021_TPAC || https://www.w3.org/2017/09/i18n-meeting-info.html || '''OPTION 1 CONFIRMED''' 28 Oct 14:00-16:00UTC<br />
|-<br />
| Addison Phillips, Rain Michaels || Internationalization + COGA || Thu 28 October 1400 UTC to 1500 UTC || â || â || https://www.w3.org/WAI/GL/task-forces/coga/wiki/TPAC_2021_initial_planning#Internationalization || https://www.w3.org/2017/08/telecon-info_coga || '''OPTION 1 CONFIRMED''' 28 Oct 14:00-15:00UTC<br />
|-<br />
| Bernard Aboba, Harald Alvestrand, Jan-Ivar Bruaroey, Jer Noble, Chris Needham || WebRTC WG + Media WG + Audio WG|| [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T140000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 26, 14:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T160000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 26, 16:00 UTC] || [https://www.timeanddate.com/worldclock/converter.html?iso=20211027T140000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 27, 14:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211027T160000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 27, 16:00 UTC] || WebRTC, WebTransport, MEIG || [https://www.w3.org/2011/04/webrtc/wiki/TPAC_2021#Joint_WebRTC.2FMedia.2FAudio_WG_Meeting Agenda] || See https://www.w3.org/events/meetings/81d215c7-f4c2-4697-a4b4-985efba5427e || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T140000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 26, 14:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T160000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 26, 16:00 UTC]<br />
|-<br />
| Adrian Hope-Bailie, Nick Telford-Reed, John Fontana, Tony Nadalin || WPWG and WebAuthn || 27 OCT. 14-15 UTC || || || See [https://github.com/w3c/webpayments/wiki/Agenda-TPAC2021 WPWG agenda] || See [https://github.com/w3c/webpayments/wiki/Agenda-TPAC2021 WPWG agenda] || '''OPTION 1 CONFIRMED''' 27 Oct 14:00-15:00UTC<br />
|-<br />
| Adrian Hope-Bailie, Nick Telford-Reed, Addison Phillips || WPWG and I18N || 26 OCT. 15-15:30 UTC || || || See [https://github.com/w3c/webpayments/wiki/Agenda-TPAC2021 WPWG agenda] || See [https://github.com/w3c/webpayments/wiki/Agenda-TPAC2021 WPWG agenda] || '''OPTION 1 CONFIRMED''' 26 Oct 15:00-15:30UTC<br />
|-<br />
| Janina Sajka, Becky Gibson, Jeanne Spellman, Charles Adams, Alastair Campbell, Rachael Bradley Montgomery, Dave Cramer, Wendy Reid, Shinya Takami || APA, AGWG/Silver, EPUB || [https://www.timeanddate.com/worldclock/converter.html?iso=20211025T140000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 25, 14:00 UTC] for 1 hour || || || [https://www.w3.org/events/meetings/5d4c7d7c-ca9d-4dde-8663-a93493714abc Agenda] || [https://www.w3.org/events/meetings/5d4c7d7c-ca9d-4dde-8663-a93493714abc Meeting Coordinates] || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/converter.html?iso=20211025T140000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 25, 14:00-15:00 UTC]<br />
|-<br />
| Janina Sajka, Becky Gibson, Jason White, Lisa Seeman, Rain Michaels || APA Research Questions TF & APA/ARIA Cognitive TF || [https://www.timeanddate.com/worldclock/converter.html?iso=20211027T140000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240&p8=1440 Oct 27, 14:00 UTC] for 1 hour || || || [https://www.w3.org/WAI/GL/task-forces/coga/wiki/TPAC_2021_initial_planning#RQTF COGA's Proposed Agenda] || Zoom set up on Cvent: the host needs to use this [https://zoom.us/s/95045321322?zak=eyJ0eXAiOiJKV1QiLCJzdiI6IjAwMDAwMSIsInptX3NrbSI6InptX28ybSIsImFsZyI6IkhTMjU2In0.eyJhdWQiOiJjbGllbnRzbSIsInVpZCI6ImFBbzVqMTBPUzUyUFhOMEpkcFdKREEiLCJpc3MiOiJ3ZWIiLCJzdHkiOjk5LCJ3Y2QiOiJhdzEiLCJjbHQiOjAsIm1udW0iOiI5NTA0NTMyMTMyMiIsInN0ayI6IktvVkppQ3pkd2c0VEdCanloRGdYeWhCWGNRNERjVzUyeHJLR1dIVzNuMmsuQmdaZ2EyeFNRV2haUWk5NFF6UlJjM0pLYUVwQ2IxazRkMk5KV1VwMlJHSTRkRlpFTjJGeGFVZExRVVJHV0hoak9WTnNWVEIyUVZsdFUwTlNUVVJQVFZkTlExTmFZMVpCUkdVNGJHRTVUaXRVVGtabWFWWkxUbVpoZWtKbU1rNURLMjh6QUFBTWNtVnNjSGhYTDFWRFowRTlBQU5oZHpFQUFBRjhvYS1MUGdBU2RRQUFBQSIsImV4cCI6MTY0MjU3NjIwOCwiaWF0IjoxNjM0ODAwMjA4LCJhaWQiOiJBUUlheUNVd1RqS3BEVDdnVDFyLXV3IiwiY2lkIjoiIn0.Ai72oqpFN7ENaoPizQ9_cHEqS0xLlV5HmjysNGTY6nE Host link]. The other attendees will connect to Cvent and click on the join session button (FYI here is the [https://zoom.us/j/95045321322?pwd=QUNva2g3dW9XbFIzbE5TVUJUUFNFUT09 attendee URL]) || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/converter.html?iso=20211027T140000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240&p8=1440 Oct 27, 14:00-15:00 UTC]<br />
|-<br />
| Janina Sajka, Becky Gibson, Sharon Snider Lionel Wolberger, Lisa Seeman, Rain Michaels || APA Personalization TF & APA/ARIA Cognitive TF || [https://www.timeanddate.com/worldclock/converter.html?iso=20211027T150000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240&p8=1440 Oct 27, 15:00 UTC] for 1 hour || || || [https://www.w3.org/WAI/GL/task-forces/coga/wiki/TPAC_2021_initial_planning#Personalization COGA's Proposed Topics] || Zoom set up on Cvent: the host needs to use this [https://zoom.us/s/93478214071?zak=eyJ0eXAiOiJKV1QiLCJzdiI6IjAwMDAwMSIsInptX3NrbSI6InptX28ybSIsImFsZyI6IkhTMjU2In0.eyJhdWQiOiJjbGllbnRzbSIsInVpZCI6IlFoZks1MjRSU3VDanBTVGJkOWt5OEEiLCJpc3MiOiJ3ZWIiLCJzdHkiOjk5LCJ3Y2QiOiJhdzEiLCJjbHQiOjAsIm1udW0iOiI5MzQ3ODIxNDA3MSIsInN0ayI6Ik1qNnktdGpONGFmdjUzUGVWdDFGZ0syWnlLcTJZM1NCb3ItU3g2QUI0MFEuQmdaZ1ZrNDBkamx3ZVVaMVIySjJVMHBET1hjcldqQjRSVFJMZWt0d1lUSXlhalpvV1dsRVEyWlNVamhoUkRoSFkwUk1jRnBrTlUxWFUwTlNUVVJQVFZkTlExTmFZMVpCUkdVNGJHRTVUaXRVVGtabWFWWkxUbVpoZWtKbU1rNURLMjh6QUFBTWNtVnNjSGhYTDFWRFowRTlBQU5oZHpFQUFBRjhvY0c4SUFBU2RRQUFBQSIsImV4cCI6MTY0MjU3NzQwMCwiaWF0IjoxNjM0ODAxNDAwLCJhaWQiOiJBUUlheUNVd1RqS3BEVDdnVDFyLXV3IiwiY2lkIjoiIn0.xtCjVjBTWWrZO-FE4mHkfLABtLA2bt7Q7LY_721ieiI Host link]. The other attendees will connect to Cvent and click on the join session button (FYI here is the [https://zoom.us/j/93478214071?pwd=UXVFMXpxNWdnWDd2RmcyODJVNnRlUT09 attendee URL] || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/converter.html?iso=20211027T150000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240&p8=1440 Oct 27, 15:00-16:00 UTC]<br />
|-<br />
| Janina Sajka, Becky Gibson, Dave Cramer, Wendy Reid, Shinya Takami || APA and EPUB || [https://www.timeanddate.com/worldclock/converter.html?iso=20211028T140000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240&p8=1440 Oct 28, 14:00 UTC] for 2 hours || || || [https://www.w3.org/events/meetings/35bce778-3fec-40d6-a6e1-30ff6961616a Agenda] || [https://www.w3.org/events/meetings/35bce778-3fec-40d6-a6e1-30ff6961616a Meeting Coordinates] || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/converter.html?iso=20211028T140000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240&p8=1440 Oct 28, 14:00-16:00 UTC]<br />
|-<br />
| Christine Perey, Ada Rose Canon, AyĹegĂźl YĂśnet, Chris Wilson || IWWG and OGC GeoPose SWG / SDWWG || [https://www.timeanddate.com/worldclock/converter.html?iso=20211029T150000 Oct 29 15:00 UTC] || || || || Zoom set up on Cvent: the host needs to use this [https://zoom.us/s/96741815761?zak=eyJ0eXAiOiJKV1QiLCJzdiI6IjAwMDAwMSIsInptX3NrbSI6InptX28ybSIsImFsZyI6IkhTMjU2In0.eyJhdWQiOiJjbGllbnRzbSIsInVpZCI6IlRHbUZlbDFZUzN1UlRZMVZuOFZYUEEiLCJpc3MiOiJ3ZWIiLCJzdHkiOjk5LCJ3Y2QiOiJhdzEiLCJjbHQiOjAsIm1udW0iOiI5Njc0MTgxNTc2MSIsInN0ayI6IjVIMHhVZ3ZTekNlc2thai1pa3BxWHBlVHk2M1BtV1VRcFBUWjBVRDI4ancuQmdaZ1NFTmtTME5ETUV4WFZTODViR3RKTmtNMldreG1SRmxvU2poclQyeEVNM1ZhZWtwc00xa3hNbTVGWmxJNE1tMW9WMmhyT1RsSFUwTlNUVVJQVFZkTlExTmFZMVpCUkdVNGJHRTVUaXRVVGtabWFWWkxUbVpoZWtKbU1rNURLMjh6QUFBTWNtVnNjSGhYTDFWRFowRTlBQU5oZHpFQUFBRjh0VjNwdmdBU2RRQUFBQSIsImV4cCI6MTY0MjkwNjQwMywiaWF0IjoxNjM1MTMwNDAzLCJhaWQiOiJBUUlheUNVd1RqS3BEVDdnVDFyLXV3IiwiY2lkIjoiIn0.uhXWW6QBPARUvKvvLoou8QEzTtHDX4vogCQNt3L9SGo Host link]. The other attendees will connect to Cvent and click on the join session button (FYI here is the [https://zoom.us/j/96741815761?pwd=bWNic3dPeXN3aGJOU2UxV2QxdTdzQT09 attendee URL]) || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/converter.html?iso=20211029T150000 Oct 29 15:00-16:00 UTC]<br />
|-<br />
| Christine Runnegar, Pete Snyder, Nick Doty, Wendy Reid, Dave Cramer, Shinya Takami || PING and EPUB3 WG || [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T150000 Oct 26 15:00 UTC] || || || [https://www.w3.org/events/meetings/2e397c32-b5e1-4f5b-8789-741d09c285ed#agenda Agenda] || [https://www.w3.org/events/meetings/2e397c32-b5e1-4f5b-8789-741d09c285ed#general Meeting Coordinates] || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T150000 Oct 26 15:00-16:00 UTC]<br />
|-<br />
|-<br />
| Janina Sajka, Becky Gibson, James Nurthen|| APA & ARIA: The Future of Accessibility APIs (Session 1)|| [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T160000 Oct 26 16:00 UTC] || || ||[https://www.w3.org/WAI/APA/wiki/Meetings/TPAC_2021#APA_.26_ARIA:_The_Future_of_Accessibility_APIs Link to APA & ARIA agenda] || Zoom set up on Cvent: the host needs to use this [https://zoom.us/s/99193782572?zak=eyJ0eXAiOiJKV1QiLCJzdiI6IjAwMDAwMSIsInptX3NrbSI6InptX28ybSIsImFsZyI6IkhTMjU2In0.eyJhdWQiOiJjbGllbnRzbSIsInVpZCI6InFnT2V2WHdDUUtPc3IwamVMakFhbkEiLCJpc3MiOiJ3ZWIiLCJzdHkiOjk5LCJ3Y2QiOiJhdzEiLCJjbHQiOjAsIm1udW0iOiI5OTE5Mzc4MjU3MiIsInN0ayI6IlFxZDZfbXpKUldqUXBSM2pRWXd6N3NqeEhjT1hVTzYzeXN4b3piSVRCXzguQmdaZ1NscE5kRk0wVWprMGMzUmljVmRhVFVGUGNtWklZMU0xY1RCQlZWVkZabmRrVEM4clRsZDRMekpSYjBKRVNqQXlOM0I0Vm1kSFUwTlNUVVJQVFZkTlExTmFZMVpCUkdVNGJHRTVUaXRVVGtabWFWWkxUbVpoZWtKbU1rNURLMjh6QUFBTWNtVnNjSGhYTDFWRFowRTlBQU5oZHpFQUFBRjhvSU12bmdBU2RRQUFBQSIsImV4cCI6MTY0MjU1NjUyNCwiaWF0IjoxNjM0NzgwNTI0LCJhaWQiOiJBUUlheUNVd1RqS3BEVDdnVDFyLXV3IiwiY2lkIjoiIn0.r3N_7JWHLjgTamEHxw5RgoO5PLKbSBTqnmQ4tVQNfjA Host link]. The other attendees will connect to Cvent and click on the join session button (FYI here is the [https://zoom.us/j/99193782572?pwd=MC9JUnVVZkxQSUlvYTJmZkRDRDcydz09 attendee URL]) || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T160000 Oct 26 16:00-18:00 UTC]<br />
|-<br />
|-<br />
| Janina Sajka, Becky Gibson, James Nurthen|| APA & ARIA: The Future of Accessibility APIs (Session 2)|| [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T100000 Oct 27 00:00 UTC] || || ||[https://www.w3.org/WAI/APA/wiki/Meetings/TPAC_2021#APA_.26_ARIA:_The_Future_of_Accessibility_APIs Link to APA & ARIA agenda] || Zoom set up on Cvent: the host needs to use this [https://zoom.us/s/96942169805?zak=eyJ0eXAiOiJKV1QiLCJzdiI6IjAwMDAwMSIsInptX3NrbSI6InptX28ybSIsImFsZyI6IkhTMjU2In0.eyJhdWQiOiJjbGllbnRzbSIsInVpZCI6InM4TndVRVZaU3VxN0dCWHZVZUdSTlEiLCJpc3MiOiJ3ZWIiLCJzdHkiOjk5LCJ3Y2QiOiJhdzEiLCJjbHQiOjAsIm1udW0iOiI5Njk0MjE2OTgwNSIsInN0ayI6ImJJNjA3NG41Y1hpNzlwTlYxV09yY2cxR3g3cEJteXZwOThPNFQyNmUzZzQuQmdaZ1IxSm9SbUZ0UkdKeVFUaHVRMjFUUzB4T2JrYzVaa3hhV0VkUFVsUndSM1ZHVmxVck1VNHZNREV4VmpSMk5YbDRUR3RFVGtGdFUwTlNUVVJQVFZkTlExTmFZMVpCUkdVNGJHRTVUaXRVVGtabWFWWkxUbVpoZWtKbU1rNURLMjh6QUFBTWNtVnNjSGhYTDFWRFowRTlBQU5oZHpFQUFBRjhwYVE1bHdBU2RRQUFBQSIsImV4cCI6MTY0MjY0MjU3NSwiaWF0IjoxNjM0ODY2NTc1LCJhaWQiOiJBUUlheUNVd1RqS3BEVDdnVDFyLXV3IiwiY2lkIjoiIn0.sQ_CpQt0Rhcp4af4ZhiO35gein6gqOxiHa6DSgsLxuM Host link]. The other attendees will connect to Cvent and click on the join session button (FYI here is the [https://zoom.us/j/96942169805?pwd=S3d4bThBeTVqSGdaa3d3T2RnVklkdz09 attendee URL]) || '''OPTION 1 CONFIRMED'''[https://www.timeanddate.com/worldclock/converter.html?iso=20211026T100000 Oct 27 00:00-02:00 UTC]<br />
|-<br />
|}<br />
<br />
== WG/IG/BG Group Meetings details ==<br />
<br />
Please let us know your preferred dates and times between the @@ - @@ time<br/><br />
<br />
{| class="wikitable"<br />
|-<br />
! '''Chair name''' !! '''Group name''' !! '''OPTION 1: Date and times in [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20201001T140000 UTC]''' !! '''OPTION 2: Date and times in [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20201001T140000 UTC]''' !! '''With which groups there should be no overlap''' !! '''Link to agenda''' See "Group meetings attendance section || '''Link to Meeting coordinates (service, code, password)''' See "Group meetings attendance section|| CONFIRMED date and times by W3C<br />
|-<br />
|Michael McCool & Sebastian Kaebisch || WoT Meeting || [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T120000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 26, 12:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T150000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 26, 15:00 UTC], [https://www.timeanddate.com/worldclock/converter.html?iso=20211027T120000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 27, 12:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211027T150000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 27, 15:00 UTC], and [https://www.timeanddate.com/worldclock/converter.html?iso=20211028T120000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 28, 12:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211028T150000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 28, 15:00 UTC] || One or two of the proposed days can be shifted to [https://www.timeanddate.com/worldclock/converter.html?iso=20211025T120000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 25, 12:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211025T150000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 25, 15:00 UTC] (preferred), or [https://www.timeanddate.com/worldclock/converter.html?iso=20211029T120000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 29, 12:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211029T150000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 29, 15:00 UTC] || WebRTC, MEIG || [https://www.w3.org/WoT/IG/wiki/F2F_meeting,_October_2021 WoT F2F Wiki] || || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T120000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 26, 12:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T150000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 26, 15:00 UTC], [https://www.timeanddate.com/worldclock/converter.html?iso=20211027T120000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 27, 12:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211027T150000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 27, 15:00 UTC], and [https://www.timeanddate.com/worldclock/converter.html?iso=20211028T120000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 28, 12:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211028T150000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 28, 15:00 UTC] Note that WebRTC will conflict from 15:00 to 16:00 on 28 October and MEIG will conflict from 14:00 to 15:00 on 28 October<br />
|-<br />
| Jan-Ivar Bruaroey & Will Law || WebTransport Meeting || [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T210000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 26, 21:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T223000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 26, 22:30 UTC] || [https://www.timeanddate.com/worldclock/converter.html?iso=20211027T210000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 27, 21:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211027T230000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 27, 23:00 UTC] || WebRTC, MEIG || [https://www.w3.org/wiki/WebTransport/TPAC_2021 Agenda] ||[https://www.w3.org/wiki/WebTransport/TPAC_2021 See the WG Agenda] || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T210000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 26, 21:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T223000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 26, 22:30 UTC]<br />
|-<br />
| Bernard Aboba, Harald Alvestrand, Jan-Ivar Bruaroey || WebRTC || Oct 28, 15:00 UTC to 16:00 UTC || Oct 29, 15:00 UTC to 16:00 UTC || WebTransport, Media WG || [https://www.w3.org/2011/04/webrtc/wiki/TPAC_2021#WebRTC_WG_Meeting agenda] || https://meet.google.com/rcd-qate-gwo || '''OPTION 1 CONFIRMED''': Oct 28, 15:00 UTC to 16:00 UTC on <br />
|-<br />
| Adrian Hope-Bailie, Nick Telford-Reed || Web Payments WG || 25-28 October, each day [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T140000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 14:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T160000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 16:00 UTC] || || || [https://github.com/w3c/webpayments/wiki/Agenda-TPAC2021 WPWG agenda] || See the [https://github.com/w3c/webpayments/wiki/Agenda-TPAC2021 WPWG agenda]|| '''OPTION 1 CONFIRMED''' 25-28 October, each day [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T140000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 14:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T160000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 16:00 UTC]<br />
|-<br />
| Ian Jacobs, Bastien Latge, Christina Hulka || Web Payment Security IG || CANCELED|| || || TBD || || NOT INCLUDED to the TPAC agenda<br />
|-<br />
| Wendy Reid, Dave Cramer, Shinya Takami || EPUB 3 WG || 29 October [https://www.timeanddate.com/worldclock/converter.html?iso=20211029T000000&p1=250&p2=248&p3=195&p4=770&p5=1440 0:00-3:00 UTC] and 29 October [https://www.timeanddate.com/worldclock/converter.html?iso=20211027T140000&p1=250&p2=248&p3=195&p4=770 14:00-17:00 UTC] || || None || [https://www.w3.org/events/meetings/c8ee0d57-8383-4cd1-bc9f-dec4f913c2ca Day 1], [https://www.w3.org/events/meetings/a1c8ce2e-f205-451f-a6b5-3a41438bcebc Day 2] || [https://www.w3.org/events/meetings/c8ee0d57-8383-4cd1-bc9f-dec4f913c2ca/edit#joining Meeting Details]] || '''OPTION 1 CONFIRMED''' 29 October [https://www.timeanddate.com/worldclock/converter.html?iso=20211029T000000&p1=250&p2=248&p3=195&p4=770&p5=1440 0:00-3:00 UTC]and 29 October [https://www.timeanddate.com/worldclock/converter.html?iso=20211029T140000&p1=250&p2=248&p3=195&p4=770 14:00-17:00 UTC]<br />
|-<br />
| Brent Zundel, Wayne Chang || VCWG || 26 October [https://www.timeanddate.com/worldclock/fixedtime.html?msg=VCWG+at+TPAC+Day+1&iso=20211026T11&p1=43&ah=2 15:00 UTC to 17:00 UTC] and 27 October [https://www.timeanddate.com/worldclock/fixedtime.html?msg=VCWG+at+TPAC+Day+2&iso=20211027T11&p1=43&ah=2 15:00 UTC to 17:00 UTC] || || EPUB 3 WG || TBD || [https://www.w3.org/events/meetings/e0471fdb-3647-4c74-a040-8bbad6e475a2/edit#joining calendar info] || '''OPTION 1 CONFIRMED''' 26 October [https://www.timeanddate.com/worldclock/fixedtime.html?msg=VCWG+at+TPAC+Day+1&iso=20211026T11&p1=43&ah=2 15:00 UTC to 17:00 UTC] and 27 October [https://www.timeanddate.com/worldclock/fixedtime.html?msg=VCWG+at+TPAC+Day+2&iso=20211027T11&p1=43&ah=2 15:00 UTC to 17:00 UTC]<br />
|-<br />
| Marcos Caceres, Leonie Watson || WebAppsWG || [https://www.timeanddate.com/worldclock/converter.html?iso=20211025T210000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 25, 21:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211027T230000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 27, 23:00 UTC] || [https://www.timeanddate.com/worldclock/converter.html?iso=20211027T210000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 27, 21:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211027T230000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 27, 23:00 UTC] || DAS, Editing, WebAppsSec || [https://github.com/w3c/webappswg/wiki/TPAC-2021 Agenda] || [https://www.w3.org/events/meetings/4eee203e-9515-4f84-9c20-ed636be71fbc GamePad - 21 October 2021, 23:00 - 22 October 2021, 00:00 UTC] <br> [https://www.w3.org/events/meetings/846fb79f-a5c9-4485-8d05-291e12d85f0e Web Manifest 25 October 2021, 21:00 - 23:00 UTC]<br>Zoom set up on Cvent: the host needs to use this [https://zoom.us/s/94632797975?zak=eyJ0eXAiOiJKV1QiLCJzdiI6IjAwMDAwMSIsInptX3NrbSI6InptX28ybSIsImFsZyI6IkhTMjU2In0.eyJhdWQiOiJjbGllbnRzbSIsInVpZCI6InlpRXdsZTRjUTlPZDBpNnhrVm5peXciLCJpc3MiOiJ3ZWIiLCJzdHkiOjk5LCJ3Y2QiOiJhdzEiLCJjbHQiOjAsIm1udW0iOiI5NDYzMjc5Nzk3NSIsInN0ayI6ImlMdkhxR00wR0ZoaXdhR0I5dk8zSE9oQTNPWlpfRDc5YUJLRnRPcDlnUmsuQmdaZ1RYUkVTaXRJWlU5V1VEaDVhalpKWmtaNFZUUlFiVEJSU25WdU9YZG5MMHRsVDFkeU1FTkxVWGQ0ZGsxNmEyNWFjamxNYURGWFUwTlNUVVJQVFZkTlExTmFZMVpCUkdVNGJHRTVUaXRVVGtabWFWWkxUbVpoZWtKbU1rNURLMjh6QUFBTWNtVnNjSGhYTDFWRFowRTlBQU5oZHpFQUFBRjhnMklDRkFBU2RRQUFBQSIsImV4cCI6MTY0MjA2NzgxMCwiaWF0IjoxNjM0MjkxODEwLCJhaWQiOiJBUUlheUNVd1RqS3BEVDdnVDFyLXV3IiwiY2lkIjoiIn0.tLFdmFHHO6KXbu193hTh6rHPz4MA5Oq8wjJk7eS6-4s Host link]. The other attendees will connect to Cvent and click on the join session button (FYI here is the [https://zoom.us/j/94632797975?pwd=anRlQ2ovNXhpVGhBL25vdmNkQWd5UT09 attendee URL])<br> [https://www.w3.org/events/meetings/916336d3-0c47-46b8-9f03-3ecfe991749d WebApps Roundtable - 26 October 2021, 21:00 - 23:00 UTC] Zoom set up on Cvent: the host needs to use this [https://zoom.us/s/98953364903?zak=eyJ0eXAiOiJKV1QiLCJzdiI6IjAwMDAwMSIsInptX3NrbSI6InptX28ybSIsImFsZyI6IkhTMjU2In0.eyJhdWQiOiJjbGllbnRzbSIsInVpZCI6IktKcnFoYnByU1MtY2duay1qOEdXMkEiLCJpc3MiOiJ3ZWIiLCJzdHkiOjk5LCJ3Y2QiOiJhdzEiLCJjbHQiOjAsIm1udW0iOiI5ODk1MzM2NDkwMyIsInN0ayI6IkowdGF0STZJeEdQRGtvVnozNkRyT1liTGlkM0xGaHlmSm9sTzZnVC0waDAuQmdaZ2JWQkJPSEJvTUhsbkwwNTBlVWhSUkVoR1drVlZTbVZsTVhOeFRteFpRV2t3TmxONGNXNVVTV2wyVjJ3NFFsUklhelIzV1VwSFUwTlNUVVJQVFZkTlExTmFZMVpCUkdVNGJHRTVUaXRVVGtabWFWWkxUbVpoZWtKbU1rNURLMjh6QUFBTWNtVnNjSGhYTDFWRFowRTlBQU5oZHpFQUFBRjhnekZqdEFBU2RRQUFBQSIsImV4cCI6MTY0MjA2NDYyNCwiaWF0IjoxNjM0Mjg4NjI0LCJhaWQiOiJBUUlheUNVd1RqS3BEVDdnVDFyLXV3IiwiY2lkIjoiIn0.Q6QF-IRfJE593DVubFlycSNfK6ZNXJnSueq0wPsK9zQ Host link]. The other attendees will connect to Cvent and click on the join session button (FYI here is the [https://zoom.us/j/98953364903?pwd=bGhGdVoveEo5ZHZDQ2hYbFREYVNVQT09 attendee URL]) || '''OPTION 1 CONFIRMED''' 25 and 26 OCT. 21:00-23:00UTC<br />
|-<br />
| Angel Li, Yongjing Zhang, Ming Zu || MiniApps WG || [https://www.timeanddate.com/worldclock/converter.html?iso=20211028T120000&p1=33&p2=43&p3=224&p4=248&p5=195&p6=1440 Oct 28, 12:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211028T120000&p1=33&p2=43&p3=224&p4=248&p5=195&p6=1440 Oct 28, 14:00 UTC] || || MiniApps CG might join one hour as well || [https://github.com/w3c/miniapp/issues/172 agenda] || [https://www.w3.org/events/meetings/fff7abb3-54ed-4631-b5e6-df9ff47bb980 calendar info] || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/converter.html?iso=20211028T120000&p1=33&p2=43&p3=224&p4=248&p5=195&p6=1440 Oct 28, 12:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211028T120000&p1=33&p2=43&p3=224&p4=248&p5=195&p6=1440 Oct 28, 14:00 UTC]<br />
|-<br />
| Addison Phillips || Internationalization (I18N) WG || [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T140000&p1=33&p2=43&p3=224&p4=248&p5=195&p6=1440&p7=136&p8=37 26 October 2021 14:00 UTC] || || || [https://www.w3.org/wiki/I18N_2021_TPAC agenda] || [https://www.w3.org/2017/09/i18n-meeting-info.html Zoom &amp; IRC info (member only)] || '''OPTION 1 Confirmed''' [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T140000&p1=33&p2=43&p3=224&p4=248&p5=195&p6=1440&p7=136&p8=37 26 October 2021 14:00 UTC]<br />
|-<br />
| Travis Leithead & Johannes Wilm || Web Editing WG || [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T140000&p1=33&p2=43&p3=224&p4=248&p5=195&p6=1440&p7=136&p8=37 29 October 2021 16:00 UTC] || || WebApps || [https://github.com/w3c/editing/labels/Agenda%2B agenda] || [https://meet.google.com/pdx-dnmm-cen Google Hangouts (open also to non-members)]<br>IRC: [https://irc.w3.org irc.w3.org] #editing || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T140000&p1=33&p2=43&p3=224&p4=248&p5=195&p6=1440&p7=136&p8=37 29 October 2021 16:00 UTC]<br />
|-<br />
| Anssi Kostiainen & Reilly Grant || Devices and Sensors WG || [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20211027T05 27-29 October 2021] each day 5:00-7:00 UTC || || WebML, Second Screen || [https://github.com/w3c/devicesensors-wg/issues/47 agenda] || [https://www.w3.org/events/meetings/c1d1adc0-7093-4dac-97a2-a37c4526fb08 calendar info - day 1/3]<br>[https://www.w3.org/events/meetings/c8a10439-616e-4784-b41a-0440acf4bccb calendar info - day 2/3]<br>[https://www.w3.org/events/meetings/1577c6af-a098-48bc-89d4-2618ddde3ebc calendar info - day 3/3] || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20211027T05 27-29 October 2021] each day 5:00-7:00 UTC <br />
|-<br />
| Anssi Kostiainen || Web Machine Learning WG || [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20211026T14 26-28 October 2021] each day 14:00-15:00 UTC || || DAS, Second Screen || [https://github.com/webmachinelearning/meetings/issues/18 agenda] || [https://www.w3.org/events/meetings/cfb1bec6-948f-4651-802e-f4a10c1c7ab2 calendar info - day 1/3] [https://www.w3.org/events/meetings/e70e2b4c-9313-45ec-a16e-be9746a49b80 calendar info - day 2/3] [https://www.w3.org/events/meetings/9fdaa3af-5858-46c8-8ecf-05384a15636e calendar info - day 3/3] || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20211026T14 26-28 October 2021] each day 14:00-15:00 UTC <br />
|-<br />
| Anssi Kostiainen & Louay Bassbouss || Second Screen WG || [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20211025T14 25 October 2021 14:00-15:00 UTC] and [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20211026T05 26 Oct 2021 5:00-6:00 UTC] || || DAS, WebML || [https://github.com/w3c/secondscreen-wg/issues/3 agenda] || [https://www.w3.org/events/meetings/cbb60781-e18b-4fd9-b6bf-464df6b6ad03 calendar info - day 1/2]<br>[https://www.w3.org/events/meetings/b2d24686-103a-4eb9-8499-b3a35a4771a7 calendar info - day 2/2] || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20211025T14 25 October 2021 14:00-15:00 UTC] and [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20211026T05 26 Oct 2021 5:00-6:00 UTC] <br />
|-<br />
| Brent Zundel, Dan Burnett || DID WG || 28 October [https://www.timeanddate.com/worldclock/fixedtime.html?msg=DID+WG+at+TPAC+Day+1&iso=20211028T11&p1=43&ah=2 15:00 UTC to 17:00 UTC] || || EPUB 3 WG || [https://www.w3.org/events/meetings/7a3923ee-8744-47d3-9802-a6a85e2fa50b#agenda Agenda] || [https://lists.w3.org/Archives/Member/member-did-wg/2020Jun/0000.html see dial information] || '''OPTION 1 CONFIRMED''' 28 October [https://www.timeanddate.com/worldclock/fixedtime.html?msg=DID+WG+at+TPAC+Day+1&iso=20211028T11&p1=43&ah=2 15:00 UTC to 17:00 UTC]<br />
|-<br />
| Nic Jansma, Yoav Weiss || WebPerf || [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20211025T15 25-29 October 2021 8-11am Pacific], every day''' || || || [https://docs.google.com/document/d/1GQpM8IvL4feXQ0oQdCQIPKhZZkMLNTYJQhBUntMxPkI/edit#heading=h.odc700in1ypg agenda] || [https://meet.google.com/ayk-ipmq-kjv meeting link] || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20211025T15 25-29 October 2021 8-11am Pacific], every day''' <br />
|-<br />
| Tatsuya Igarashi & Chris Lorenzo & Chris Needham || Media & Entertainment IG || [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20211025T14 25 Oct 2021 14:00-16:00 UTC] and [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20211027T05 27 Oct 2021 5:00-6:00 UTC] || || Media WG, Web Transport WG || [https://www.w3.org/events/meetings/5a432437-7170-4e79-9090-1e92836d5134 Agenda (Meeting 1)]<br>[https://www.w3.org/events/meetings/e8d07212-25b8-4f4c-8d38-943ed0a6130f Agenda (Meeting 2)] || [https://www.w3.org/events/meetings/5a432437-7170-4e79-9090-1e92836d5134 Calendar Info (Meeting 1)]<br>[https://www.w3.org/events/meetings/e8d07212-25b8-4f4c-8d38-943ed0a6130f Calendar Info (Meeting 2)] || '''OPTION 1 CONFIRMED [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20211025T14 25 Oct 2021 14:00-16:00 UTC] and [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20211027T05 27 Oct 2021 5:00-6:00 UTC]<br />
|-<br />
| Wendy Seltzer || Improving Web Advertising BG || 27 Oct 23:00-0:00UTC and 28 Oct 15:00-16:00UTC || OPTION 2: Date and times in [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20201001T140000 UTC] 2 times, one Asia/Pacific-friendly || || TBD || TBD || '''OPTION 1 CONFIRMED''' 27 Oct 23:00-0:00UTC and 28 Oct 15:00-16:00UTC<br />
|-<br />
| Sudeep Divakaran, Song Xu, Dan Druta || Web & Networks IG || October 28 2pm-3pm UTC || October 28 3pm-4pm UTC || || [https://www.w3.org/wiki/Networks/TPAC2021#Meeting_:_Web_.26_Networks_IG_Meeting Agenda] || Webex defined in [https://www.w3.org/events/meetings/c98bdb94-1917-4035-a677-d1cb3a5419c3 WNIG group calendar] || '''OPTION 1 CONFIRMED''' October 28 2pm-3pm UTC<br />
|-<br />
| Hongchan Choi, Matthew Paradis || Audio WG || October 25,27,28 3pm-5pm UTC, October 26 4pm-5pm UTC || || WebRTC, Media || [https://docs.google.com/document/d/1V3vhlOa5DQVHI3azwk3V3pBfq_R2ZUuwLVSkO3xCbH4/edit?usp=sharing Agenda] || https://meet.google.com/oxy-ouyf-ith || '''OPTION 1 CONFIRMED''' October 25,27,28 3pm-5pm UTC, October 26 4pm-5pm UTC Note that WebRTC will conflict from 15:00 to 16:00 on 28 October<br />
|-<br />
| James Nurthen || ARIA ||[https://www.timeanddate.com/worldclock/meetingdetails.html?year=2021&month=10&day=28&hour=14&min=0&sec=0&p1=224&p2=179&p3=248 Oct 28, 14:00-15:00 UTC] || || CSS, APA, I18N, EPUB || https://github.com/w3c/aria/issues/1619 , https://github.com/w3c/aria/issues/1620 || [https://www.w3.org/events/meetings/1d106c10-842d-44d2-a43f-bccfa7841b62 ARIA Calendar] || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/meetingdetails.html?year=2021&month=10&day=28&hour=14&min=0&sec=0&p1=224&p2=179&p3=248 Oct 28, 14:00-15:00 UTC]<br />
|-<br />
| James Nurthen || ARIA ||[https://www.timeanddate.com/worldclock/meetingdetails.html?year=2021&month=10&day=28&hour=16&min=0&sec=0&p1=224&p2=179&p3=248 Oct 28, 16:00-18:00 UTC] || || || Discuss issues surrounding ARIA representation in IDL including Nullable Strings (https://github.com/w3c/aria/issues/1598, https://github.com/w3c/aria/issues/1058) and Element References (https://github.com/w3c/aria/issues/1596) || [https://www.w3.org/events/meetings/e8be2735-d90b-4619-a25c-d25c0abdd965 ARIA Calendar] || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/meetingdetails.html?year=2021&month=10&day=28&hour=16&min=0&sec=0&p1=224&p2=179&p3=248 Oct 28, 16:00-18:00 UTC]<br />
|-<br />
| Tzviya Siegman, Ralph Swick || Publishing BG, Publishing CG, EPUB WG ||[https://www.timeanddate.com/worldclock/meetingdetails.html?year=2021&month=10&day=28&hour=13&min=0&sec=0&p1=224&p2=179&p3=248 Oct 27, 13:00-14:30 UTC] || || EPUB WG || Discuss plans on the work on Digital Publishing beyond EPUB || [https://www.w3.org/events/meetings/447c6288-6cb9-4134-86c0-b419edd0cea3 calendar info] || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/meetingdetails.html?year=2021&month=10&day=28&hour=13&min=0&sec=0&p1=224&p2=179&p3=248 Oct 27, 13:00-14:30 UTC]<br />
|-<br />
| Caroline Burle, Peter Winstanley || Dataset Exchange Working Group ||[https://www.timeanddate.com/worldclock/meetingdetails.html?year=2021&month=10&day=26&hour=20&min=0&sec=0&p1=43&p2=195&p3=224&p4=33&p5=248&p6=136&p7=64&p8=216&p9=152 Oct 26, 20:00-21:00 UTC] || || || Discuss the next steps for the Working Group || [https://www.w3.org/events/meetings/7c0849e5-1088-455e-8ee5-1a5c942af363/20211019T220000 DX Calendar] || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/meetingdetails.html?year=2021&month=10&day=26&hour=20&min=0&sec=0&p1=43&p2=195&p3=224&p4=33&p5=248&p6=136&p7=64&p8=216&p9=152 Oct 26, 20:00-21:00 UTC]<br />
|-<br />
|}<br />
<br />
== CG Group Meetings details ==<br />
<br />
Community Groups will be able to meet. <br />
CGs Chairs who can not edit this page should contact [mailto:w3t-tpregister@w3.org Events Team] stating their username . Access will be given.<br />
<br />
{| class="wikitable"<br />
|-<br />
! '''Chair name''' !! '''Group name''' !! '''OPTION 1: Date and times in [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20201001T140000 UTC]''' !! '''OPTION 2: Date and times in [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20201001T140000 UTC]''' !! '''With which groups there should be no overlap''' !! '''Link to agenda''' See "Group meetings attendance section|| '''Link to Meeting coordinates (service, code, password)''' See "Group meetings attendance section|| CONFIRMED date and times by W3C<br />
|-<br />
| Giulia Marangoni, Laurent Le Meur || TDM Reservation Protocol || Oct 26, 15:00 UTC to 16:00 UTC || Oct 28, 15:00 UTC to 16:00 UTC || - || [https://www.w3.org/community/tdmrep/2021/10/19/community-group-meeting-at-w3c-tpac-2021/ Agenda] || [https://us06web.zoom.us/j/93756647259?pwd=Y01HQjVxdG84UE1ST0dwQXdsdHRrZz09 Zoom] || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/fixedtime.html?msg=TDM+Res+Protocol&iso=20211026T15&p1=1440&ah=1 Oct 26, 15:00 UTC to 16:00 UTC]<br />
|-<br />
| Michael Good, Adrian Holovaty, Daniel Spreadbury || Music Notation || Oct 28, 14:00 UTC to 16:00 UTC || Oct 27, 14:00 UTC to 16:00 UTC || Audio WG, Synchronized Multimedia for Publications CG || [https://www.w3.org/community/music-notation/2021/09/28/co-chair-meeting-september-28-2021/ Agenda] ||[https://peaksware.zoom.us/j/98085343649?pwd=QTIwK2hscmJ0OXVielBORXZjOE51Zz09 Zoom] || '''OPTION 1 CONFIRMED''' Oct 28, 14:00 UTC to 16:00 UTC<br />
|-<br />
| Deborah Dahl, Dirk Schnelle-Walka, Brian Susko, Marco Kerwitz|| Voice Interaction Community Group || Oct 27, 15:00 UTC to 16:00 UTC || ⌠||âŚ|| [https://lists.w3.org/Archives/Public/public-voiceinteraction/2021Oct/0012.html Agenda]||[https://mit.zoom.us/j/96653575919?pwd=eFgrUE5WYlJyU2RDc2dic05YK0tkUT09 Zoom] || '''OPTION 1 CONFIRMED''' Oct 27, 15:00 UTC to 16:00 UTC<br />
|-<br />
| Bev Corwin, Noreen Whysel, Shari Thurow || Information Architecture Community Group || [https://www.timeanddate.com/worldclock/converter.html?iso=20211028T150000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240&p8=1440 Oct 27, 13:00 UTC to 14:00 UTC] || ⌠|| ⌠|| ⌠|| Zoom [https://us02web.zoom.us/j/82459868901?pwd=ZnpDMUZlTElURDBrbFZUVTF3Mkp4Zz09 Zoom] || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/converter.html?iso=20211028T150000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240&p8=1440 Oct 27, 13:00 UTC to 14:00 UTC]<br />
|-<br />
| Tom Greenaway, NoÍl Meudec || Games Community Group || Oct 26, 14:00 UTC to 15:00 UTC || Oct 27, 14:00 UTC to 15:00 UTC || ⌠|| [https://www.w3.org/events/meetings/dcf599f4-549c-4a8a-81a5-6437429bac3c Agenda] || [https://mit.zoom.us/j/91631568635 Zoom info] || '''OPTION 1 CONFIRMED''' Oct 26, 14:00 UTC to 15:00 UTC<br />
|-<br />
| Heather Vescent, Mike Prorock, Wayne Chang || Credentials Community Group || 26 Oct 16:00 UTC to 17:00 UTC (9am PDT, 12pm EDT, 5pm BST, 6pm CEST / 6AM+1 NZDT) || ⌠|| ⌠|| Overview of the CCG and Work Items || https://meet.w3c-ccg.org/weekly || '''OPTION 1 CONFIRMED''' 26 Oct 16:00 UTC to 17:00 UTC (9am PDT, 12pm EDT, 5pm BST, 6pm CEST / 6AM+1 NZDT)<br />
|-<br />
| Jake Holland || Multicast Community Group || 27 Oct 15:00 UTC to 16:00 UTC (8am PDT, 11am EDT) || ... || webrtc, web-network, media-and-entertainment, webtransport || [https://github.com/w3c/multicast-cg/blob/main/meetings/minutes/tpac-2021-agenda.md Agenda] || https://akamai.webex.com/akamai/j.php?MTID=m82facd432d2daa720ebbb302d17e256c <br/>pw=yay-multicast!, #2598 001 6648 || '''OPTION 1 CONFIRMED''' 27 Oct 15:00 UTC to 16:00 UTC (8am PDT, 11am EDT)<br />
|-<br />
| Timothy Hatcher, Simeon Vincent || WebExtensions Community Group || [https://www.timeanddate.com/worldclock/converter.html?iso=20211028T150000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240&p8=1440 Oct 28 2021, 15:00 UTC to 16:00 UTC] || ⌠|| Service Workers, WebDriver BiDi || [https://www.w3.org/events/meetings/f13adee3-d80c-4348-bc2a-64e006b0db4a/20211028T150000 Agenda] || [https://www.w3.org/events/meetings/f13adee3-d80c-4348-bc2a-64e006b0db4a/20211028T150000 Meeting Coordinates] || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/converter.html?iso=20211028T150000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240&p8=1440 Oct 28 2021, 15:00 UTC to 16:00 UTC] <br />
|-<br />
| Peter Rushforth || Web Maps Community Group || [https://www.timeanddate.com/worldclock/converter.html?iso=20211029T170000&p1=1440&p2=188&p3=43&p4=195&p5=136&p6=239&p7=137# Oct 29 2021, 17:00 UTC to 18:00 UTC] || ⌠|| SVG *G, Devices and Sensors, AR/XR || [https://www.w3.org/community/maps4html/wiki/TPAC_2021_Agenda Agenda] || Zoom set up on Cvent: the host needs to use this [https://zoom.us/s/94788718871?zak=eyJ0eXAiOiJKV1QiLCJzdiI6IjAwMDAwMSIsInptX3NrbSI6InptX28ybSIsImFsZyI6IkhTMjU2In0.eyJhdWQiOiJjbGllbnRzbSIsInVpZCI6IlBrRVVyNFowU0lHMUw5Umxtd1RSV1EiLCJpc3MiOiJ3ZWIiLCJzdHkiOjk5LCJ3Y2QiOiJhdzEiLCJjbHQiOjAsIm1udW0iOiI5NDc4ODcxODg3MSIsInN0ayI6ImVwcE1hanVsTlRrSWFyeVZhVUFWaXhmd25iLVk4OWlneHJjdjNSMkNqOUkuQmdaZ1JFd3pPVmR2TldSbFZGaFpXVkZrWjFrdlRWazRaR0l4VVhGRFlrZEJhVlpJTUROdmNrdHJNa2RyT1ZCRFIwRk9URVpaTWxkSFUwTlNUVVJQVFZkTlExTmFZMVpCUkdVNGJHRTVUaXRVVGtabWFWWkxUbVpoZWtKbU1rNURLMjh6QUFBTWNtVnNjSGhYTDFWRFowRTlBQU5oZHpFQUFBRjh0VkJWOGdBU2RRQUFBQSIsImV4cCI6MTY0MjkwNTUxMywiaWF0IjoxNjM1MTI5NTEzLCJhaWQiOiJBUUlheUNVd1RqS3BEVDdnVDFyLXV3IiwiY2lkIjoiIn0.-g8Eze5WyDHd1s1_8oYsVpEeGKmKZI_YVaAfIA5sR34 Host link]. The other attendees will connect to Cvent and click on the join session button (FYI here is the [https://zoom.us/j/94788718871?pwd=Mjl6RGRpb25NUnZJdTBnWVNLU2tzdz09 attendee URL]) || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/converter.html?iso=20211029T170000&p1=1440&p2=188&p3=43&p4=195&p5=136&p6=239&p7=137# Oct 29 2021, 17:00 UTC to 18:00 UTC]<br />
|-<br />
| Sarven Capadisli || Solid Community Group || 27 Oct 14:00 UTC to 16:00 UTC || 27 Oct 14:30 UTC to 16:30 UTC || ⌠|| [https://github.com/solid/specification/blob/main/meetings/2021-10-27.md Agenda] || https://meet.jit.si/solid-specification || '''OPTION 2 CONFIRMED''' 27 Oct 14:30 UTC to 16:30 UTC<br />
|-<br />
| Paola Di Maio|| AI KR CG || Oct 25 2021, 12:00 UTC to 14:00 UTC || ⌠|| || <br />
[https://www.w3.org/community/aikr/wiki/AI_KR_CG_@TPAC_2021 Agenda]<br />
|| Zoom set up on Cvent: the host needs to use this [https://zoom.us/s/99055638533?zak=eyJ0eXAiOiJKV1QiLCJzdiI6IjAwMDAwMSIsInptX3NrbSI6InptX28ybSIsImFsZyI6IkhTMjU2In0.eyJhdWQiOiJjbGllbnRzbSIsInVpZCI6IjR1S0t5XzY0VGFDZGw4Q3Vvb2FpelEiLCJpc3MiOiJ3ZWIiLCJzdHkiOjk5LCJ3Y2QiOiJhdzEiLCJjbHQiOjAsIm1udW0iOiI5OTA1NTYzODUzMyIsInN0ayI6IldUc0VycWlTNzVWMEpudFR0SVloOUFTb1JzNDdvVVhIbGFnbEUzSDJEWkEuQmdaZ05sUlBMMHh2ZFUxRVRscGpXbGxaV2xKa1pVUnJWV1ZwWmxKR1lYbzRaR3h5T0hwc1FXNVBiek4zUWpVelJucFJkbWRMVlV0SFUwTlNUVVJQVFZkTlExTmFZMVpCUkdVNGJHRTVUaXRVVGtabWFWWkxUbVpoZWtKbU1rNURLMjh6QUFBTWNtVnNjSGhYTDFWRFowRTlBQU5oZHpFQUFBRjhsalFOREFBU2RRQUFBQSIsImV4cCI6MTY0MjM4MzU2NiwiaWF0IjoxNjM0NjA3NTY2LCJhaWQiOiJBUUlheUNVd1RqS3BEVDdnVDFyLXV3IiwiY2lkIjoiIn0.b3ZowvSuBCXjt5bv-KA0amxJYDvmwoYdBRYhUpi3fWU Host link]. The other attendees will connect to Cvent and click on the join session button (FYI here is the [https://zoom.us/j/99055638533?pwd=TUxwcTMrUktKM3QwVGpQbzR2SDZtUT09 attendee URL]) || '''OPTION 1 CONFIRMED''' Oct 25 2021, 12:00 UTC to 14:00 UTC<br />
|-<br />
| Christopher Patnoe|| Immersive Captions || 26 Oct 2021, 14:00 UTC to 17:00 UTC || 27 Oct 2021, 14:00 UTC to 17:00 UTC || || [https://www.w3.org/community/immersive-captions/2021/10/18/community-group-meeting-at-w3c-tpac-2021/ Agenda] || Zoom set up on Cvent: the host needs to use this [https://zoom.us/s/98047409225?zak=eyJ0eXAiOiJKV1QiLCJzdiI6IjAwMDAwMSIsInptX3NrbSI6InptX28ybSIsImFsZyI6IkhTMjU2In0.eyJhdWQiOiJjbGllbnRzbSIsInVpZCI6Ik5lWGNxQTBEUjBhZXNod25JZWppOEEiLCJpc3MiOiJ3ZWIiLCJzdHkiOjk5LCJ3Y2QiOiJhdzEiLCJjbHQiOjAsIm1udW0iOiI5ODA0NzQwOTIyNSIsInN0ayI6IkgwVWlxalp3NnRLa2o3WXhValRfaGVsSkdkRkgxMkM1MGZ1Y1dtaVpYQWcuQmdaZ2EwRm9iaTl1Ykc1cmVrdEVXa3B3YTFwYWNHZHBVRTltZUZRd1QyOWxjblZaVGxaWFNWcDJTRmh3SzJzM1ZIRktZa3hKUVcweVUwTlNUVVJQVFZkTlExTmFZMVpCUkdVNGJHRTVUaXRVVGtabWFWWkxUbVpoZWtKbU1rNURLMjh6QUFBTWNtVnNjSGhYTDFWRFowRTlBQU5oZHpFQUFBRjhrUEV3ZUFBU2RRQUFBQSIsImV4cCI6MTY0MjI5NTI5OCwiaWF0IjoxNjM0NTE5Mjk4LCJhaWQiOiJBUUlheUNVd1RqS3BEVDdnVDFyLXV3IiwiY2lkIjoiIn0.FEg8yWXf4lBoc1Mce_KfeTuMOZB0q6nUAs2ciYm1zkE Host link]. The other attendees will connect to Cvent and click on the join session button (FYI here is the [https://zoom.us/j/98047409225?pwd=Ly93ZXdScVRzM0ZQOW14S2piTzZEUT09 attendee URL]) ||'''OPTION 1 CONFIRMED''' Oct 26 2021, 15:00 UTC to 16:30 UTC<br />
|-<br />
| Aram Zucker-Scharff, Sean Turner|| PATCG || 29 Oct 2021, 16:00 UTC - 17:00 UTC || || || Initial meeting of Private Advertising Technology CG || || '''OPTION 1 CONFIRMED''' Oct 29 2021, 16:00 UTC to 17:00 UTC<br />
|}<br />
<br />
== Group Meetings attendance: '''Connecting to your meeting''' ==<br />
See [https://docs.google.com/document/d/19p6cA_TdMZ8yVQ_qBQITjfbLgeJ9KD3LK-LdlaR2ieA/edit?usp=sharing separate document]<br />
<br />
== Contacts ==<br />
If you need any assistance with planning your meeting, the [mailto:w3t-tpregister@w3.org Events Team] is here to help you.</div>Plehegarhttps://www.w3.org/wiki/index.php?title=TPAC/2021/GroupMeetings&diff=114208TPAC/2021/GroupMeetings2021-10-20T12:06:37Z<p>Plehegar: Added DXWG</p>
<hr />
<div>==Introduction ==<br />
<br />
Due to uncertainties in the health and sanitary situation, TPAC 2021 will be a fully remote event. You will find below the schedule:<br />
<br />
* 12 October: AC Meeting<br />
* 18 - 22 October : Breakout sessions <br />
* '''25 - 29 October : WG/IG/BG/CG meetings and Joint Group Meetings<br />
'''<br />
The usual TPAC objectives remain:<br />
<br />
* Groups schedule a Group meeting to which observers are invited so that members of our community have the opportunity to see the work of the W3C groups.<br />
* Groups schedule joint meetings with other Groups<br />
* Breakout sessions will discuss specific topics of interest.<br />
<br />
We also invite you to read further details about goals, opportunities and good practices in organizing [https://www.w3.org/Guide/meetings/tpac.html '''TPAC group and Joint Meetings''']<br />
<br />
Those who are eligible to attend the group and joint meetings are:<br />
<br />
* a participant in a W3C Working, Interest, Business or Community Group scheduled to meet for TPAC<br />
* a W3C Member Advisory Committee Representative<br />
* a participant on the Advisory Board or the TAG<br />
* an employee of a W3C member organization<br />
* an invited Guest<br />
* a W3C Evangelist<br />
* W3C staff or W3C Office chapter<br />
<br />
Observer and Guest Attendance: Eligible participants may request to attend as an Observer via the registration form. <br /><br />
Community Group Participants: Any participant of a CG scheduled to meet will be able to attend other group meetings if one of the above criteria is fulfilled.<br />
<br />
'''Group chairs, please read the details below and fill in the appropriate table(s). <br />'''<br />
There are three different tables for the following meetings:<br />
* Working Group [WG], Interest Group [IG], Business Group [BG] Meetings<br />
* Community Group [CG] Meetings<br />
* Joint Group Meetings<br />
<br />
'''The meeting scheduling process is as follows:'''<br />
<br />
* Until 10 September please fill in the tables below with your preferred meeting dates and time. If flexible, please state a second option<br />
* The W3C Events Team will make sure that the meetings are well distributed within the week and will contact group to confirm the options they stated<br />
* 17 September: Group schedule confirmed<br />
* 20 September: Meeting registration opens<br />
<br />
Please do your best to select times that will allow a broad participation among meeting attendees and observers all around the globe.<br />
<br />
== Joint Group meetings ==<br />
<br />
Group Chairs, <br />
please coordinate with the groups you would like to meet with and fill in the following table.<br />
{| class="wikitable"<br />
|-<br />
! '''Chair name''' !! '''Group name''' !! '''OPTION 1: Date and times in [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20201001T140000 UTC]''' !! '''OPTION 2: Date and times in [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20201001T140000 UTC]''' !! '''With which groups there should be no overlap''' !! '''Link to agenda''' See "Group meetings attendance section" || '''Link to Meeting coordinates (service, code, password)''' See "Group meetings attendance section|| CONFIRMED date and times by W3C<br />
|-<br />
| Bernard Aboba, Harald Alvestrand, Jan-Ivar Bruaroey, Jer Noble, Chris Needham || WebRTC WG + Media WG + Audio WG|| [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T140000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 26, 14:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T160000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 26, 16:00 UTC] || [https://www.timeanddate.com/worldclock/converter.html?iso=20211027T140000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 27, 14:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211027T160000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 27, 16:00 UTC] || WebRTC, WebTransport, MEIG || [https://www.w3.org/2011/04/webrtc/wiki/TPAC_2021#Joint_WebRTC.2FMedia.2FAudio_WG_Meeting Agenda] || See https://www.w3.org/events/meetings/81d215c7-f4c2-4697-a4b4-985efba5427e || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T140000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 26, 14:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T160000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 26, 16:00 UTC]<br />
|-<br />
| Adrian Hope-Bailie, Nick Telford-Reed, John Fontana, Tony Nadalin || WPWG and WebAuthn || 27 OCT. 14-15 UTC || || || See [https://github.com/w3c/webpayments/wiki/Agenda-TPAC2021 WPWG agenda] || See [https://github.com/w3c/webpayments/wiki/Agenda-TPAC2021 WPWG agenda] || '''OPTION 1 CONFIRMED''' 27 Oct 14:00-15:00UTC<br />
|-<br />
| Adrian Hope-Bailie, Nick Telford-Reed, Addison Phillips || WPWG and I18N || 26 OCT. 15-15:30 UTC || || || See [https://github.com/w3c/webpayments/wiki/Agenda-TPAC2021 WPWG agenda] || See [https://github.com/w3c/webpayments/wiki/Agenda-TPAC2021 WPWG agenda] || '''OPTION 1 CONFIRMED''' 26 Oct 15:00-15:30UTC<br />
|-<br />
| Janina Sajka, Becky Gibson, Jeanne Spellman, Charles Adams, Alastair Campbell, Rachael Bradley Montgomery, Dave Cramer, Wendy Reid, Shinya Takami || APA, AGWG/Silver, EPUB || [https://www.timeanddate.com/worldclock/converter.html?iso=20211025T140000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 25, 14:00 UTC] for 1 hour || || || TBD || || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/converter.html?iso=20211025T140000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 25, 14:00-15:00 UTC]<br />
|-<br />
| Janina Sajka, Becky Gibson, Jason White, Lisa Seeman, Rain Michaels || APA Research Questions TF & APA/ARIA Cognitive TF || [https://www.timeanddate.com/worldclock/converter.html?iso=20211027T140000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240&p8=1440 Oct 27, 14:00 UTC] for 1 hour || || || [https://www.w3.org/WAI/GL/task-forces/coga/wiki/TPAC_2021_initial_planning#RQTF COGA's Proposed Agenda] || || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/converter.html?iso=20211027T140000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240&p8=1440 Oct 27, 14:00-15:00 UTC]<br />
|-<br />
| Janina Sajka, Becky Gibson, Sharon Snider Lionel Wolberger, Lisa Seeman, Rain Michaels || APA Personalization TF & APA/ARIA Cognitive TF || [https://www.timeanddate.com/worldclock/converter.html?iso=20211027T150000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240&p8=1440 Oct 27, 15:00 UTC] for 1 hour || || || [https://www.w3.org/WAI/GL/task-forces/coga/wiki/TPAC_2021_initial_planning#Personalization COGA's Proposed Topics] || || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/converter.html?iso=20211027T150000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240&p8=1440 Oct 27, 15:00-16:00 UTC]<br />
|-<br />
| Janina Sajka, Becky Gibson, Dave Cramer, Wendy Reid, Shinya Takami || APA and EPUB || [https://www.timeanddate.com/worldclock/converter.html?iso=20211028T140000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240&p8=1440 Oct 28, 14:00 UTC] for 2 hours || || || TBD || || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/converter.html?iso=20211028T140000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240&p8=1440 Oct 28, 14:00-16:00 UTC]<br />
|-<br />
| Christine Perey, Ada Rose Canon, AyĹegĂźl YĂśnet, Chris Wilson || IWWG and OGC GeoPose SWG / SDWWG || [https://www.timeanddate.com/worldclock/converter.html?iso=20211029T150000 Oct 29 15:00 UTC] || || || || || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/converter.html?iso=20211029T150000 Oct 29 15:00-16:00 UTC]<br />
|-<br />
| Christine Runnegar, Pete Snyder, Nick Doty, Wendy Reid, Dave Cramer, Shinya Takami || PING and EPUB3 WG || [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T150000 Oct 26 15:00 UTC] || || || || [https://www.w3.org/events/meetings/2e397c32-b5e1-4f5b-8789-741d09c285ed#general] || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T150000 Oct 26 15:00-16:00 UTC]<br />
|-<br />
|-<br />
| Janina Sajka, Becky Gibson, James Nurthen|| APA & ARIA: The Future of Accessibility APIs (Session 1)|| [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T160000 Oct 26 16:00 UTC] || || ||[https://www.w3.org/WAI/APA/wiki/Meetings/TPAC_2021#APA_.26_ARIA:_The_Future_of_Accessibility_APIs Link to APA & ARIA agenda] || ||<br />
|-<br />
|-<br />
| Janina Sajka, Becky Gibson, James Nurthen|| APA & ARIA: The Future of Accessibility APIs (Session 2)|| [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T100000 Oct 27 10:00 UTC] || || ||[https://www.w3.org/WAI/APA/wiki/Meetings/TPAC_2021#APA_.26_ARIA:_The_Future_of_Accessibility_APIs Link to APA & ARIA agenda] || ||<br />
|-<br />
|}<br />
<br />
== WG/IG/BG Group Meetings details ==<br />
<br />
Please let us know your preferred dates and times between the @@ - @@ time<br/><br />
<br />
{| class="wikitable"<br />
|-<br />
! '''Chair name''' !! '''Group name''' !! '''OPTION 1: Date and times in [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20201001T140000 UTC]''' !! '''OPTION 2: Date and times in [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20201001T140000 UTC]''' !! '''With which groups there should be no overlap''' !! '''Link to agenda''' See "Group meetings attendance section || '''Link to Meeting coordinates (service, code, password)''' See "Group meetings attendance section|| CONFIRMED date and times by W3C<br />
|-<br />
|Michael McCool & Sebastian Kaebisch || WoT Meeting || [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T120000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 26, 12:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T150000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 26, 15:00 UTC], [https://www.timeanddate.com/worldclock/converter.html?iso=20211027T120000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 27, 12:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211027T150000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 27, 15:00 UTC], and [https://www.timeanddate.com/worldclock/converter.html?iso=20211028T120000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 28, 12:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211028T150000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 28, 15:00 UTC] || One or two of the proposed days can be shifted to [https://www.timeanddate.com/worldclock/converter.html?iso=20211025T120000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 25, 12:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211025T150000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 25, 15:00 UTC] (preferred), or [https://www.timeanddate.com/worldclock/converter.html?iso=20211029T120000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 29, 12:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211029T150000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 29, 15:00 UTC] || WebRTC, MEIG || [https://www.w3.org/WoT/IG/wiki/F2F_meeting,_October_2021 WoT F2F Wiki] || || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T120000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 26, 12:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T150000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 26, 15:00 UTC], [https://www.timeanddate.com/worldclock/converter.html?iso=20211027T120000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 27, 12:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211027T150000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 27, 15:00 UTC], and [https://www.timeanddate.com/worldclock/converter.html?iso=20211028T120000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 28, 12:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211028T150000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 28, 15:00 UTC] Note that WebRTC will conflict from 15:00 to 16:00 on 28 October and MEIG will conflict from 14:00 to 15:00 on 28 October<br />
|-<br />
| Jan-Ivar Bruaroey & Will Law || WebTransport Meeting || [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T210000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 26, 21:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T223000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 26, 22:30 UTC] || [https://www.timeanddate.com/worldclock/converter.html?iso=20211027T210000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 27, 21:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211027T230000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 27, 23:00 UTC] || WebRTC, MEIG || [https://www.w3.org/wiki/WebTransport/TPAC_2021 Agenda] ||[https://www.w3.org/wiki/WebTransport/TPAC_2021 See the WG Agenda] || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T210000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 26, 21:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T223000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 26, 22:30 UTC]<br />
|-<br />
| Bernard Aboba, Harald Alvestrand, Jan-Ivar Bruaroey || WebRTC || Oct 28, 15:00 UTC to 16:00 UTC || Oct 29, 15:00 UTC to 16:00 UTC || WebTransport, Media WG || [https://www.w3.org/2011/04/webrtc/wiki/TPAC_2021#WebRTC_WG_Meeting agenda] || https://meet.google.com/rcd-qate-gwo || '''OPTION 1 CONFIRMED''': Oct 28, 15:00 UTC to 16:00 UTC on <br />
|-<br />
| Adrian Hope-Bailie, Nick Telford-Reed || Web Payments WG || 25-28 October, each day [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T140000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 14:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T160000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 16:00 UTC] || || || [https://github.com/w3c/webpayments/wiki/Agenda-TPAC2021 WPWG agenda] || See the [https://github.com/w3c/webpayments/wiki/Agenda-TPAC2021 WPWG agenda]|| '''OPTION 1 CONFIRMED''' 25-28 October, each day [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T140000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 14:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T160000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 16:00 UTC]<br />
|-<br />
| Ian Jacobs, Bastien Latge, Christina Hulka || Web Payment Security IG || CANCELED|| || || TBD || || NOT INCLUDED to the TPAC agenda<br />
|-<br />
| Wendy Reid, Dave Cramer, Shinya Takami || EPUB 3 WG || 29 October [https://www.timeanddate.com/worldclock/converter.html?iso=20211029T000000&p1=250&p2=248&p3=195&p4=770&p5=1440 0:00-3:00 UTC] and 29 October [https://www.timeanddate.com/worldclock/converter.html?iso=20211027T140000&p1=250&p2=248&p3=195&p4=770 14:00-17:00 UTC] || || None || TBD || [https://www.w3.org/events/meetings/c8ee0d57-8383-4cd1-bc9f-dec4f913c2ca/edit#joining calendar info]] || '''OPTION 1 CONFIRMED''' 29 October [https://www.timeanddate.com/worldclock/converter.html?iso=20211029T000000&p1=250&p2=248&p3=195&p4=770&p5=1440 0:00-3:00 UTC]and 29 October [https://www.timeanddate.com/worldclock/converter.html?iso=20211029T140000&p1=250&p2=248&p3=195&p4=770 14:00-17:00 UTC]<br />
|-<br />
| Brent Zundel, Wayne Chang || VCWG || 26 October [https://www.timeanddate.com/worldclock/fixedtime.html?msg=VCWG+at+TPAC+Day+1&iso=20211026T11&p1=43&ah=2 15:00 UTC to 17:00 UTC] and 27 October [https://www.timeanddate.com/worldclock/fixedtime.html?msg=VCWG+at+TPAC+Day+2&iso=20211027T11&p1=43&ah=2 15:00 UTC to 17:00 UTC] || || EPUB 3 WG || TBD || [https://www.w3.org/events/meetings/e0471fdb-3647-4c74-a040-8bbad6e475a2/edit#joining calendar info] || '''OPTION 1 CONFIRMED''' 26 October [https://www.timeanddate.com/worldclock/fixedtime.html?msg=VCWG+at+TPAC+Day+1&iso=20211026T11&p1=43&ah=2 15:00 UTC to 17:00 UTC] and 27 October [https://www.timeanddate.com/worldclock/fixedtime.html?msg=VCWG+at+TPAC+Day+2&iso=20211027T11&p1=43&ah=2 15:00 UTC to 17:00 UTC]<br />
|-<br />
| Marcos Caceres, Leonie Watson || WebAppsWG || [https://www.timeanddate.com/worldclock/converter.html?iso=20211025T210000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 25, 21:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211027T230000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 27, 23:00 UTC] || [https://www.timeanddate.com/worldclock/converter.html?iso=20211027T210000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 27, 21:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211027T230000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240 Oct 27, 23:00 UTC] || DAS, Editing, WebAppsSec || [https://github.com/w3c/webappswg/wiki/TPAC-2021 Agenda] || [https://www.w3.org/events/meetings/4eee203e-9515-4f84-9c20-ed636be71fbc GamePad - 21 October 2021, 23:00 - 22 October 2021, 00:00 UTC] <br> [https://www.w3.org/events/meetings/846fb79f-a5c9-4485-8d05-291e12d85f0e Web Manifest 25 October 2021, 21:00 - 23:00 UTC]<br>Zoom set up on Cvent: the host needs to use this [https://zoom.us/s/94632797975?zak=eyJ0eXAiOiJKV1QiLCJzdiI6IjAwMDAwMSIsInptX3NrbSI6InptX28ybSIsImFsZyI6IkhTMjU2In0.eyJhdWQiOiJjbGllbnRzbSIsInVpZCI6InlpRXdsZTRjUTlPZDBpNnhrVm5peXciLCJpc3MiOiJ3ZWIiLCJzdHkiOjk5LCJ3Y2QiOiJhdzEiLCJjbHQiOjAsIm1udW0iOiI5NDYzMjc5Nzk3NSIsInN0ayI6ImlMdkhxR00wR0ZoaXdhR0I5dk8zSE9oQTNPWlpfRDc5YUJLRnRPcDlnUmsuQmdaZ1RYUkVTaXRJWlU5V1VEaDVhalpKWmtaNFZUUlFiVEJSU25WdU9YZG5MMHRsVDFkeU1FTkxVWGQ0ZGsxNmEyNWFjamxNYURGWFUwTlNUVVJQVFZkTlExTmFZMVpCUkdVNGJHRTVUaXRVVGtabWFWWkxUbVpoZWtKbU1rNURLMjh6QUFBTWNtVnNjSGhYTDFWRFowRTlBQU5oZHpFQUFBRjhnMklDRkFBU2RRQUFBQSIsImV4cCI6MTY0MjA2NzgxMCwiaWF0IjoxNjM0MjkxODEwLCJhaWQiOiJBUUlheUNVd1RqS3BEVDdnVDFyLXV3IiwiY2lkIjoiIn0.tLFdmFHHO6KXbu193hTh6rHPz4MA5Oq8wjJk7eS6-4s Host link]. The other attendees will connect to Cvent and click on the join session button (FYI here is the [https://zoom.us/j/94632797975?pwd=anRlQ2ovNXhpVGhBL25vdmNkQWd5UT09 attendee URL])<br> [https://www.w3.org/events/meetings/916336d3-0c47-46b8-9f03-3ecfe991749d WebApps Roundtable - 26 October 2021, 21:00 - 23:00 UTC] Zoom set up on Cvent: the host needs to use this [https://zoom.us/s/98953364903?zak=eyJ0eXAiOiJKV1QiLCJzdiI6IjAwMDAwMSIsInptX3NrbSI6InptX28ybSIsImFsZyI6IkhTMjU2In0.eyJhdWQiOiJjbGllbnRzbSIsInVpZCI6IktKcnFoYnByU1MtY2duay1qOEdXMkEiLCJpc3MiOiJ3ZWIiLCJzdHkiOjk5LCJ3Y2QiOiJhdzEiLCJjbHQiOjAsIm1udW0iOiI5ODk1MzM2NDkwMyIsInN0ayI6IkowdGF0STZJeEdQRGtvVnozNkRyT1liTGlkM0xGaHlmSm9sTzZnVC0waDAuQmdaZ2JWQkJPSEJvTUhsbkwwNTBlVWhSUkVoR1drVlZTbVZsTVhOeFRteFpRV2t3TmxONGNXNVVTV2wyVjJ3NFFsUklhelIzV1VwSFUwTlNUVVJQVFZkTlExTmFZMVpCUkdVNGJHRTVUaXRVVGtabWFWWkxUbVpoZWtKbU1rNURLMjh6QUFBTWNtVnNjSGhYTDFWRFowRTlBQU5oZHpFQUFBRjhnekZqdEFBU2RRQUFBQSIsImV4cCI6MTY0MjA2NDYyNCwiaWF0IjoxNjM0Mjg4NjI0LCJhaWQiOiJBUUlheUNVd1RqS3BEVDdnVDFyLXV3IiwiY2lkIjoiIn0.Q6QF-IRfJE593DVubFlycSNfK6ZNXJnSueq0wPsK9zQ Host link]. The other attendees will connect to Cvent and click on the join session button (FYI here is the [https://zoom.us/j/98953364903?pwd=bGhGdVoveEo5ZHZDQ2hYbFREYVNVQT09 attendee URL]) || '''OPTION 1 CONFIRMED''' 25 and 26 OCT. 21:00-23:00UTC<br />
|-<br />
| Angel Li, Yongjing Zhang, Ming Zu || MiniApps WG || [https://www.timeanddate.com/worldclock/converter.html?iso=20211028T120000&p1=33&p2=43&p3=224&p4=248&p5=195&p6=1440 Oct 28, 12:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211028T120000&p1=33&p2=43&p3=224&p4=248&p5=195&p6=1440 Oct 28, 14:00 UTC] || || MiniApps CG might join one hour as well || [https://github.com/w3c/miniapp/issues/172 agenda] || [https://www.w3.org/events/meetings/fff7abb3-54ed-4631-b5e6-df9ff47bb980 calendar info] || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/converter.html?iso=20211028T120000&p1=33&p2=43&p3=224&p4=248&p5=195&p6=1440 Oct 28, 12:00 UTC] to [https://www.timeanddate.com/worldclock/converter.html?iso=20211028T120000&p1=33&p2=43&p3=224&p4=248&p5=195&p6=1440 Oct 28, 14:00 UTC]<br />
|-<br />
| Addison Phillips || Internationalization (I18N) WG || [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T140000&p1=33&p2=43&p3=224&p4=248&p5=195&p6=1440&p7=136&p8=37 26 October 2021 14:00 UTC] || || || [https://www.w3.org/wiki/I18N_2021_TPAC agenda] || [https://www.w3.org/2017/09/i18n-meeting-info.html Zoom &amp; IRC info (member only)] || '''OPTION 1 Confirmed''' [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T140000&p1=33&p2=43&p3=224&p4=248&p5=195&p6=1440&p7=136&p8=37 26 October 2021 14:00 UTC]<br />
|-<br />
| Travis Leithead & Johannes Wilm || Web Editing WG || [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T140000&p1=33&p2=43&p3=224&p4=248&p5=195&p6=1440&p7=136&p8=37 29 October 2021 16:00 UTC] || || WebApps || TBD || || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/converter.html?iso=20211026T140000&p1=33&p2=43&p3=224&p4=248&p5=195&p6=1440&p7=136&p8=37 29 October 2021 16:00 UTC]<br />
|-<br />
| Anssi Kostiainen & Reilly Grant || Devices and Sensors WG || [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20211027T05 27-29 October 2021] each day 5:00-7:00 UTC || || WebML, Second Screen || [https://github.com/w3c/devicesensors-wg/issues/47 agenda] || [https://www.w3.org/events/meetings/c1d1adc0-7093-4dac-97a2-a37c4526fb08 calendar info - day 1/3]<br>[https://www.w3.org/events/meetings/c8a10439-616e-4784-b41a-0440acf4bccb calendar info - day 2/3]<br>[https://www.w3.org/events/meetings/1577c6af-a098-48bc-89d4-2618ddde3ebc calendar info - day 3/3] || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20211027T05 27-29 October 2021] each day 5:00-7:00 UTC <br />
|-<br />
| Anssi Kostiainen || Web Machine Learning WG || [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20211026T14 26-28 October 2021] each day 14:00-15:00 UTC || || DAS, Second Screen || [https://github.com/webmachinelearning/meetings/issues/18 agenda] || [https://www.w3.org/events/meetings/cfb1bec6-948f-4651-802e-f4a10c1c7ab2 calendar info - day 1/3] [https://www.w3.org/events/meetings/e70e2b4c-9313-45ec-a16e-be9746a49b80 calendar info - day 2/3] [https://www.w3.org/events/meetings/9fdaa3af-5858-46c8-8ecf-05384a15636e calendar info - day 3/3] || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20211026T14 26-28 October 2021] each day 14:00-15:00 UTC <br />
|-<br />
| Anssi Kostiainen & Louay Bassbouss || Second Screen WG || [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20211025T14 25 October 2021 14:00-15:00 UTC] and [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20211026T05 26 Oct 2021 5:00-6:00 UTC] || || DAS, WebML || [https://github.com/w3c/secondscreen-wg/issues/3 agenda] || [https://www.w3.org/events/meetings/cbb60781-e18b-4fd9-b6bf-464df6b6ad03 calendar info - day 1/2]<br>[https://www.w3.org/events/meetings/b2d24686-103a-4eb9-8499-b3a35a4771a7 calendar info - day 2/2] || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20211025T14 25 October 2021 14:00-15:00 UTC] and [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20211026T05 26 Oct 2021 5:00-6:00 UTC] <br />
|-<br />
| Brent Zundel, Dan Burnett || DID WG || 28 October [https://www.timeanddate.com/worldclock/fixedtime.html?msg=DID+WG+at+TPAC+Day+1&iso=20211028T11&p1=43&ah=2 15:00 UTC to 17:00 UTC] || || EPUB 3 WG || [https://www.w3.org/events/meetings/7a3923ee-8744-47d3-9802-a6a85e2fa50b#agenda Agenda] || [https://lists.w3.org/Archives/Member/member-did-wg/2020Jun/0000.html see dial information] || '''OPTION 1 CONFIRMED''' 28 October [https://www.timeanddate.com/worldclock/fixedtime.html?msg=DID+WG+at+TPAC+Day+1&iso=20211028T11&p1=43&ah=2 15:00 UTC to 17:00 UTC]<br />
|-<br />
| Nic Jansma, Yoav Weiss || WebPerf || [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20211025T15 25-29 October 2021 8-11am Pacific], every day''' || || || [https://docs.google.com/document/d/1GQpM8IvL4feXQ0oQdCQIPKhZZkMLNTYJQhBUntMxPkI/edit#heading=h.odc700in1ypg agenda] || [https://meet.google.com/ayk-ipmq-kjv meeting link] || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20211025T15 25-29 October 2021 8-11am Pacific], every day''' <br />
|-<br />
| Tatsuya Igarashi & Chris Lorenzo & Chris Needham || Media & Entertainment IG || [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20211025T14 25 Oct 2021 14:00-16:00 UTC] and [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20211027T05 27 Oct 2021 5:00-6:00 UTC] || || Media WG, Web Transport WG || [https://www.w3.org/events/meetings/5a432437-7170-4e79-9090-1e92836d5134 Agenda (Meeting 1)]<br>[https://www.w3.org/events/meetings/e8d07212-25b8-4f4c-8d38-943ed0a6130f Agenda (Meeting 2)] || [https://www.w3.org/events/meetings/5a432437-7170-4e79-9090-1e92836d5134 Calendar Info (Meeting 1)]<br>[https://www.w3.org/events/meetings/e8d07212-25b8-4f4c-8d38-943ed0a6130f Calendar Info (Meeting 2)] || '''OPTION 1 CONFIRMED [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20211025T14 25 Oct 2021 14:00-16:00 UTC] and [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20211027T05 27 Oct 2021 5:00-6:00 UTC]<br />
|-<br />
| Wendy Seltzer || Improving Web Advertising BG || 27 Oct 23:00-0:00UTC and 28 Oct 15:00-16:00UTC || OPTION 2: Date and times in [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20201001T140000 UTC] 2 times, one Asia/Pacific-friendly || || TBD || TBD || '''OPTION 1 CONFIRMED''' 27 Oct 23:00-0:00UTC and 28 Oct 15:00-16:00UTC<br />
|-<br />
| Sudeep Divakaran, Song Xu, Dan Druta || Web & Networks IG || October 28 2pm-3pm UTC || October 28 3pm-4pm UTC || || [https://www.w3.org/wiki/Networks/TPAC2021#Meeting_:_Web_.26_Networks_IG_Meeting Agenda] || Webex defined in [https://www.w3.org/events/meetings/c98bdb94-1917-4035-a677-d1cb3a5419c3 WNIG group calendar] || '''OPTION 1 CONFIRMED''' October 28 2pm-3pm UTC<br />
|-<br />
| Hongchan Choi, Matthew Paradis || Audio WG || October 25,27,28 3pm-5pm UTC, October 26 4pm-5pm UTC || || WebRTC, Media || [https://docs.google.com/document/d/1V3vhlOa5DQVHI3azwk3V3pBfq_R2ZUuwLVSkO3xCbH4/edit?usp=sharing Agenda] || https://meet.google.com/oxy-ouyf-ith || '''OPTION 1 CONFIRMED''' October 25,27,28 3pm-5pm UTC, October 26 4pm-5pm UTC Note that WebRTC will conflict from 15:00 to 16:00 on 28 October<br />
|-<br />
| James Nurthen || ARIA ||[https://www.timeanddate.com/worldclock/meetingdetails.html?year=2021&month=10&day=28&hour=14&min=0&sec=0&p1=224&p2=179&p3=248 Oct 28, 14:00-15:00 UTC] || || CSS, APA, I18N, EPUB || https://github.com/w3c/aria/issues/1619 , https://github.com/w3c/aria/issues/1620 || [https://www.w3.org/events/meetings/1d106c10-842d-44d2-a43f-bccfa7841b62 ARIA Calendar] || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/meetingdetails.html?year=2021&month=10&day=28&hour=14&min=0&sec=0&p1=224&p2=179&p3=248 Oct 28, 14:00-15:00 UTC]<br />
|-<br />
| James Nurthen || ARIA ||[https://www.timeanddate.com/worldclock/meetingdetails.html?year=2021&month=10&day=28&hour=16&min=0&sec=0&p1=224&p2=179&p3=248 Oct 28, 16:00-18:00 UTC] || || || Discuss issues surrounding ARIA representation in IDL including Nullable Strings (https://github.com/w3c/aria/issues/1598, https://github.com/w3c/aria/issues/1058) and Element References (https://github.com/w3c/aria/issues/1596) || [https://www.w3.org/events/meetings/e8be2735-d90b-4619-a25c-d25c0abdd965 ARIA Calendar] || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/meetingdetails.html?year=2021&month=10&day=28&hour=16&min=0&sec=0&p1=224&p2=179&p3=248 Oct 28, 16:00-18:00 UTC]<br />
|-<br />
| Tzviya Siegman, Ralph Swick || Publishing BG, Publishing CG, EPUB WG ||[https://www.timeanddate.com/worldclock/meetingdetails.html?year=2021&month=10&day=28&hour=13&min=0&sec=0&p1=224&p2=179&p3=248 Oct 27, 13:00-14:30 UTC] || || EPUB WG || Discuss plans on the work on Digital Publishing beyond EPUB || [https://www.w3.org/events/meetings/447c6288-6cb9-4134-86c0-b419edd0cea3 calendar info] || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/meetingdetails.html?year=2021&month=10&day=28&hour=13&min=0&sec=0&p1=224&p2=179&p3=248 Oct 27, 13:00-14:30 UTC]<br />
|-<br />
| Caroline Burle, Peter Winstanley || Dataset Exchange Working Group ||[https://www.timeanddate.com/worldclock/meetingdetails.html?year=2021&month=10&day=26&hour=20&min=0&sec=0&p1=43&p2=195&p3=224&p4=33&p5=248&p6=136&p7=64&p8=216&p9=152 Oct 26, 22:00-23:00 UTC] || || || Discuss the next steps for the Working Group || [https://www.w3.org/events/meetings/7c0849e5-1088-455e-8ee5-1a5c942af363/20211019T220000 DX Calendar] || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/meetingdetails.html?year=2021&month=10&day=26&hour=20&min=0&sec=0&p1=43&p2=195&p3=224&p4=33&p5=248&p6=136&p7=64&p8=216&p9=152 Oct 26, 22:00-23:00 UTC]<br />
|-<br />
|}<br />
<br />
== CG Group Meetings details ==<br />
<br />
Community Groups will be able to meet. <br />
CGs Chairs who can not edit this page should contact [mailto:w3t-tpregister@w3.org Events Team] stating their username . Access will be given.<br />
<br />
{| class="wikitable"<br />
|-<br />
! '''Chair name''' !! '''Group name''' !! '''OPTION 1: Date and times in [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20201001T140000 UTC]''' !! '''OPTION 2: Date and times in [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20201001T140000 UTC]''' !! '''With which groups there should be no overlap''' !! '''Link to agenda''' See "Group meetings attendance section|| '''Link to Meeting coordinates (service, code, password)''' See "Group meetings attendance section|| CONFIRMED date and times by W3C<br />
|-<br />
| Giulia Marangoni, Laurent Le Meur || TDM Reservation Protocol || Oct 26, 15:00 UTC to 16:00 UTC || Oct 28, 15:00 UTC to 16:00 UTC || - || [https://www.w3.org/community/tdmrep/2021/10/19/community-group-meeting-at-w3c-tpac-2021/ Agenda] || [https://us06web.zoom.us/j/88082313676?pwd=R0taL0grTWUxK3hrMlJUWFRYdkRNdz09 Zoom] || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/fixedtime.html?msg=TDM+Res+Protocol&iso=20211026T15&p1=1440&ah=1 Oct 26, 15:00 UTC to 16:00 UTC]<br />
|-<br />
| Michael Good, Adrian Holovaty, Daniel Spreadbury || Music Notation || Oct 28, 14:00 UTC to 16:00 UTC || Oct 27, 14:00 UTC to 16:00 UTC || Audio WG, Synchronized Multimedia for Publications CG || [https://www.w3.org/community/music-notation/2021/09/28/co-chair-meeting-september-28-2021/ Agenda] ||[https://peaksware.zoom.us/j/98085343649?pwd=QTIwK2hscmJ0OXVielBORXZjOE51Zz09 Zoom] || '''OPTION 1 CONFIRMED''' Oct 28, 14:00 UTC to 16:00 UTC<br />
|-<br />
| Deborah Dahl, Dirk Schnelle-Walka, Brian Susko, Marco Kerwitz|| Voice Interaction Community Group || Oct 27, 15:00 UTC to 16:00 UTC || ⌠||âŚ|| [https://lists.w3.org/Archives/Public/public-voiceinteraction/2021Oct/0012.html Agenda]||[https://mit.zoom.us/j/96653575919?pwd=eFgrUE5WYlJyU2RDc2dic05YK0tkUT09 Zoom] || '''OPTION 1 CONFIRMED''' Oct 27, 15:00 UTC to 16:00 UTC<br />
|-<br />
| Bev Corwin, Noreen Whysel, Shari Thurow || Information Architecture Community Group || [https://www.timeanddate.com/worldclock/converter.html?iso=20211028T150000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240&p8=1440 Oct 27, 13:00 UTC to 14:00 UTC] || ⌠|| ⌠|| ⌠|| Zoom [https://us02web.zoom.us/j/82459868901?pwd=ZnpDMUZlTElURDBrbFZUVTF3Mkp4Zz09 Zoom] || '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/converter.html?iso=20211028T150000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240&p8=1440 Oct 27, 13:00 UTC to 14:00 UTC]<br />
|-<br />
| Tom Greenaway, NoÍl Meudec || Games Community Group || Oct 26, 14:00 UTC to 15:00 UTC || Oct 27, 14:00 UTC to 15:00 UTC || ⌠|| [https://www.w3.org/events/meetings/dcf599f4-549c-4a8a-81a5-6437429bac3c Agenda] || [https://mit.zoom.us/j/91631568635 Zoom info] || '''OPTION 1 CONFIRMED''' Oct 26, 14:00 UTC to 15:00 UTC<br />
|-<br />
| Heather Vescent, Mike Prorock, Wayne Chang || Credentials Community Group || 26 Oct 16:00 UTC to 17:00 UTC (9am PDT, 12pm EDT, 5pm BST, 6pm CEST / 6AM+1 NZDT) || ⌠|| ⌠|| ⌠|| https://w3c-ccg.github.io/ || '''OPTION 1 CONFIRMED''' 26 Oct 16:00 UTC to 17:00 UTC (9am PDT, 12pm EDT, 5pm BST, 6pm CEST / 6AM+1 NZDT)<br />
|-<br />
| Jake Holland || Multicast Community Group || 27 Oct 15:00 UTC to 16:00 UTC (8am PDT, 11am EDT) || ... || webrtc, web-network, media-and-entertainment, webtransport || [https://github.com/w3c/multicast-cg/blob/main/meetings/minutes/tpac-2021-agenda.md Agenda] || https://akamai.webex.com/akamai/j.php?MTID=m82facd432d2daa720ebbb302d17e256c <br/>pw=yay-multicast!, #2598 001 6648 || '''OPTION 1 CONFIRMED''' 27 Oct 15:00 UTC to 16:00 UTC (8am PDT, 11am EDT)<br />
|-<br />
| Timothy Hatcher, Simeon Vincent || WebExtensions Community Group || [https://www.timeanddate.com/worldclock/converter.html?iso=20211028T150000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240&p8=1440 Oct 28 2021, 15:00 UTC to 16:00 UTC] || ⌠|| Service Workers, WebDriver BiDi || ⌠|| ⌠|| '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/converter.html?iso=20211028T150000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136&p7=240&p8=1440 Oct 28 2021, 15:00 UTC to 16:00 UTC] <br />
|-<br />
| Peter Rushforth || Web Maps Community Group || [https://www.timeanddate.com/worldclock/converter.html?iso=20211029T170000&p1=1440&p2=188&p3=43&p4=195&p5=136&p6=239&p7=137# Oct 29 2021, 17:00 UTC to 18:00 UTC] || ⌠|| SVG *G, Devices and Sensors, AR/XR || [https://www.w3.org/community/maps4html/wiki/TPAC_2021_Agenda Agenda] || ⌠|| '''OPTION 1 CONFIRMED''' [https://www.timeanddate.com/worldclock/converter.html?iso=20211029T170000&p1=1440&p2=188&p3=43&p4=195&p5=136&p6=239&p7=137# Oct 29 2021, 17:00 UTC to 18:00 UTC]<br />
|-<br />
| Sarven Capadisli || Solid Community Group || 27 Oct 14:00 UTC to 16:00 UTC || 27 Oct 14:30 UTC to 16:30 UTC || ⌠|| [https://github.com/solid/specification/pull/327 Agenda] || https://meet.jit.si/solid-specification || '''OPTION 1 CONFIRMED''' 27 Oct 14:30 UTC to 16:30 UTC<br />
|-<br />
| Paola Di Maio|| AI KR CG || Oct 25 2021, 12:00 UTC to 14:00 UTC || ⌠|| || <br />
[https://www.w3.org/community/aikr/wiki/AI_KR_CG_@TPAC_2021 Agenda]<br />
|| Zoom set up on Cvent: the host needs to use this [https://zoom.us/s/99055638533?zak=eyJ0eXAiOiJKV1QiLCJzdiI6IjAwMDAwMSIsInptX3NrbSI6InptX28ybSIsImFsZyI6IkhTMjU2In0.eyJhdWQiOiJjbGllbnRzbSIsInVpZCI6IjR1S0t5XzY0VGFDZGw4Q3Vvb2FpelEiLCJpc3MiOiJ3ZWIiLCJzdHkiOjk5LCJ3Y2QiOiJhdzEiLCJjbHQiOjAsIm1udW0iOiI5OTA1NTYzODUzMyIsInN0ayI6IldUc0VycWlTNzVWMEpudFR0SVloOUFTb1JzNDdvVVhIbGFnbEUzSDJEWkEuQmdaZ05sUlBMMHh2ZFUxRVRscGpXbGxaV2xKa1pVUnJWV1ZwWmxKR1lYbzRaR3h5T0hwc1FXNVBiek4zUWpVelJucFJkbWRMVlV0SFUwTlNUVVJQVFZkTlExTmFZMVpCUkdVNGJHRTVUaXRVVGtabWFWWkxUbVpoZWtKbU1rNURLMjh6QUFBTWNtVnNjSGhYTDFWRFowRTlBQU5oZHpFQUFBRjhsalFOREFBU2RRQUFBQSIsImV4cCI6MTY0MjM4MzU2NiwiaWF0IjoxNjM0NjA3NTY2LCJhaWQiOiJBUUlheUNVd1RqS3BEVDdnVDFyLXV3IiwiY2lkIjoiIn0.b3ZowvSuBCXjt5bv-KA0amxJYDvmwoYdBRYhUpi3fWU Host link]. The other attendees will connect to Cvent and click on the join session button (FYI here is the [https://zoom.us/j/99055638533?pwd=TUxwcTMrUktKM3QwVGpQbzR2SDZtUT09 attendee URL]) || '''OPTION 1 CONFIRMED''' Oct 25 2021, 12:00 UTC to 14:00 UTC<br />
|-<br />
| Christopher Patnoe|| Immersive Captions || 26 Oct 2021, 14:00 UTC to 17:00 UTC || 27 Oct 2021, 14:00 UTC to 17:00 UTC || || [https://www.w3.org/community/immersive-captions/2021/10/18/community-group-meeting-at-w3c-tpac-2021/ Agenda] || Zoom set up on Cvent: the host needs to use this [https://zoom.us/s/98047409225?zak=eyJ0eXAiOiJKV1QiLCJzdiI6IjAwMDAwMSIsInptX3NrbSI6InptX28ybSIsImFsZyI6IkhTMjU2In0.eyJhdWQiOiJjbGllbnRzbSIsInVpZCI6Ik5lWGNxQTBEUjBhZXNod25JZWppOEEiLCJpc3MiOiJ3ZWIiLCJzdHkiOjk5LCJ3Y2QiOiJhdzEiLCJjbHQiOjAsIm1udW0iOiI5ODA0NzQwOTIyNSIsInN0ayI6IkgwVWlxalp3NnRLa2o3WXhValRfaGVsSkdkRkgxMkM1MGZ1Y1dtaVpYQWcuQmdaZ2EwRm9iaTl1Ykc1cmVrdEVXa3B3YTFwYWNHZHBVRTltZUZRd1QyOWxjblZaVGxaWFNWcDJTRmh3SzJzM1ZIRktZa3hKUVcweVUwTlNUVVJQVFZkTlExTmFZMVpCUkdVNGJHRTVUaXRVVGtabWFWWkxUbVpoZWtKbU1rNURLMjh6QUFBTWNtVnNjSGhYTDFWRFowRTlBQU5oZHpFQUFBRjhrUEV3ZUFBU2RRQUFBQSIsImV4cCI6MTY0MjI5NTI5OCwiaWF0IjoxNjM0NTE5Mjk4LCJhaWQiOiJBUUlheUNVd1RqS3BEVDdnVDFyLXV3IiwiY2lkIjoiIn0.FEg8yWXf4lBoc1Mce_KfeTuMOZB0q6nUAs2ciYm1zkE Host link]. The other attendees will connect to Cvent and click on the join session button (FYI here is the [https://zoom.us/j/98047409225?pwd=Ly93ZXdScVRzM0ZQOW14S2piTzZEUT09 attendee URL]) ||'''OPTION 1 CONFIRMED''' Oct 26 2021, 15:00 UTC to 16:30 UTC<br />
|-<br />
| Aram Zucker-Scharff, Sean Turner|| PATCG || 29 Oct 2021, 16:00 UTC - 17:00 UTC || || || Initial meeting of Private Advertising Technology CG || || '''OPTION 1 CONFIRMED''' Oct 29 2021, 16:00 UTC to 17:00 UTC<br />
|}<br />
<br />
== Group Meetings attendance: '''Connecting to your meeting''' ==<br />
See [https://docs.google.com/document/d/19p6cA_TdMZ8yVQ_qBQITjfbLgeJ9KD3LK-LdlaR2ieA/edit?usp=sharing separate document]<br />
<br />
== Contacts ==<br />
If you need any assistance with planning your meeting, the [mailto:w3t-tpregister@w3.org Events Team] is here to help you.</div>Plehegarhttps://www.w3.org/wiki/index.php?title=TPAC/2021/SessionIdeas&diff=114032TPAC/2021/SessionIdeas2021-10-07T12:39:59Z<p>Plehegar: /* Navigating W3C Process Tracks: Living Specifications, Registries, Notes and Statements */</p>
<hr />
<div>You are invited to propose [https://www.w3.org/2021/10/TPAC/ TPAC 2021] '''TPAC Breakout week (October 18-22)''' sessions in advance of the meeting, and '''before October 8 EOB''' if you want to benefit from optimal scheduling. <br />
See the [[TPAC/2021/FAQ | TPAC 2021 FAQ]] for more information. Please contact dom@w3.org for any question regarding the organization of TPAC breakouts.<br />
<br />
<div style="float:right;clear:right">__TOC__</div><br />
<br />
== How to use this page ==<br />
<br />
Please use this page to:<br />
<br />
* Propose sessions you wish to lead<br />
* '''Please place new proposals at the bottom of this document'''<br />
<br />
Any TPAC participant (participant in a Working Group, Interest Group, Business Group, or participant in a Community Group meeting at TPAC) may propose a session. We encourage you to bring new presenters to the community, particularly to help us improve the inclusiveness and diversity of W3C, listing yourself as the proposer. Please limit yourself to one or at most two proposals per proposer. <br />
<br />
The W3C planning team will review all proposed breakouts and may suggest refining, combining, or deferring some proposals. <br />
<br />
== Scheduling breakouts for broad community participation ==<br />
Breakouts are scheduled the week of October 18-22. The exact time and date of each breakout will be determined by the staff to reduce overlap of sessions with similar expected participants. We expect that scheduling to happen on October 8 - proposals submitted after October 8 will have much less flexibility in how they get scheduled.<br />
<br />
With the W3C community spread across the globe, we are suggesting two approaches to breakout facilitators:<br />
* run their sessions twice to make it possible for people from as many timezones as possible to attend sessions they care about. We suggest picking 2 among the following of times:<br />
** 12am UTC: 5pm US PT / 8pm US ET / 8am Beijing / 9am Tokyo / 11am Sydney<br />
** 7am UTC: 8am UK / 9am CET / 11am Dubai / 3pm Beijing / 4pm Tokyo / 6pm Sydney<br />
** 3pm UTC: 8am US PT / 11am US ET / 4pm UK / 5pm CET / 7pm Dubai<br />
* run it a single time at 2pm UTC (7am US PT / 10am US ET / 3pm UK / 4pm CET / 6pm Dubai / 10pm Beijing / 11pm Tokyo / 1am Sydney). Single instance TPAC breakout sessions proposed outside of the 2pm UTC slot are subject to validation.<br />
<br />
== How to propose a session ==<br />
<br />
Please provide:<br />
<ul class="show_items"><br />
* session name (as a === subhead === )<br />
* session facilitators and speakers<br />
* one sentence session summary<br />
* type of session: (e.g.: open discussion, talk, panel, tutorial, demo, etc.)<br />
* goals of session - what outcomes can session participants expect?<br />
* additional speakers/panelists (to help reduce conflicts when one person is needed in more than one place)<br />
* is this breakout only for TPAC participants or should it be open to anyone?<br />
* a shortname that can be used to associate an IRC channel to your breakout<br />
* time preference: (2 slots among the ones listed above, 1 slot 2pm UTC, or request an exception)<br />
* days: if your breakout can only be scheduled on a subset of the 5 days of the week, please also indicate it<br />
</ul><br />
<br />
== Breakout facilitator training ==<br />
<br />
To help make the experience of TPAC breakouts as inclusive and welcoming as possible, W3C is offering a program to support facilitators in preparing and running their sessions.<br />
<br />
We will be running two training sessions the week of October 4th <br />
* a 90 minutes workshop on Inclusive Facilitation Training, run by Kay Martinez, scheduled on October 5, 2021 at 2pm UTC<br />
** The session will be an update of the [https://www.w3.org/2020/10/TPAC/facilitator-training.html training run last year]<br />
* a workshop on conflict management, run by Jory Burson (exact time and date to be confirmed)<br />
<br />
These training sessions are open to anyone planning to run a breakout session, and more generally to anyone wanting to build their skills in W3C meeting facilitation, with the first workshop limited to 30 participants - please indicate your interest in attending it with dom@w3.org.<br />
<br />
In addition to these training sessions open to anyone, we are inviting breakout facilitators to volunteer for a more in-depth program, which will add the opportunity to get paired with a buddy and participate in a debriefing session after TPAC to keep better track of what did and did not work as well in terms of applying the training in practice. For scalability reasons, we only expect to accept about 10 people in this program, and ask that the said volunteers commit to participate to all of the sessions scheduled as part of this training program - please get in touch with dom@w3.org if you are interested.<br />
<br />
== Proposed sessions ==<br />
<br />
=== EXAMPLE session with session name ===<br />
* Proposer: <nowiki>~~~~</nowiki> (Instruction: remove <nowiki><nowiki> and </nowiki></nowiki> around the tildes (~). Explanation: The 4 tildes will sign YOUR name and include a timestamp of your proposal.)<br />
* Email address of proposer: <br />
* Summary (one-sentence or so): <br />
* Type of session (e.g.: open discussion, talk, panel, etc.): <br />
* Goals:<br />
* shortname (used for minting an IRC channel for the breakout)<br />
* [optional] Additional speakers/panelists:<br />
* limited to TPAC participants or open to the public?<br />
* [optional] Timeslot: two slots among 12am UTC, 7am UTC, 3pm UTC, one slot at 2pm UTC, or exception request<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Wednesday, Thursday, Friday<br />
<br />
=== State of CSS 2021 ===<br />
* Proposer: [[User:Foolip|Philip Jägenstedt]] ([[User talk:Foolip|talk]]) 14:57, 7 September 2021 (UTC)<br />
* Email address of proposer: foolip@google.com<br />
* Summary (one-sentence or so): State of CSS 2021: what do the results say?<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): discussion<br />
* Goals: Get insights from the State of CSS 2021 results and if possible prioritize spec and implementation work to address top wants or pain points.<br />
* shortname (used for minting an IRC channel for the breakout): stateofcss<br />
* [optional] Additional speakers/panelists:<br />
* Open to the public<br />
* [optional] Timeslot: one slot at 7am UTC, 2pm UTC, or 3pm UTC any day except Wednesday<br />
<br />
=== The state of browser storage partitioning ===<br />
* Proposer: [[User:Miketaylr|Michael Taylor]] ([[User talk:Miketaylr|talk]]) 20:27, 7 September 2021 (UTC)<br />
* Email address of proposer: miketaylr@google.com<br />
* Summary (one-sentence or so): What is the current state of storage partitioning efforts in browsers today?<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): discussion<br />
* Goals: Understand the progress of partitioning efforts and discover opportunities to align approaches. <br />
* shortname (used for minting an IRC channel for the breakout): partitioning<br />
* [optional] Additional speakers/panelists: Any browser reps or contributors are welcome to join the discussion<br />
* limited to TPAC participants or open to the public? Open to public<br />
* [optional] Timeslot: one slot at 3pm UTC<br />
* [optional] Preferably Thursday or Friday<br />
<br />
=== Project Fugu đĄ: Almost Three Years In⌠===<br />
* Proposer: [[User:Tsteiner|Thomas Steiner]] ([[User talk:Tsteiner|talk]]) 12:09, 8 September 2021 (UTC)<br />
* Email address of proposer: tomac@google.com<br />
* Summary (one-sentence or so): It's been almost three years that the [https://web.dev/fugu-status/ Project Fugu] effort was started. This is a good occasion to look back at what we have achieved and where we fell short of our objectives, but then also to look forward to what's still ahead of us.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Open discussion.<br />
* Goals: Reflect back and look forward.<br />
* shortname (used for minting an IRC channel for the breakout): project-fugu<br />
* [optional] Additional speakers/panelists: Edit this Wiki and add you!<br />
* limited to TPAC participants or open to the public? Open to the public.<br />
* [optional] Timeslot: One slot at 3pm UTC.<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Wednesday, Thursday.<br />
<br />
=== Voice Agent Interoperability ===<br />
* Proposer: Deborah Dahl [[User:Ddahl2|Deborah Dahl]] ([[User talk:Ddahl2|talk]]) 21:16, 8 September 2021 (UTC) <br />
* Email address of proposer: dahl@conversational-technologies.com<br />
* Summary (one-sentence or so): We now have silos of thousands of voice agents that only work with one platform. Enterprises have to develop multiple versions of their customer service applications and users may need multiple platforms to access all the voice agents they want to use. It would be much better if voice agents could interoperate with each other, perhaps using some standards analogous to HTML. In addition, discovery of voice agents with specific capabilities is currently haphazard and difficult. How can discovery be made easier? Is there an analogy to search engines and domain names? With these capabilities, the voice agent world would be much more like the web. This session will discuss issues related to interoperability of voice agents.<br />
* Type of session: open discussion<br />
* Goals: Raise issues of voice agent interoperability, including potential standards and barriers.<br />
* shortname (used for minting an IRC channel for the breakout):voiceagents<br />
* [optional] Additional speakers/panelists:<br />
* limited to TPAC participants or open to the public?: open to the public<br />
* [optional] Timeslot: two slots among 12am UTC, 3pm UTC or one slot at 2pm UTC<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Wednesday, Thursday, Friday<br />
<br />
=== WebID ===<br />
<span style="color:#f00"><br />
This event name and details is in conflict with an existing name under W3C e.g., WebID CG: https://www.w3.org/community/webid/ .<br />
This is a well-known issue: https://github.com/WICG/WebID/issues/41 with consensus that renaming will take place. - [[User:Scapadis|Sarven Capadisli]] ([[User talk:Scapadis|talk]]) 08:50, 5 October 2021 (UTC)<br />
</span><br />
<br />
* Proposer: [[User:Cbiesing|Christian Biesinger]] ([[User talk:Cbiesing|talk]]) 17:48, 9 September 2021 (UTC)<br />
* Email address of proposer: cbiesinger@google.com<br />
* Summary (one-sentence or so): Discuss the state of the WebID spec<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): open discussion<br />
* Goals: Discuss the current state of ongoing WebID initiatives, which will help to have more privacy-preserving federated sign-in experiences.<br />
* shortname (used for minting an IRC channel for the breakout): webid<br />
* [optional] Additional speakers/panelists: Kaan Icer<br />
* limited to TPAC participants or open to the public? open<br />
* [optional] Timeslot: two slots among 12am UTC, 7am UTC, 3pm UTC, one slot at 2pm UTC, or exception request<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Wednesday, Thursday, Friday<br />
<br />
=== Framework for the Accessible Specification of Technologies ===<br />
* Proposer: [[User:Joconnor|Joshue O&#39;Connor]] ([[User talk:Joconnor|talk]]) 12:14, 13 September 2021 (UTC)<br />
* Email address of proposer: joconnor@w3.org<br />
* Summary (one-sentence or so): Overview of progress to date and work on [https://w3c.github.io/apa/fast/ FAST user needs and gap analysis methodology].<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Presentationa and open discussion.<br />
* Goals: Presentation and discussion of FAST work, how it relates to horizontal accessibility spec review as well as the development of our methodology for technique gap analysis in Silver.<br />
* shortname (used for minting an IRC channel for the breakout): fast<br />
* [optional] Additional speakers/panelists: Michael Cooper, Jake Abma, Jeanne Spellman.<br />
* limited to TPAC participants or open to the public?: TPAC participants<br />
* [optional] Timeslot: one slot at 2pm UTC<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Weds, Thurs<br />
<br />
<br />
=== Auto Accessibility breakout ===<br />
* Proposer: [[User:ted|Ted Guild]] ([[User talk:ted|talk]]) 12:14, 13 September 2021 (UTC)<br />
* Email address of proposer: tedguild@geotab.com<br />
* Summary (one-sentence or so): Determine scope of work for Accessibility in W3C Automotive either for technical specifications or in best practices document.<br />
<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): talk<br />
* Goals: The W3C Automotive activity is producing standards around telematics data and services for connected vehicles. While not directly defining user interfaces, there are opportunities to influence this industry at a formative stage for better accessibility inclusion in its technical architecture. Together with WAI Accessibility Platform Architecture (APA) Research Questions Task Force, we want to explain current work, as well as explore and prioritize potential work.<br />
* shortname (used for minting an IRC channel for the breakout): autoa11y<br />
* [optional] Additional speakers/panelists:<br />
* limited to TPAC participants or open to the public?: tpac<br />
* [optional] Timeslot: one slot at 2pm UTC<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Weds, Thurs<br />
<br />
=== COGA Content Usable: user needs to specifications ===<br />
* Proposer: [[User:Rainb|Rain Breaw Michaels]] ([[User talk:Rainb|talk]]) 13:37, 13 September 2021 (UTC) <br />
* Email address of proposer: rainb@google.com<br />
* Summary: [https://www.w3.org/TR/coga-usable/ Content Usable] gives advice on how to make content and interfaces usable for people with cognitive and learning disabilities. This breakout session will look at how this advice can translate into specifications.<br />
* Type of session: Panel followed by discussion<br />
* Goals: Enable working groups and task forces across W3C to make sure that the user needs of individuals with cognitive differences and disabilities (examples: autism, dementia, learning disabilities, and much more) are included in your user needs for your specifications so that you include the widest possible potential.<br />
* shortname (used for minting an IRC channel for the breakout): cogapanel<br />
* [optional] Additional speakers/panelists: Lisa Seeman, David Fazio, John Kirkwood, Rain Michaels<br />
* limited to TPAC participants or open to the public? tpac<br />
* [optional] Timeslot: one slot, preferred 2pm or 3pm UTC, 12am UTC will work, as well<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Wednesday, Thursday, Friday<br />
<br />
=== How to work with COGA ===<br />
* Proposer: [[User:Rainb|Rain Breaw Michaels]] ([[User talk:Rainb|talk]]) 22:04, 13 September 2021 (UTC) <br />
* Email address of proposer: rainb@google.com<br />
* Summary: Cover the types of cognitive and learning disabilities and differences that members of COGA (the Cognitive Accessibility Task Force) (and truthfully other members of W3C groups) may have, and how our collaboration processes across the W3C can better include the valuable perspectives of these individuals. <br />
* Type of session: Guided open discussion<br />
* Goals: Enable the various groups across the W3C to engage effectively with the COGA Task Force. Identify the tooling, communication styles, and processes that can support more inclusive and successful collaboration. <br />
* shortname (used for minting an IRC channel for the breakout): cogainclusion<br />
* [optional] Additional speakers/panelists: Jennie Delisi<br />
* limited to TPAC participants or open to the public? tpac<br />
* [optional] Timeslot: two slot, prefer 3pm UTC, but 12am UTC will work, as well<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Wednesday, Thursday<br />
<br />
=== Service Worker CSRF Discussion ===<br />
* Withdrawn due to scheduling conflicts this week.<br />
<br />
=== Introduction to Synchronization Accessibility User Requirements (SAUR) ===<br />
* Proposer: [[User:Bgibson|Becky Gibson]] ([[User talk:Bgibson|talk]]) 12:40, 15 September 2021 (UTC) <br />
* Email address of proposer: gibson.becky@gmail.com<br />
* Summary (one-sentence or so): Introduce Synchronization Accessibility User Requirements (SAUR) and implications on media related W3C specifications. <br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Panel and Q&A<br />
* Goals: Understand the issues surrounding synchronization in online media.<br />
* shortname (used for minting an IRC channel for the breakout): SAUR<br />
* [optional] Additional speakers/panelists: Janina Sajka, Steve Noble, Jason White, Joshue O'Connor, Scott Hollier<br />
* limited to TPAC participants or open to the public? Open to public<br />
* [optional] Timeslot: We have already confirmed availability of panelists and interested parties across the -8 to +8 UTC time zones for Wednesday, Oct 20 at 14:00 UTC so respectfully request that time slot if possible<br />
* [optional] Preferable the above already confirmed time slot to reach the wide range of time zones for the participants.<br />
<br />
=== Accessibility & CSS ===<br />
* Proposer: [[User:Bgibson|Becky Gibson]] ([[User talk:Bgibson|talk]]) 13:00, 15 September 2021 (UTC)<br />
* Email address of proposer: gibson.becky@gmail.com<br />
* Summary (one-sentence or so): Discussion of CSS and potential advances and implications for accessibility<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): open discussion<br />
* Goals: Discuss and review upcoming CSS features for where they may help and possibly hinder accessibility.<br />
* shortname (used for minting an IRC channel for the breakout): CSSA11y<br />
* [optional] Additional speakers/panelists:<br />
* limited to TPAC participants or open to the public? open to the public<br />
* [optional] Timeslot: We have already confirmed availability of CSS and APA working group participants on Wednesday, Oct 20 at 16:00 UTS so respectfully request that time slot if possible<br />
* [optional] constraints on days in which the breakout can run: Cannot run on Wed. Oct 20 at 14:00 UTC (if SAUR gets scheduled at that time) or against COGA breakouts<br />
<br />
=== Anti-Fraud for the Web ===<br />
* Proposer: [[User:svaldez|Steven Valdez]] ([[User talk:svaldez|talk]]) 21:00, 15 September 2021 (UTC) <br />
* Email address of proposer: svaldez@google.com<br />
* Summary (one-sentence or so): Discussion of current use of cross-site identification (third-party cookies, browser/device fingerprinting, etc) in various types of anti-fraud solutions on the web. <br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Short talks followed with guided open discussion <br />
* Goals: Discuss the use cases and requirements, along with potential next steps for work in the space.<br />
* shortname (used for minting an IRC channel for the breakout): antifraud<br />
* [optional] Additional speakers/panelists: <br />
* [optional] Timeslot: one slot at 2pm UTC<br />
* limited to TPAC participants or open to the public? open to the public<br />
* [https://github.com/WICG/trust-token-api/blob/main/antifrauid-breakout-agenda.md Agenda (more items/materials speakers welcome)]<br />
<br />
=== From MathML to AT ===<br />
* Proposer: [[User:Nsoiffer2|Neil Soiffer]] ([[User talk:Nsoiffer2|talk]]) 19:54, 17 September 2021 (UTC) <br />
* Email address of proposer: neil.soiffer@gmail.com<br />
* Summary (one-sentence or so): The MathML WG is collecting ideas to allow authors to clarify the meaning of mathematical expressions so that the content can be clearly conveyed to assistive technology. The WG is interested in outside ideas such as how ARIA, CSS, and/or microddata could be used for this purpose. The WG is also soliciting feedback on potential ideas the WG has discussed. This is about making math accessible within the web platform; no mathematical expertise is required.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Open discussion<br />
* Goals: To solicit ideas from various stakeholders and WGs as to what they feel is appropriate<br />
* shortname (used for minting an IRC channel for the breakout) a11y-math<br />
* [optional] Additional speakers/panelists:<br />
* limited to TPAC participants or open to the public? open to the public<br />
* [optional] Timeslot: 3pm UTC or 4pm UTC<br />
* [optional] any day (avoid conflicts with sessions that have a11y relevance)<br />
<br />
=== The State of Web Monetization ===<br />
* Proposer: [[User:uchiu|Uchi Uchibeke]] ([[User talk:uchiu|talk]]) 11:15, 22 September 2021 (UTC)<br />
* Email address of proposer: uchi@coil.com<br />
* Summary (one-sentence or so): Introduction to Web Monetization and ongoing changes to the Web Monetization spec to make it easier for wider adoption<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Open Discussion<br />
* Goals: To get feedback from stakeholders and discuss the potential path for supporting Web Monetization natively<br />
* shortname (used for minting an IRC channel for the breakout)<br />
* [optional] Additional speakers/panelists: <br />
* limited to TPAC participants or open to the public? open to the public<br />
* [optional] Timeslot: 2pm UTC or 3pm UTC<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Wednesday, Thursday, Friday<br />
<br />
<br />
=== Accessibility of Remote Meetings ===<br />
* Proposer:[[User:Shollier|Scott Hollier]] ([[User talk:Shollier|talk]]) 13:51, 22 September 2021 (UTC) Scott Hollier <br />
* Email address of proposer: scott@hollier.info <br />
* Summary (one-sentence or so): Discussion of the Accessibility of Remote meetings draft work being developed in the APA RQTF <br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Open Discussion<br />
* Goals: Discuss what's needed to ensure that remote meetings are accessible to people with disabilities, especially during this time when we have all become so reliant on remote communications. Also, discuss the applicability to other W3C work. <br />
* shortname (used for minting an IRC channel for the breakout): remotemeet<br />
* [optional] Additional speakers/panelists: Judy Brewer <br />
* limited to TPAC participants or open to the public? open to the public<br />
* [optional] Timeslot: 1pm UTC or 2pm UTC on any day. Times are based on presenter being based in +8 UTC time zone.<br />
<br />
=== Converting Tools for MiniApp ===<br />
* Proposer: Zitao Wang 9:00, 27 September 2021 (UTC)<br />
* Email address of proposer: wangzitao@huawei.com<br />
* Summary (one-sentence or so): Tools for converting standard MiniApp to vendor-specific implementations.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): discussion<br />
* Goals: Demonstrate potential solutions for converting standards to vendor implementations. Discuss the tool design and improvement solution.<br />
* shortname (used for minting an IRC channel for the breakout): MiniAppTools<br />
* [optional] Additional speakers/panelists:Open to the public<br />
* [optional] Timeslot: 9am-12am UTC<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Wednesday, Thursday, Friday<br />
<br />
=== focusgroup for improved keyboard navigation ===<br />
* Proposer: Travis Leithead, travil@microsoft.com<br />
* Summary: overview of new proposal for an HTML [focusgroup](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Focusgroup/explainer.md) attribute.<br />
* Type: talk & slides; discussion<br />
* Goal: spread awareness of the proposal, solicit feedback.<br />
* Access: open to everyone<br />
* Shortname: #focusgroup<br />
* Time: 12am UTC, 3pm UTC (only need 30 minutes)<br />
* days: Any day except Wed, 20th<br />
<br />
=== Privacy-Preserving Advertising Measurement ===<br />
* Proposer: [[User:Johnwilander|John Wilander]] ([[User talk:Johnwilander|talk]]) 20:33, 28 September 2021 (UTC)<br />
* Email address of proposer: wilander@apple.com<br />
* Summary (one-sentence or so): A discussion on where we are with the various ad tech proposals in Privacy CG, WICG, and IWABG.<br />
* Type of session: Summary talks from browser vendors first, then open discussion<br />
* Goals: Look for alignment, get reports on trials or early shipping features, get feedback on direction from others than browser vendors.<br />
* PrivateAdMeasurement (used for minting an IRC channel for the breakout)<br />
* Additional speakers/panelists: I would like to invite the various spec editors actively working on related proposals in Privacy CG, WICG, and IWABG.<br />
* Limited to TPAC participants or open to the public? I'm leaning TPAC participants but will want to hear what others say.<br />
* Timeslot: two slots among 12am UTC, 7am UTC, 3pm UTC<br />
<br />
=== Cross-Device Security (caBLE) ===<br />
* Proposer: [[User:Kryasuda|Kristina Yasda]] ([[User talk:Kryasuda|talk]]) 21:06, 29 September 2021 (UTC)Kristina Yasuda<br />
* Email address of proposer: kristina.yasuda@microsoft.com <br />
* Summary (one-sentence or so): Discuss methods to make cross-device flows more secure, such as user sharing data from the mobile device to the browser, with particular interest in leveraging caBLE<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): discussion<br />
* Goals: Agree on the problem statement, share available mitigations, agree on the next steps (if any) to make these mitigations more usable/standard<br />
* shortname (used for minting an IRC channel for the breakout): #crossdevicesec<br />
* Additional speakers/panelists: Tim Cappalli, tim.cappalli@microsoft.com<br />
* limited to TPAC participants or open to the public? open to everyone<br />
* Timeslot: one slot among 12am UTC, 3pm UTC, 2pm UTC<br />
* constraints on days in which the breakout can run: any day<br />
<br />
=== WCAG Maturity Model ===<br />
* Proposers: Sheri Byrne-Haber, David Fazio<br />
Email address of proposers: sbyrnehaber@vmware.com dfazio@helixopp.com <br />
* session facilitators and speakers: Jeanne Spellman, Sheri Byrne-Haber, David Fazio<br />
* one sentence session summary: Overview of progress to date and work on WCAG Maturity Model: https://docs.google.com/document/d/1Y5EO6zkOMrbyePw5-Crq8ojmhn9OCTRQ6TlgB0cE6YE<br />
* type of session: open discussion<br />
* goals of session - Present and discuss the WCAG Maturity Model work, and how it drives sustainable, continuously improving, WCAG compliance<br />
* additional speakers/panelists: Jake Abma<br />
* Open to anyone<br />
* IRC shortname #silver-maturity<br />
* time preference: 2 PM UTC<br />
* days: Monday, Tuesday, Wednesday, or Friday<br />
<br />
=== Navigating W3C Process Tracks: Living Specifications, Registries, Notes and Statements ===<br />
* Proposer: [[User:Plehegar|Philippe Le HĂŠgaret]] ([[User talk:Plehegar|talk]]) 12:36, 1 October 2021 (UTC)<br />
* Email address of proposer: plh@w3.org<br />
* Summary (one-sentence or so): W3C will approve a new Process in November, which now includes 3 tracks: Recommendation, Registry, Note. This session will present them and help Groups to navigate them.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): talk<br />
* Goals: Understand the W3C Tracks<br />
* shortname (used for minting an IRC channel for the breakout): process<br />
* [optional] Additional speakers/panelists:<br />
* limited to TPAC participants or open to the public? public<br />
* Timeslot: one slot at 2pm UTC<br />
<br />
=== Making WebViews work for the Web ===<br />
* Proposer: [[User:Dom|Dominique HazaĂŤl-Massieux]] ([[User talk:Dom|talk]]) 14:06, 1 October 2021 (UTC)<br />
* Email address of proposer: dom@w3.org<br />
* Summary: A significant share of Web pages get rendered via WebView components rather than through fullblown browser engines; WebViews come with limitations that are not always well understood by developers, nor standards makers. This session offers to discuss what if anything W3C should do to help<br />
* Type of session: talk followed by open discussion<br />
* Goals: Identify what role W3C should play in making WebViews work better for the Web<br />
* shortname: webviews<br />
* [optional] Additional speakers/panelists: TBC<br />
* open to the public<br />
* Timeslot: 7am UTC, 3pm UTC or one slot at 2pm UTC<br />
<br />
=== Use of Machine Learning to validate Success Criteria ===<br />
* Proposer: Sheri Byrne-Haber<br />
* Email address of proposer sbyrnehaber@vmware.com<br />
* session facilitators and speakers: Sheri Byrne-Haber<br />
* one sentence session summary: Which W3C success criteria can be validated using machine learning<br />
* type of session: presentation and open discussion<br />
* goals of session - Brief introduction to machine learning techniques, review of five success criteria that have been sucessfully automated, proposal for 16 more success criteria, and discussion and review of others that can potentially be automated.<br />
* additional speakers/panelists (to help reduce conflicts when one person is needed in more than one place)<br />
* open to public<br />
* a shortname that can be used to associate an IRC channel to your breakout: ml<br />
* time preference: 2pm UTC<br />
* days: Monday, Tuesday, Wednesday, or Friday (not he same date as the maturity modeling session, if selected)<br />
<br />
=== Personalizing the Web for Better Accessibility ===<br />
* Proposer: [[User:Lwolberg|Lionel Wolberger]] ([[User talk:Lwolberg|talk]]) 15:25, 4 October 2021 (UTC)<br />
* Email address of proposer: lionel@userway.org<br />
* Summary (one-sentence or so): Personalization Module 1.0 brings accessibility markup beyond screen readers, and enables many users to access services who are currently blocked. <br />
* Type of session (e.g.: open discussion, talk, panel, etc.): talk and open discussion<br />
* Goals: Participants will be motivated to implement Personalization Module 1 specification to enable many more people to access web content<br />
* shortname (used for minting an IRC channel for the breakout): personalization<br />
* limited to TPAC participants or open to the public? Open to the public<br />
* Timeslot: Prefer 1400 - 1500 UTC start time (1300 possible if necessary)<br />
* constraints on days in which the breakout can run: Monday, Tuesday, Thursday<br />
<br />
<br />
=== Intelligent Collaboration features for WebRTC (NV) ===<br />
* Proposer: [[User:riju|Rijubrata Bhaumik]] ([[User talk:riju|talk]]) 7:40, 6 October 2021 (UTC)<br />
* Email address of proposer: rijubrata.bhaumik@intel.com<br />
* Summary (one-sentence or so): As WebRTC gains more prominence in a remote friendly world, we need to delight users by enabling intelligent collaboration features for the Web like Face Detection, UserFraming, Eye-contact correction, Background Blur, Noise Suppression, SpeechToText and many more. <br />
* Type of session (e.g.: open discussion, talk, panel, etc.): talk and open discussion<br />
* Goals: Heads up on the new API extensions and gather feedback.<br />
* shortname (used for minting an IRC channel for the breakout): webrtc-ic<br />
* [optional] Additional speakers/panelists: Harald Alvestrand, Chris Needham<br />
* limited to TPAC participants or open to the public? Open to the public<br />
* Timeslot: Prefer 1400 - 1500 UTC start time <br />
* constraints on days in which the breakout can run: Wednesday<br />
<br />
=== Web Components Community Group: Community driven spec/API prioritization ===<br />
* Proposer: [[User:westbrook|Westbrook Johnson]] ([[User talk:westbrook|talk]]) 18:51, 6 October 2021 (UTC)<br />
* Email address of proposer: wesjohns@adobe.com<br />
* Summary (one-sentence or so): The Web Components Community Group will share their stance on need for and priority of various APIs and specs in support of delivering web components in production. <br />
* Type of session (e.g.: open discussion, talk, panel, etc.): talk and open discussion<br />
* Goals: Introduce the growing Web Components Community Group work to implementors and share community priorities for web component-centric API implementation and spec development in hopes of supporting clearer bi-directional communication around this work.<br />
* shortname (used for minting an IRC channel for the breakout): webcomponents-cg<br />
* [optional] Additional speakers/panelists: Will Riley, Owen Buckley, Justin Fagnani<br />
* limited to TPAC participants or open to the public? Open to the public<br />
<br />
=== What is the value of and are the values of W3C ===<br />
* Proposer: [[User:Tantekelik|Tantek Ăelik]] ([[User talk:Tantekelik|talk]]) 21:53, 6 October 2021 (UTC)<br />
* Email address of proposer: tantek(at)cs.stanford.edu<br />
* Summary (one-sentence or so): This is a follow-up from last year's [[TPAC/2020/focus-values]] session, which itself was a follow-up from a 2019 session (will find the link). W3C is currently both a community formed around shared values and formal structure of a consortium of four entities, each of which has a representative on the governing Steering Committee (SC) along with a CEO and the Director, with authority delegated to a team employed by those four entities. What happens when community shared values are in conflict with the power structures at W3C? What value do different members get out of W3C?<br />
* Type of session: open discussion (e.g.: open discussion, talk, panel, etc.): <br />
* Goals: open and frank discussion about similarities and differences in values & goals across the broader community, and how do those align with or conflict with or are upheld by the power structures in place.<br />
* shortname: what-values<br />
* [optional] Additional speakers/panelists:<br />
* limited to TPAC participants or open to the public? Public<br />
* [optional] Timeslot: prefer 12am UTC (17:00 PDT); can live with: 3pm UTC (08:00 PDT); not: 7am UTC, 2pm UTC.<br />
* [optional] constraints on days in which the breakout can run: TWTh 17:00PDT (TWTh24:00UTC or WThF00:00UTC), F 08:00PDT (15:00 UTC)</div>Plehegarhttps://www.w3.org/wiki/index.php?title=TPAC/2021/SessionIdeas&diff=113997TPAC/2021/SessionIdeas2021-10-01T12:36:53Z<p>Plehegar: /* W3C Process session */</p>
<hr />
<div>You are invited to propose [https://www.w3.org/2021/10/TPAC/ TPAC 2021] '''TPAC Breakout week (October 18-22)''' sessions in advance of the meeting, and '''before October 8''' if you want to benefit from optimal scheduling. <br />
See the [[TPAC/2021/FAQ | TPAC 2021 FAQ]] for more information. Please contact dom@w3.org for any question regarding the organization of TPAC breakouts.<br />
<br />
<div style="float:right;clear:right">__TOC__</div><br />
<br />
== How to use this page ==<br />
<br />
Please use this page to:<br />
<br />
* Propose sessions you wish to lead<br />
* '''Please place new proposals at the bottom of this document'''<br />
<br />
Any TPAC participant (participant in a Working Group, Interest Group, Business Group, or participant in a Community Group meeting at TPAC) may propose a session. We encourage you to bring new presenters to the community, particularly to help us improve the inclusiveness and diversity of W3C, listing yourself as the proposer. Please limit yourself to one or at most two proposals per proposer. <br />
<br />
The W3C planning team will review all proposed breakouts and may suggest refining, combining, or deferring some proposals. <br />
<br />
== Scheduling breakouts for broad community participation ==<br />
Breakouts are scheduled the week of October 18-22. The exact time and date of each breakout will be determined by the staff to reduce overlap of sessions with similar expected participants. We expect that scheduling to happen on October 8 - proposals submitted after October 8 will have much less flexibility in how they get scheduled.<br />
<br />
With the W3C community spread across the globe, we are suggesting two approaches to breakout facilitators:<br />
* run their sessions twice to make it possible for people from as many timezones as possible to attend sessions they care about. We suggest picking 2 among the following of times:<br />
** 12am UTC: 5pm US PT / 8pm US ET / 8am Beijing / 9am Tokyo / 11am Sydney<br />
** 7am UTC: 8am UK / 9am CET / 11am Dubai / 3pm Beijing / 4pm Tokyo / 6pm Sydney<br />
** 3pm UTC: 8am US PT / 11am US ET / 4pm UK / 5pm CET / 7pm Dubai<br />
* run it a single time at 2pm UTC (7am US PT / 10am US ET / 3pm UK / 4pm CET / 6pm Dubai / 10pm Beijing / 11pm Tokyo / 1am Sydney). Single instance TPAC breakout sessions proposed outside of the 2pm UTC slot are subject to validation.<br />
<br />
== How to propose a session ==<br />
<br />
Please provide:<br />
<ul class="show_items"><br />
* session name (as a === subhead === )<br />
* session facilitators and speakers<br />
* one sentence session summary<br />
* type of session: (e.g.: open discussion, talk, panel, tutorial, demo, etc.)<br />
* goals of session - what outcomes can session participants expect?<br />
* additional speakers/panelists (to help reduce conflicts when one person is needed in more than one place)<br />
* is this breakout only for TPAC participants or should it be open to anyone?<br />
* a shortname that can be used to associate an IRC channel to your breakout<br />
* time preference: (2 slots among the ones listed above, 1 slot 2pm UTC, or request an exception)<br />
* days: if your breakout can only be scheduled on a subset of the 5 days of the week, please also indicate it<br />
</ul><br />
<br />
== Breakout facilitator training ==<br />
<br />
To help make the experience of TPAC breakouts as inclusive and welcoming as possible, W3C is offering a program to support facilitators in preparing and running their sessions.<br />
<br />
We will be running two training sessions the week of October 4th <br />
* a 90 minutes workshop on Inclusive Facilitation Training, run by Kay Martinez, scheduled on October 5, 2021 at 2pm UTC<br />
** The session will be an update of the [https://www.w3.org/2020/10/TPAC/facilitator-training.html training run last year]<br />
* a workshop on conflict management, run by Jory Burson (exact time and date to be confirmed)<br />
<br />
These training sessions are open to anyone planning to run a breakout session, and more generally to anyone wanting to build their skills in W3C meeting facilitation, with the first workshop limited to 30 participants - please indicate your interest in attending it with dom@w3.org.<br />
<br />
In addition to these training sessions open to anyone, we are inviting breakout facilitators to volunteer for a more in-depth program, which will add the opportunity to get paired with a buddy and participate in a debriefing session after TPAC to keep better track of what did and did not work as well in terms of applying the training in practice. For scalability reasons, we only expect to accept about 10 people in this program, and ask that the said volunteers commit to participate to all of the sessions scheduled as part of this training program - please get in touch with dom@w3.org if you are interested.<br />
<br />
== Proposed sessions ==<br />
<br />
=== EXAMPLE session with session name ===<br />
* Proposer: <nowiki>~~~~</nowiki> (Instruction: remove <nowiki><nowiki> and </nowiki></nowiki> around the tildes (~). Explanation: The 4 tildes will sign YOUR name and include a timestamp of your proposal.)<br />
* Email address of proposer: <br />
* Summary (one-sentence or so): <br />
* Type of session (e.g.: open discussion, talk, panel, etc.): <br />
* Goals:<br />
* shortname (used for minting an IRC channel for the breakout)<br />
* [optional] Additional speakers/panelists:<br />
* limited to TPAC participants or open to the public?<br />
* [optional] Timeslot: two slots among 12am UTC, 7am UTC, 3pm UTC, one slot at 2pm UTC, or exception request<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Wednesday, Thursday, Friday<br />
<br />
=== State of CSS 2021 ===<br />
* Proposer: [[User:Foolip|Philip Jägenstedt]] ([[User talk:Foolip|talk]]) 14:57, 7 September 2021 (UTC)<br />
* Email address of proposer: foolip@google.com<br />
* Summary (one-sentence or so): State of CSS 2021: what do the results say?<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): discussion<br />
* Goals: Get insights from the State of CSS 2021 results and if possible prioritize spec and implementation work to address top wants or pain points.<br />
* shortname (used for minting an IRC channel for the breakout): stateofcss<br />
* [optional] Additional speakers/panelists:<br />
* Open to the public<br />
* [optional] Timeslot: one slot at 7am UTC, 2pm UTC, or 3pm UTC any day except Wednesday<br />
<br />
=== The state of browser storage partitioning ===<br />
* Proposer: [[User:Miketaylr|Michael Taylor]] ([[User talk:Miketaylr|talk]]) 20:27, 7 September 2021 (UTC)<br />
* Email address of proposer: miketaylr@google.com<br />
* Summary (one-sentence or so): What is the current state of storage partitioning efforts in browsers today?<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): discussion<br />
* Goals: Understand the progress of partitioning efforts and discover opportunities to align approaches. <br />
* shortname (used for minting an IRC channel for the breakout): partitioning<br />
* [optional] Additional speakers/panelists: Any browser reps or contributors are welcome to join the discussion<br />
* limited to TPAC participants or open to the public? Open to public<br />
* [optional] Timeslot: one slot at 3pm UTC<br />
* [optional] Preferably Thursday or Friday<br />
<br />
=== Project Fugu đĄ: Almost Three Years In⌠===<br />
* Proposer: [[User:Tsteiner|Thomas Steiner]] ([[User talk:Tsteiner|talk]]) 12:09, 8 September 2021 (UTC)<br />
* Email address of proposer: tomac@google.com<br />
* Summary (one-sentence or so): It's been almost three years that the [https://web.dev/fugu-status/ Project Fugu] effort was started. This is a good occasion to look back at what we have achieved and where we fell short of our objectives, but then also to look forward to what's still ahead of us.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Open discussion.<br />
* Goals: Reflect back and look forward.<br />
* shortname (used for minting an IRC channel for the breakout): project-fugu<br />
* [optional] Additional speakers/panelists: Edit this Wiki and add you!<br />
* limited to TPAC participants or open to the public? Open to the public.<br />
* [optional] Timeslot: One slot at 3pm UTC.<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Wednesday, Thursday.<br />
<br />
=== Voice Agent Interoperability ===<br />
* Proposer: Deborah Dahl [[User:Ddahl2|Deborah Dahl]] ([[User talk:Ddahl2|talk]]) 21:16, 8 September 2021 (UTC) <br />
* Email address of proposer: dahl@conversational-technologies.com<br />
* Summary (one-sentence or so): We now have silos of thousands of voice agents that only work with one platform. Enterprises have to develop multiple versions of their customer service applications and users may need multiple platforms to access all the voice agents they want to use. It would be much better if voice agents could interoperate with each other, perhaps using some standards analogous to HTML. In addition, discovery of voice agents with specific capabilities is currently haphazard and difficult. How can discovery be made easier? Is there an analogy to search engines and domain names? With these capabilities, the voice agent world would be much more like the web. This session will discuss issues related to interoperability of voice agents.<br />
* Type of session: open discussion<br />
* Goals: Raise issues of voice agent interoperability, including potential standards and barriers.<br />
* shortname (used for minting an IRC channel for the breakout):voiceagents<br />
* [optional] Additional speakers/panelists:<br />
* limited to TPAC participants or open to the public?: open to the public<br />
* [optional] Timeslot: two slots among 12am UTC, 3pm UTC or one slot at 2pm UTC<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Wednesday, Thursday, Friday<br />
<br />
=== WebID ===<br />
* Proposer: [[User:Cbiesing|Christian Biesinger]] ([[User talk:Cbiesing|talk]]) 17:48, 9 September 2021 (UTC)<br />
* Email address of proposer: cbiesinger@google.com<br />
* Summary (one-sentence or so): Discuss the state of the WebID spec<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): open discussion<br />
* Goals: Discuss the current state of ongoing WebID initiatives, which will help to have more privacy-preserving federated sign-in experiences.<br />
* shortname (used for minting an IRC channel for the breakout): webid<br />
* [optional] Additional speakers/panelists: Kaan Icer<br />
* limited to TPAC participants or open to the public? open<br />
* [optional] Timeslot: two slots among 12am UTC, 7am UTC, 3pm UTC, one slot at 2pm UTC, or exception request<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Wednesday, Thursday, Friday<br />
<br />
=== Framework for the Accessible Specification of Technologies ===<br />
* Proposer: [[User:Joconnor|Joshue O&#39;Connor]] ([[User talk:Joconnor|talk]]) 12:14, 13 September 2021 (UTC)<br />
* Email address of proposer: joconnor@w3.org<br />
* Summary (one-sentence or so): Overview of progress to date and work on [https://w3c.github.io/apa/fast/ FAST user needs and gap analysis methodology].<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Presentationa and open discussion.<br />
* Goals: Presentation and discussion of FAST work, how it relates to horizontal accessibility spec review as well as the development of our methodology for technique gap analysis in Silver.<br />
* shortname (used for minting an IRC channel for the breakout): fast<br />
* [optional] Additional speakers/panelists: Michael Cooper, Jake Abma, Jeanne Spellman.<br />
* limited to TPAC participants or open to the public?: TPAC participants<br />
* [optional] Timeslot: one slot at 2pm UTC<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Weds, Thurs<br />
<br />
<br />
=== Auto Accessibility breakout ===<br />
* Proposer: [[User:Joconnor|Joshue O&#39;Connor]] ([[User talk:Joconnor|talk]]) 12:14, 13 September 2021 (UTC)<br />
* Email address of proposer: tedguild@geotab.com<br />
* Summary (one-sentence or so): Determine scope of work for Accessibility in W3C Automotive either for technical specifications or in best practices document.<br />
<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): talk<br />
* Goals: The W3C Automotive activity is producing standards around telematics data and services for connected vehicles. While not directly defining user interfaces, there are opportunities to influence this industry at a formative stage for better accessibility inclusion in its technical architecture. Together with WAI Accessibility Platform Architecture (APA) Research Questions Task Force, we want to explain current work, as well as explore and prioritize potential work.<br />
* shortname (used for minting an IRC channel for the breakout): autoa11y<br />
* [optional] Additional speakers/panelists:<br />
* limited to TPAC participants or open to the public?: tpac<br />
* [optional] Timeslot: one slot at 2pm UTC<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Weds, Thurs<br />
<br />
=== COGA Content Usable: user needs to specifications ===<br />
* Proposer: [[User:Rainb|Rain Breaw Michaels]] ([[User talk:Rainb|talk]]) 13:37, 13 September 2021 (UTC) <br />
* Email address of proposer: rainb@google.com<br />
* Summary: [https://www.w3.org/TR/coga-usable/ Content Usable] gives advice on how to make content and interfaces usable for people with cognitive and learning disabilities. This breakout session will look at how this advice can translate into specifications.<br />
* Type of session: Panel followed by discussion<br />
* Goals: Enable working groups and task forces across W3C to make sure that the user needs of individuals with cognitive differences and disabilities (examples: autism, dementia, learning disabilities, and much more) are included in your user needs for your specifications so that you include the widest possible potential.<br />
* shortname (used for minting an IRC channel for the breakout): cogapanel<br />
* [optional] Additional speakers/panelists: Lisa Seeman, David Fazio, John Kirkwood, Rain Michaels<br />
* limited to TPAC participants or open to the public? tpac<br />
* [optional] Timeslot: one slot, preferred 2pm or 3pm UTC, 12am UTC will work, as well<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Wednesday, Thursday, Friday<br />
<br />
=== How to work with COGA ===<br />
* Proposer: [[User:Rainb|Rain Breaw Michaels]] ([[User talk:Rainb|talk]]) 22:04, 13 September 2021 (UTC) <br />
* Email address of proposer: rainb@google.com<br />
* Summary: Cover the types of cognitive and learning disabilities and differences that members of COGA (the Cognitive Accessibility Task Force) (and truthfully other members of W3C groups) may have, and how our collaboration processes across the W3C can better include the valuable perspectives of these individuals. <br />
* Type of session: Guided open discussion<br />
* Goals: Enable the various groups across the W3C to engage effectively with the COGA Task Force. Identify the tooling, communication styles, and processes that can support more inclusive and successful collaboration. <br />
* shortname (used for minting an IRC channel for the breakout): cogainclusion<br />
* [optional] Additional speakers/panelists: Jennie Delisi<br />
* limited to TPAC participants or open to the public? tpac<br />
* [optional] Timeslot: two slot, prefer 3pm UTC, but 12am UTC will work, as well<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Wednesday, Thursday<br />
<br />
=== Service Worker CSRF Discussion ===<br />
* Withdrawn due to scheduling conflicts this week.<br />
<br />
=== Introduction to Synchronization Accessibility User Requirements (SAUR) ===<br />
* Proposer: [[User:Bgibson|Becky Gibson]] ([[User talk:Bgibson|talk]]) 12:40, 15 September 2021 (UTC) <br />
* Email address of proposer: gibson.becky@gmail.com<br />
* Summary (one-sentence or so): Introduce Synchronization Accessibility User Requirements (SAUR) and implications on media related W3C specifications. <br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Panel and Q&A<br />
* Goals: Understand the issues surrounding synchronization in online media.<br />
* shortname (used for minting an IRC channel for the breakout): SAUR<br />
* [optional] Additional speakers/panelists: Janina Sajka, Steve Noble, Jason White, Joshue O'Connor, Scott Hallier<br />
* limited to TPAC participants or open to the public? Open to public<br />
* [optional] Timeslot: We have already confirmed availability of panelists and interested parties across the -8 to +8 UTC time zones for Wednesday, Oct 20 at 14:00 UTC so respectfully request that time slot if possible<br />
* [optional] Preferable the above already confirmed time slot to reach the wide range of time zones for the participants.<br />
<br />
=== Accessibility & CSS ===<br />
* Proposer: [[User:Bgibson|Becky Gibson]] ([[User talk:Bgibson|talk]]) 13:00, 15 September 2021 (UTC)<br />
* Email address of proposer: gibson.becky@gmail.com<br />
* Summary (one-sentence or so): Discussion of CSS and potential advances and implications for accessibility<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): open discussion<br />
* Goals: Discuss and review upcoming CSS features for where they may help and possibly hinder accessibility.<br />
* shortname (used for minting an IRC channel for the breakout): CSSA11y<br />
* [optional] Additional speakers/panelists:<br />
* limited to TPAC participants or open to the public? open to the public<br />
* [optional] Timeslot: We have already confirmed availability of CSS and APA working group participants on Wednesday, Oct 20 at 16:00 UTS so respectfully request that time slot if possible<br />
* [optional] constraints on days in which the breakout can run: Cannot run on Wed. Oct 20 at 14:00 UTC (if SAUR gets scheduled at that time) or against COGA breakouts<br />
<br />
=== Anti-Fraud for the Web ===<br />
* Proposer: [[User:svaldez|Steven Valdez]] ([[User talk:svaldez|talk]]) 21:00, 15 September 2021 (UTC) <br />
* Email address of proposer: svaldez@google.com<br />
* Summary (one-sentence or so): Discussion of current use of cross-site identification (third-party cookies, browser/device fingerprinting, etc) in various types of anti-fraud solutions on the web. <br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Short talks followed with guided open discussion <br />
* Goals: Discuss the use cases and requirements, along with potential next steps for work in the space.<br />
* shortname (used for minting an IRC channel for the breakout): antifraud<br />
* [optional] Additional speakers/panelists: <br />
* [optional] Timeslot: one slot at 2pm UTC<br />
* limited to TPAC participants or open to the public? open to the public<br />
* [https://github.com/WICG/trust-token-api/blob/main/antifrauid-breakout-agenda.md Agenda (more items/materials speakers welcome)]<br />
<br />
=== From MathML to AT ===<br />
* Proposer: [[User:Nsoiffer2|Neil Soiffer]] ([[User talk:Nsoiffer2|talk]]) 19:54, 17 September 2021 (UTC) <br />
* Email address of proposer: neil.soiffer@gmail.com<br />
* Summary (one-sentence or so): The MathML WG is collecting ideas to allow authors to clarify the meaning of mathematical expressions so that the content can be clearly conveyed to assistive technology. The WG is interested in outside ideas such as how ARIA, CSS, and/or microddata could be used for this purpose. The WG is also soliciting feedback on potential ideas the WG has discussed. This is about making math accessible within the web platform; no mathematical expertise is required.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Open discussion<br />
* Goals: To solicit ideas from various stakeholders and WGs as to what they feel is appropriate<br />
* shortname (used for minting an IRC channel for the breakout) a11y-math<br />
* [optional] Additional speakers/panelists:<br />
* limited to TPAC participants or open to the public? open to the public<br />
* [optional] Timeslot: 3pm UTC or 4pm UTC<br />
* [optional] any day (avoid conflicts with sessions that have a11y relevance)<br />
<br />
=== The State of Web Monetization ===<br />
* Proposer: [[User:uchiu|Uchi Uchibeke]] ([[User talk:uchiu|talk]]) 11:15, 22 September 2021 (UTC)<br />
* Email address of proposer: uchi@coil.com<br />
* Summary (one-sentence or so): Introduction to Web Monetization and ongoing changes to the Web Monetization spec to make it easier for wider adoption<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Open Discussion<br />
* Goals: To get feedback from stakeholders and discuss the potential path for supporting Web Monetization natively<br />
* shortname (used for minting an IRC channel for the breakout)<br />
* [optional] Additional speakers/panelists: <br />
* limited to TPAC participants or open to the public? open to the public<br />
* [optional] Timeslot: 2pm UTC or 3pm UTC<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Wednesday, Thursday, Friday<br />
<br />
<br />
=== Accessibility of Remote Meetings ===<br />
* Proposer:[[User:Shollier|Scott Hollier]] ([[User talk:Shollier|talk]]) 13:51, 22 September 2021 (UTC) Scott Hollier <br />
* Email address of proposer: scott@hollier.info <br />
* Summary (one-sentence or so): Discussion of the Accessibility of Remote meetings draft work being developed in the APA RQTF <br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Open Discussion<br />
* Goals: Discuss what's needed to ensure that remote meetings are accessible to people with disabilities, especially during this time when we have all become so reliant on remote communications. Also, discuss the applicability to other W3C work. <br />
* shortname (used for minting an IRC channel for the breakout): remotemeet<br />
* [optional] Additional speakers/panelists: Judy Brewer <br />
* limited to TPAC participants or open to the public? open to the public<br />
* [optional] Timeslot: 1pm UTC or 2pm UTC on any day. Times are based on presenter being based in +8 UTC time zone.<br />
<br />
=== Converting Tools for MiniApp ===<br />
* Proposer: Zitao Wang 9:00, 27 September 2021 (UTC)<br />
* Email address of proposer: wangzitao@huawei.com<br />
* Summary (one-sentence or so): Tools for converting standard MiniApp to vendor-specific implementations.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): discussion<br />
* Goals: Demonstrate potential solutions for converting standards to vendor implementations. Discuss the tool design and improvement solution.<br />
* shortname (used for minting an IRC channel for the breakout): MiniAppTools<br />
* [optional] Additional speakers/panelists:Open to the public<br />
* [optional] Timeslot: 9am-12am UTC<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Wednesday, Thursday, Friday<br />
<br />
=== focusgroup for improved keyboard navigation ===<br />
* Proposer: Travis Leithead, travil@microsoft.com<br />
* Summary: overview of new proposal for an HTML [focusgroup](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Focusgroup/explainer.md) attribute.<br />
* Type: talk & slides; discussion<br />
* Goal: spread awareness of the proposal, solicit feedback.<br />
* Access: open to everyone<br />
* Shortname: #focusgroup<br />
* Time: 12am UTC, 3pm UTC (only need 30 minutes)<br />
* days: Any day except Wed, 20th<br />
<br />
=== Privacy-Preserving Advertising Measurement ===<br />
* Proposer: [[User:Johnwilander|John Wilander]] ([[User talk:Johnwilander|talk]]) 20:33, 28 September 2021 (UTC)<br />
* Email address of proposer: wilander@apple.com<br />
* Summary (one-sentence or so): A discussion on where we are with the various ad tech proposals in Privacy CG, WICG, and IWABG.<br />
* Type of session: Summary talks from browser vendors first, then open discussion<br />
* Goals: Look for alignment, get reports on trials or early shipping features, get feedback on direction from others than browser vendors.<br />
* PrivateAdMeasurement (used for minting an IRC channel for the breakout)<br />
* Additional speakers/panelists: I would like to invite the various spec editors actively working on related proposals in Privacy CG, WICG, and IWABG.<br />
* Limited to TPAC participants or open to the public? I'm leaning TPAC participants but will want to hear what others say.<br />
* Timeslot: two slots among 12am UTC, 7am UTC, 3pm UTC<br />
<br />
=== Cross-Device Security (caBLE) ===<br />
* Proposer: [[User:Kryasuda|Kristina Yasda]] ([[User talk:Kryasuda|talk]]) 21:06, 29 September 2021 (UTC)Kristina Yasuda<br />
* Email address of proposer: kristina.yasuda@microsoft.com <br />
* Summary (one-sentence or so): Discuss methods to make cross-device flows more secure, such as user sharing data from the mobile device to the browser, with particular interest in leveraging caBLE<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): discussion<br />
* Goals: Agree on the problem statement, share available mitigations, agree on the next steps (if any) to make these mitigations more usable/standard<br />
* shortname (used for minting an IRC channel for the breakout): #crossdevicesec<br />
* Additional speakers/panelists: Tim Cappalli, tim.cappalli@microsoft.com<br />
* limited to TPAC participants or open to the public? open to everyone<br />
* Timeslot: one slot among 12am UTC, 3pm UTC, 2pm UTC<br />
* constraints on days in which the breakout can run: any day<br />
<br />
=== WCAG Maturity Model ===<br />
* Proposers: Sheri Byrne-Haber, David Fazio<br />
Email address of proposers: sbyrnehaber@vmware.com dfazio@helixopp.com <br />
* session facilitators and speakers: Jeanne Spellman, Sheri Byrne-Haber, David Fazio<br />
* one sentence session summary: Overview of progress to date and work on WCAG Maturity Model: https://docs.google.com/document/d/1Y5EO6zkOMrbyePw5-Crq8ojmhn9OCTRQ6TlgB0cE6YE<br />
* type of session: open discussion<br />
* goals of session - Present and discuss the WCAG Maturity Model work, and how it drives sustainable, continuously improving, WCAG compliance<br />
* additional speakers/panelists: Jake Abma<br />
* Open to anyone<br />
* IRC shortname #silver-maturity<br />
* time preference: 2 PM UTC<br />
* days: Monday, Tuesday, Wednesday, or Friday<br />
<br />
=== Navigating W3C Process Tracks: Living Specifications, Registries, Notes and Statements ===<br />
* Proposer: [[User:Plehegar|Philippe Le HĂŠgaret]] ([[User talk:Plehegar|talk]]) 12:36, 1 October 2021 (UTC)<br />
* Email address of proposer: plh@w3.org<br />
* Summary (one-sentence or so): W3C will approve a new Process in November, which now includes 3 tracks: Recommendation, Registry, Note. This session will present them and help Groups to navigate them.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): talk<br />
* Goals: Understand the W3C Tracks<br />
* shortname (used for minting an IRC channel for the breakout): process<br />
* [optional] Additional speakers/panelists:<br />
* limited to TPAC participants or open to the public? public<br />
* [optional] Timeslot: two slots among 12am UTC, 7am UTC, 3pm UTC, one slot at 2pm UTC, or exception request<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Wednesday, Thursday, Friday</div>Plehegarhttps://www.w3.org/wiki/index.php?title=TPAC/2021/SessionIdeas&diff=113996TPAC/2021/SessionIdeas2021-10-01T12:32:35Z<p>Plehegar: Fixed WCAG Maturity Model title</p>
<hr />
<div>You are invited to propose [https://www.w3.org/2021/10/TPAC/ TPAC 2021] '''TPAC Breakout week (October 18-22)''' sessions in advance of the meeting, and '''before October 8''' if you want to benefit from optimal scheduling. <br />
See the [[TPAC/2021/FAQ | TPAC 2021 FAQ]] for more information. Please contact dom@w3.org for any question regarding the organization of TPAC breakouts.<br />
<br />
<div style="float:right;clear:right">__TOC__</div><br />
<br />
== How to use this page ==<br />
<br />
Please use this page to:<br />
<br />
* Propose sessions you wish to lead<br />
* '''Please place new proposals at the bottom of this document'''<br />
<br />
Any TPAC participant (participant in a Working Group, Interest Group, Business Group, or participant in a Community Group meeting at TPAC) may propose a session. We encourage you to bring new presenters to the community, particularly to help us improve the inclusiveness and diversity of W3C, listing yourself as the proposer. Please limit yourself to one or at most two proposals per proposer. <br />
<br />
The W3C planning team will review all proposed breakouts and may suggest refining, combining, or deferring some proposals. <br />
<br />
== Scheduling breakouts for broad community participation ==<br />
Breakouts are scheduled the week of October 18-22. The exact time and date of each breakout will be determined by the staff to reduce overlap of sessions with similar expected participants. We expect that scheduling to happen on October 8 - proposals submitted after October 8 will have much less flexibility in how they get scheduled.<br />
<br />
With the W3C community spread across the globe, we are suggesting two approaches to breakout facilitators:<br />
* run their sessions twice to make it possible for people from as many timezones as possible to attend sessions they care about. We suggest picking 2 among the following of times:<br />
** 12am UTC: 5pm US PT / 8pm US ET / 8am Beijing / 9am Tokyo / 11am Sydney<br />
** 7am UTC: 8am UK / 9am CET / 11am Dubai / 3pm Beijing / 4pm Tokyo / 6pm Sydney<br />
** 3pm UTC: 8am US PT / 11am US ET / 4pm UK / 5pm CET / 7pm Dubai<br />
* run it a single time at 2pm UTC (7am US PT / 10am US ET / 3pm UK / 4pm CET / 6pm Dubai / 10pm Beijing / 11pm Tokyo / 1am Sydney). Single instance TPAC breakout sessions proposed outside of the 2pm UTC slot are subject to validation.<br />
<br />
== How to propose a session ==<br />
<br />
Please provide:<br />
<ul class="show_items"><br />
* session name (as a === subhead === )<br />
* session facilitators and speakers<br />
* one sentence session summary<br />
* type of session: (e.g.: open discussion, talk, panel, tutorial, demo, etc.)<br />
* goals of session - what outcomes can session participants expect?<br />
* additional speakers/panelists (to help reduce conflicts when one person is needed in more than one place)<br />
* is this breakout only for TPAC participants or should it be open to anyone?<br />
* a shortname that can be used to associate an IRC channel to your breakout<br />
* time preference: (2 slots among the ones listed above, 1 slot 2pm UTC, or request an exception)<br />
* days: if your breakout can only be scheduled on a subset of the 5 days of the week, please also indicate it<br />
</ul><br />
<br />
== Breakout facilitator training ==<br />
<br />
To help make the experience of TPAC breakouts as inclusive and welcoming as possible, W3C is offering a program to support facilitators in preparing and running their sessions.<br />
<br />
We will be running two training sessions the week of October 4th <br />
* a 90 minutes workshop on Inclusive Facilitation Training, run by Kay Martinez, scheduled on October 5, 2021 at 2pm UTC<br />
** The session will be an update of the [https://www.w3.org/2020/10/TPAC/facilitator-training.html training run last year]<br />
* a workshop on conflict management, run by Jory Burson (exact time and date to be confirmed)<br />
<br />
These training sessions are open to anyone planning to run a breakout session, and more generally to anyone wanting to build their skills in W3C meeting facilitation, with the first workshop limited to 30 participants - please indicate your interest in attending it with dom@w3.org.<br />
<br />
In addition to these training sessions open to anyone, we are inviting breakout facilitators to volunteer for a more in-depth program, which will add the opportunity to get paired with a buddy and participate in a debriefing session after TPAC to keep better track of what did and did not work as well in terms of applying the training in practice. For scalability reasons, we only expect to accept about 10 people in this program, and ask that the said volunteers commit to participate to all of the sessions scheduled as part of this training program - please get in touch with dom@w3.org if you are interested.<br />
<br />
== Proposed sessions ==<br />
<br />
=== EXAMPLE session with session name ===<br />
* Proposer: <nowiki>~~~~</nowiki> (Instruction: remove <nowiki><nowiki> and </nowiki></nowiki> around the tildes (~). Explanation: The 4 tildes will sign YOUR name and include a timestamp of your proposal.)<br />
* Email address of proposer: <br />
* Summary (one-sentence or so): <br />
* Type of session (e.g.: open discussion, talk, panel, etc.): <br />
* Goals:<br />
* shortname (used for minting an IRC channel for the breakout)<br />
* [optional] Additional speakers/panelists:<br />
* limited to TPAC participants or open to the public?<br />
* [optional] Timeslot: two slots among 12am UTC, 7am UTC, 3pm UTC, one slot at 2pm UTC, or exception request<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Wednesday, Thursday, Friday<br />
<br />
=== State of CSS 2021 ===<br />
* Proposer: [[User:Foolip|Philip Jägenstedt]] ([[User talk:Foolip|talk]]) 14:57, 7 September 2021 (UTC)<br />
* Email address of proposer: foolip@google.com<br />
* Summary (one-sentence or so): State of CSS 2021: what do the results say?<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): discussion<br />
* Goals: Get insights from the State of CSS 2021 results and if possible prioritize spec and implementation work to address top wants or pain points.<br />
* shortname (used for minting an IRC channel for the breakout): stateofcss<br />
* [optional] Additional speakers/panelists:<br />
* Open to the public<br />
* [optional] Timeslot: one slot at 7am UTC, 2pm UTC, or 3pm UTC any day except Wednesday<br />
<br />
=== The state of browser storage partitioning ===<br />
* Proposer: [[User:Miketaylr|Michael Taylor]] ([[User talk:Miketaylr|talk]]) 20:27, 7 September 2021 (UTC)<br />
* Email address of proposer: miketaylr@google.com<br />
* Summary (one-sentence or so): What is the current state of storage partitioning efforts in browsers today?<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): discussion<br />
* Goals: Understand the progress of partitioning efforts and discover opportunities to align approaches. <br />
* shortname (used for minting an IRC channel for the breakout): partitioning<br />
* [optional] Additional speakers/panelists: Any browser reps or contributors are welcome to join the discussion<br />
* limited to TPAC participants or open to the public? Open to public<br />
* [optional] Timeslot: one slot at 3pm UTC<br />
* [optional] Preferably Thursday or Friday<br />
<br />
=== Project Fugu đĄ: Almost Three Years In⌠===<br />
* Proposer: [[User:Tsteiner|Thomas Steiner]] ([[User talk:Tsteiner|talk]]) 12:09, 8 September 2021 (UTC)<br />
* Email address of proposer: tomac@google.com<br />
* Summary (one-sentence or so): It's been almost three years that the [https://web.dev/fugu-status/ Project Fugu] effort was started. This is a good occasion to look back at what we have achieved and where we fell short of our objectives, but then also to look forward to what's still ahead of us.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Open discussion.<br />
* Goals: Reflect back and look forward.<br />
* shortname (used for minting an IRC channel for the breakout): project-fugu<br />
* [optional] Additional speakers/panelists: Edit this Wiki and add you!<br />
* limited to TPAC participants or open to the public? Open to the public.<br />
* [optional] Timeslot: One slot at 3pm UTC.<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Wednesday, Thursday.<br />
<br />
=== Voice Agent Interoperability ===<br />
* Proposer: Deborah Dahl [[User:Ddahl2|Deborah Dahl]] ([[User talk:Ddahl2|talk]]) 21:16, 8 September 2021 (UTC) <br />
* Email address of proposer: dahl@conversational-technologies.com<br />
* Summary (one-sentence or so): We now have silos of thousands of voice agents that only work with one platform. Enterprises have to develop multiple versions of their customer service applications and users may need multiple platforms to access all the voice agents they want to use. It would be much better if voice agents could interoperate with each other, perhaps using some standards analogous to HTML. In addition, discovery of voice agents with specific capabilities is currently haphazard and difficult. How can discovery be made easier? Is there an analogy to search engines and domain names? With these capabilities, the voice agent world would be much more like the web. This session will discuss issues related to interoperability of voice agents.<br />
* Type of session: open discussion<br />
* Goals: Raise issues of voice agent interoperability, including potential standards and barriers.<br />
* shortname (used for minting an IRC channel for the breakout):voiceagents<br />
* [optional] Additional speakers/panelists:<br />
* limited to TPAC participants or open to the public?: open to the public<br />
* [optional] Timeslot: two slots among 12am UTC, 3pm UTC or one slot at 2pm UTC<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Wednesday, Thursday, Friday<br />
<br />
=== WebID ===<br />
* Proposer: [[User:Cbiesing|Christian Biesinger]] ([[User talk:Cbiesing|talk]]) 17:48, 9 September 2021 (UTC)<br />
* Email address of proposer: cbiesinger@google.com<br />
* Summary (one-sentence or so): Discuss the state of the WebID spec<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): open discussion<br />
* Goals: Discuss the current state of ongoing WebID initiatives, which will help to have more privacy-preserving federated sign-in experiences.<br />
* shortname (used for minting an IRC channel for the breakout): webid<br />
* [optional] Additional speakers/panelists: Kaan Icer<br />
* limited to TPAC participants or open to the public? open<br />
* [optional] Timeslot: two slots among 12am UTC, 7am UTC, 3pm UTC, one slot at 2pm UTC, or exception request<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Wednesday, Thursday, Friday<br />
<br />
=== Framework for the Accessible Specification of Technologies ===<br />
* Proposer: [[User:Joconnor|Joshue O&#39;Connor]] ([[User talk:Joconnor|talk]]) 12:14, 13 September 2021 (UTC)<br />
* Email address of proposer: joconnor@w3.org<br />
* Summary (one-sentence or so): Overview of progress to date and work on [https://w3c.github.io/apa/fast/ FAST user needs and gap analysis methodology].<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Presentationa and open discussion.<br />
* Goals: Presentation and discussion of FAST work, how it relates to horizontal accessibility spec review as well as the development of our methodology for technique gap analysis in Silver.<br />
* shortname (used for minting an IRC channel for the breakout): fast<br />
* [optional] Additional speakers/panelists: Michael Cooper, Jake Abma, Jeanne Spellman.<br />
* limited to TPAC participants or open to the public?: TPAC participants<br />
* [optional] Timeslot: one slot at 2pm UTC<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Weds, Thurs<br />
<br />
<br />
=== Auto Accessibility breakout ===<br />
* Proposer: [[User:Joconnor|Joshue O&#39;Connor]] ([[User talk:Joconnor|talk]]) 12:14, 13 September 2021 (UTC)<br />
* Email address of proposer: tedguild@geotab.com<br />
* Summary (one-sentence or so): Determine scope of work for Accessibility in W3C Automotive either for technical specifications or in best practices document.<br />
<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): talk<br />
* Goals: The W3C Automotive activity is producing standards around telematics data and services for connected vehicles. While not directly defining user interfaces, there are opportunities to influence this industry at a formative stage for better accessibility inclusion in its technical architecture. Together with WAI Accessibility Platform Architecture (APA) Research Questions Task Force, we want to explain current work, as well as explore and prioritize potential work.<br />
* shortname (used for minting an IRC channel for the breakout): autoa11y<br />
* [optional] Additional speakers/panelists:<br />
* limited to TPAC participants or open to the public?: tpac<br />
* [optional] Timeslot: one slot at 2pm UTC<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Weds, Thurs<br />
<br />
=== COGA Content Usable: user needs to specifications ===<br />
* Proposer: [[User:Rainb|Rain Breaw Michaels]] ([[User talk:Rainb|talk]]) 13:37, 13 September 2021 (UTC) <br />
* Email address of proposer: rainb@google.com<br />
* Summary: [https://www.w3.org/TR/coga-usable/ Content Usable] gives advice on how to make content and interfaces usable for people with cognitive and learning disabilities. This breakout session will look at how this advice can translate into specifications.<br />
* Type of session: Panel followed by discussion<br />
* Goals: Enable working groups and task forces across W3C to make sure that the user needs of individuals with cognitive differences and disabilities (examples: autism, dementia, learning disabilities, and much more) are included in your user needs for your specifications so that you include the widest possible potential.<br />
* shortname (used for minting an IRC channel for the breakout): cogapanel<br />
* [optional] Additional speakers/panelists: Lisa Seeman, David Fazio, John Kirkwood, Rain Michaels<br />
* limited to TPAC participants or open to the public? tpac<br />
* [optional] Timeslot: one slot, preferred 2pm or 3pm UTC, 12am UTC will work, as well<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Wednesday, Thursday, Friday<br />
<br />
=== How to work with COGA ===<br />
* Proposer: [[User:Rainb|Rain Breaw Michaels]] ([[User talk:Rainb|talk]]) 22:04, 13 September 2021 (UTC) <br />
* Email address of proposer: rainb@google.com<br />
* Summary: Cover the types of cognitive and learning disabilities and differences that members of COGA (the Cognitive Accessibility Task Force) (and truthfully other members of W3C groups) may have, and how our collaboration processes across the W3C can better include the valuable perspectives of these individuals. <br />
* Type of session: Guided open discussion<br />
* Goals: Enable the various groups across the W3C to engage effectively with the COGA Task Force. Identify the tooling, communication styles, and processes that can support more inclusive and successful collaboration. <br />
* shortname (used for minting an IRC channel for the breakout): cogainclusion<br />
* [optional] Additional speakers/panelists: Jennie Delisi<br />
* limited to TPAC participants or open to the public? tpac<br />
* [optional] Timeslot: two slot, prefer 3pm UTC, but 12am UTC will work, as well<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Wednesday, Thursday<br />
<br />
=== Service Worker CSRF Discussion ===<br />
* Withdrawn due to scheduling conflicts this week.<br />
<br />
=== Introduction to Synchronization Accessibility User Requirements (SAUR) ===<br />
* Proposer: [[User:Bgibson|Becky Gibson]] ([[User talk:Bgibson|talk]]) 12:40, 15 September 2021 (UTC) <br />
* Email address of proposer: gibson.becky@gmail.com<br />
* Summary (one-sentence or so): Introduce Synchronization Accessibility User Requirements (SAUR) and implications on media related W3C specifications. <br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Panel and Q&A<br />
* Goals: Understand the issues surrounding synchronization in online media.<br />
* shortname (used for minting an IRC channel for the breakout): SAUR<br />
* [optional] Additional speakers/panelists: Janina Sajka, Steve Noble, Jason White, Joshue O'Connor, Scott Hallier<br />
* limited to TPAC participants or open to the public? Open to public<br />
* [optional] Timeslot: We have already confirmed availability of panelists and interested parties across the -8 to +8 UTC time zones for Wednesday, Oct 20 at 14:00 UTC so respectfully request that time slot if possible<br />
* [optional] Preferable the above already confirmed time slot to reach the wide range of time zones for the participants.<br />
<br />
=== Accessibility & CSS ===<br />
* Proposer: [[User:Bgibson|Becky Gibson]] ([[User talk:Bgibson|talk]]) 13:00, 15 September 2021 (UTC)<br />
* Email address of proposer: gibson.becky@gmail.com<br />
* Summary (one-sentence or so): Discussion of CSS and potential advances and implications for accessibility<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): open discussion<br />
* Goals: Discuss and review upcoming CSS features for where they may help and possibly hinder accessibility.<br />
* shortname (used for minting an IRC channel for the breakout): CSSA11y<br />
* [optional] Additional speakers/panelists:<br />
* limited to TPAC participants or open to the public? open to the public<br />
* [optional] Timeslot: We have already confirmed availability of CSS and APA working group participants on Wednesday, Oct 20 at 16:00 UTS so respectfully request that time slot if possible<br />
* [optional] constraints on days in which the breakout can run: Cannot run on Wed. Oct 20 at 14:00 UTC (if SAUR gets scheduled at that time) or against COGA breakouts<br />
<br />
=== Anti-Fraud for the Web ===<br />
* Proposer: [[User:svaldez|Steven Valdez]] ([[User talk:svaldez|talk]]) 21:00, 15 September 2021 (UTC) <br />
* Email address of proposer: svaldez@google.com<br />
* Summary (one-sentence or so): Discussion of current use of cross-site identification (third-party cookies, browser/device fingerprinting, etc) in various types of anti-fraud solutions on the web. <br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Short talks followed with guided open discussion <br />
* Goals: Discuss the use cases and requirements, along with potential next steps for work in the space.<br />
* shortname (used for minting an IRC channel for the breakout): antifraud<br />
* [optional] Additional speakers/panelists: <br />
* [optional] Timeslot: one slot at 2pm UTC<br />
* limited to TPAC participants or open to the public? open to the public<br />
* [https://github.com/WICG/trust-token-api/blob/main/antifrauid-breakout-agenda.md Agenda (more items/materials speakers welcome)]<br />
<br />
=== From MathML to AT ===<br />
* Proposer: [[User:Nsoiffer2|Neil Soiffer]] ([[User talk:Nsoiffer2|talk]]) 19:54, 17 September 2021 (UTC) <br />
* Email address of proposer: neil.soiffer@gmail.com<br />
* Summary (one-sentence or so): The MathML WG is collecting ideas to allow authors to clarify the meaning of mathematical expressions so that the content can be clearly conveyed to assistive technology. The WG is interested in outside ideas such as how ARIA, CSS, and/or microddata could be used for this purpose. The WG is also soliciting feedback on potential ideas the WG has discussed. This is about making math accessible within the web platform; no mathematical expertise is required.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Open discussion<br />
* Goals: To solicit ideas from various stakeholders and WGs as to what they feel is appropriate<br />
* shortname (used for minting an IRC channel for the breakout) a11y-math<br />
* [optional] Additional speakers/panelists:<br />
* limited to TPAC participants or open to the public? open to the public<br />
* [optional] Timeslot: 3pm UTC or 4pm UTC<br />
* [optional] any day (avoid conflicts with sessions that have a11y relevance)<br />
<br />
=== The State of Web Monetization ===<br />
* Proposer: [[User:uchiu|Uchi Uchibeke]] ([[User talk:uchiu|talk]]) 11:15, 22 September 2021 (UTC)<br />
* Email address of proposer: uchi@coil.com<br />
* Summary (one-sentence or so): Introduction to Web Monetization and ongoing changes to the Web Monetization spec to make it easier for wider adoption<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Open Discussion<br />
* Goals: To get feedback from stakeholders and discuss the potential path for supporting Web Monetization natively<br />
* shortname (used for minting an IRC channel for the breakout)<br />
* [optional] Additional speakers/panelists: <br />
* limited to TPAC participants or open to the public? open to the public<br />
* [optional] Timeslot: 2pm UTC or 3pm UTC<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Wednesday, Thursday, Friday<br />
<br />
<br />
=== Accessibility of Remote Meetings ===<br />
* Proposer:[[User:Shollier|Scott Hollier]] ([[User talk:Shollier|talk]]) 13:51, 22 September 2021 (UTC) Scott Hollier <br />
* Email address of proposer: scott@hollier.info <br />
* Summary (one-sentence or so): Discussion of the Accessibility of Remote meetings draft work being developed in the APA RQTF <br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Open Discussion<br />
* Goals: Discuss what's needed to ensure that remote meetings are accessible to people with disabilities, especially during this time when we have all become so reliant on remote communications. Also, discuss the applicability to other W3C work. <br />
* shortname (used for minting an IRC channel for the breakout): remotemeet<br />
* [optional] Additional speakers/panelists: Judy Brewer <br />
* limited to TPAC participants or open to the public? open to the public<br />
* [optional] Timeslot: 1pm UTC or 2pm UTC on any day. Times are based on presenter being based in +8 UTC time zone.<br />
<br />
=== Converting Tools for MiniApp ===<br />
* Proposer: Zitao Wang 9:00, 27 September 2021 (UTC)<br />
* Email address of proposer: wangzitao@huawei.com<br />
* Summary (one-sentence or so): Tools for converting standard MiniApp to vendor-specific implementations.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): discussion<br />
* Goals: Demonstrate potential solutions for converting standards to vendor implementations. Discuss the tool design and improvement solution.<br />
* shortname (used for minting an IRC channel for the breakout): MiniAppTools<br />
* [optional] Additional speakers/panelists:Open to the public<br />
* [optional] Timeslot: 9am-12am UTC<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Wednesday, Thursday, Friday<br />
<br />
=== focusgroup for improved keyboard navigation ===<br />
* Proposer: Travis Leithead, travil@microsoft.com<br />
* Summary: overview of new proposal for an HTML [focusgroup](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Focusgroup/explainer.md) attribute.<br />
* Type: talk & slides; discussion<br />
* Goal: spread awareness of the proposal, solicit feedback.<br />
* Access: open to everyone<br />
* Shortname: #focusgroup<br />
* Time: 12am UTC, 3pm UTC (only need 30 minutes)<br />
* days: Any day except Wed, 20th<br />
<br />
=== Privacy-Preserving Advertising Measurement ===<br />
* Proposer: [[User:Johnwilander|John Wilander]] ([[User talk:Johnwilander|talk]]) 20:33, 28 September 2021 (UTC)<br />
* Email address of proposer: wilander@apple.com<br />
* Summary (one-sentence or so): A discussion on where we are with the various ad tech proposals in Privacy CG, WICG, and IWABG.<br />
* Type of session: Summary talks from browser vendors first, then open discussion<br />
* Goals: Look for alignment, get reports on trials or early shipping features, get feedback on direction from others than browser vendors.<br />
* PrivateAdMeasurement (used for minting an IRC channel for the breakout)<br />
* Additional speakers/panelists: I would like to invite the various spec editors actively working on related proposals in Privacy CG, WICG, and IWABG.<br />
* Limited to TPAC participants or open to the public? I'm leaning TPAC participants but will want to hear what others say.<br />
* Timeslot: two slots among 12am UTC, 7am UTC, 3pm UTC<br />
<br />
=== Cross-Device Security (caBLE) ===<br />
* Proposer: [[User:Kryasuda|Kristina Yasda]] ([[User talk:Kryasuda|talk]]) 21:06, 29 September 2021 (UTC)Kristina Yasuda<br />
* Email address of proposer: kristina.yasuda@microsoft.com <br />
* Summary (one-sentence or so): Discuss methods to make cross-device flows more secure, such as user sharing data from the mobile device to the browser, with particular interest in leveraging caBLE<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): discussion<br />
* Goals: Agree on the problem statement, share available mitigations, agree on the next steps (if any) to make these mitigations more usable/standard<br />
* shortname (used for minting an IRC channel for the breakout): #crossdevicesec<br />
* Additional speakers/panelists: Tim Cappalli, tim.cappalli@microsoft.com<br />
* limited to TPAC participants or open to the public? open to everyone<br />
* Timeslot: one slot among 12am UTC, 3pm UTC, 2pm UTC<br />
* constraints on days in which the breakout can run: any day<br />
<br />
=== WCAG Maturity Model ===<br />
* Proposers: Sheri Byrne-Haber, David Fazio<br />
Email address of proposers: sbyrnehaber@vmware.com dfazio@helixopp.com <br />
* session facilitators and speakers: Jeanne Spellman, Sheri Byrne-Haber, David Fazio<br />
* one sentence session summary: Overview of progress to date and work on WCAG Maturity Model: https://docs.google.com/document/d/1Y5EO6zkOMrbyePw5-Crq8ojmhn9OCTRQ6TlgB0cE6YE<br />
* type of session: open discussion<br />
* goals of session - Present and discuss the WCAG Maturity Model work, and how it drives sustainable, continuously improving, WCAG compliance<br />
* additional speakers/panelists: Jake Abma<br />
* Open to anyone<br />
* IRC shortname #silver-maturity<br />
* time preference: 2 PM UTC<br />
* days: Monday, Tuesday, Wednesday, or Friday</div>Plehegarhttps://www.w3.org/wiki/index.php?title=Application_Foundations/CoreDesignAndDev&diff=112956Application Foundations/CoreDesignAndDev2021-01-22T18:00:10Z<p>Plehegar: </p>
<hr />
<div>The key technologies in this foundation help Web developers meet user expectations about the âlook and feelâ of Web applications. Users naturally expect user experiences with certain âlook and feelâ characteristics of a consistent level of quality across the different platforms on which they use applicationsâincluding the Web; for example, users of native mobile apps expect Web applications to have some of the same desirable âlook and feelâ UX characteristics that their native mobile apps have.<br />
<br />
So in part, this foundation can be seen as aiming to provide developers with the tools they need to build applications with âlook and feelâ UX characteristics of the same level of quality as they experience with native mobile apps and other application platforms.<br />
<br />
This foundation includes CSS, graphics formats, animation mechanisms, typography, HTML, the DOM, and JavaScriptâand the high-level goals are to have a âcore toolboxâ of technologies for controlling âlook and feelâ UX characteristics that is:<br />
<br />
* reliably <b>interoperable</b> across all browsers<br />
* as <b>easy-to-use for developers</b> as possible<br />
<br />
Relevant specs:<br />
* [http://www.w3.org/Style/CSS/current-work#roadmap CSS (roadmap)] - Houdini helps developer pain points there<br />
* [http://w3c.github.io/web-animations/ Web Animations] - consistent model integrating CSS Anim, SMIL Anim<br />
* [https://html.spec.whatwg.org/multipage/embedded-content.html The picture element (responsive images)]<br />
* [https://svgwg.org/svg2-draft/ SVG.next]<br />
* [http://dev.w3.org/webfonts/WOFF2/spec/ WOFF 2.0]<br />
* [http://www.w3.org/html/wg/drafts/html/master/ HTML5.next]<br />
* [http://w3c.github.io/editing-explainer/ HTML rich-text editing]<br />
* [http://w3c.github.io/selection-api/ Selection API]<br />
* [http://webaudio.github.io/web-audio-api/ WebAudio API]<br />
* [https://dom.spec.whatwg.org/ DOM]<br />
* [https://streams.spec.whatwg.org/ Streams]<br />
* [https://html.spec.whatwg.org/multipage/workers.html#workers Web Workers]<br />
* [https://html.spec.whatwg.org/multipage/custom-elements.html Custom Elements]<br />
* Shadow DOM: Most of the Shadow DOM specification has been upstreamed to DOM, HTML, CSS Scoping, UI Events, and other relevant specifications.<br />
<br />
Also the various language requirements guides: [http://www.w3.org/TR/jlreq/ Japanese], [http://www.chinaw3c.org/layout-workshop-report.html Chinese], [http://www.w3.org/International/docs/indic-layout/ Indic], [http://w3c.github.io/dpub-pagination/ Latin] etc and the requirements from digital publishing.<br />
<br />
== Goals ==<br />
* document <b>developer</b> use-case scenarios that fall under this foundation<br />
* <b>document current developer âpain pointsâ related to developing engaging and compelling Web applications using CSS, graphics formats, animation mechanisms, and typography</b>; for example, lack of ability to easily create compelling users experiences with drag-and-drop mechanisms across browsers; or lack of ability to create compelling user experiences with rich-text editing across browsers<br />
* <b>document "success stories" we've had so far for addressing developer pain points; e.g., Responsive Images (the picture element), CSS-TAG [https://lists.w3.org/Archives/Public/public-houdini/ "Houdini"] work just starting to make CSS layout more user extensible</b><br />
* define a prioritization framework for these various <ins>developer</ins> use cases <ins>can be addressed</ins><br />
* evaluate how much of these use cases are currently achievable with existing techs<br />
* <b>evaluate how much of the developer âpain pointsâ are currently achievable with existing techs</b><br />
* for use cases that are not achievable (or in unsatisfactory ways), determine which technologies are needed (Houdini working on this)<br />
* <b>for pain points that are not addressable (or in unsatisfactory ways), determine which fixes/refinements are needed</b><br />
* among those that are needed and in progress, determine how to accelerate their development<br />
* among those that are needed and not in progress, determine how to get them started<br />
<br />
== Potential milestones ==<br />
* Feb 15: document some existing â<b>âcore toolboxâ technologies that are the most-severe pain points for developers</b>; the model example of a document of this kind is the [http://w3c.github.io/editing-explainer Editing Explainer] developed by the [http://w3c.github.io/editing-explainer/tf-charter.html HTML Editing Task Force]<br />
* Feb 15: <b>document some existing âsuccess storiesâ for âcore toolboxâ technologies that have solved some severe pain points for developers</b>âwith an eye toward figuring out how to reproduce those successes (e.g., Responsive Images (the picture element)<br />
* Feb 19: Review of capabilities of native platforms in this space<br />
* Feb 28: proposed framework for prioritizing <b>consideration of the identified âpriority pain pointsâ</b><br />
* Feb 28: Outreach to the developers on the proposed framework<br />
* April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment<br />
* April 24: Report for progress on application foundation due for AC meeting<br />
* May 5: AC meeting starts<br />
<br />
== Progress ==<br />
Over the last year to 18 months, work in several Core Design/Development groups has been informed by the notion of extensibility and in particular the ''composability'' of multiple extensions. Early work showed that single extensions were relatively easy t make in some areas, but tended to step on each other's toes. Applicattion Foundations has driven some of that, although the major impetus was the [https://extensiblewebmanifesto.org/ Extensible Web Manifesto].<br />
<br />
As a result, functionality has been shifted from SVG to CSS with the expectation of using it in Web Components. CSS has done good work on styling the Shadow DOM, which allows integrating the styling of extensions into the overall site style; it has also started the Houdini project together with the TAG, to provide APIs that expose previously hidden functionality that already exists in the browser and which extensions would otherwise have to re-implement. Other changes include a focus on not specifying special-case functionality, but instead favouring generality and composability (particularly in layout models); and ongoing discussions about the styling and functionality of rich text selection, annotation, and editing.<br />
<br />
There is starting to be a conversation on ''maintenance'' of large websites (in particular the CSS) and learning from frameworks like SASS which are increasingly used. On the downside, there is a tendency to ignore/reimplement large sections of te OWP in JavaScript, which is extension but is rarely composable.<br />
<br />
The impact of extensibility on ''performance'' continues to be a hot topic. As an example, WebAudio abandoned a previous extensibility design (ScriptProcessor node) because it blocked the main layout thread; instead a new although more complex design was introduced ([https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API#Audio_Workers Audio Workers]) which provides non-blocking and low-jitter extensibility, after content developer feedback raised significant concerns about the older design. Performance improvements based on responsive images are also increasingly discussed.</div>Plehegarhttps://www.w3.org/wiki/index.php?title=Application_Foundations/CoreDesignAndDev&diff=112955Application Foundations/CoreDesignAndDev2021-01-22T17:58:54Z<p>Plehegar: </p>
<hr />
<div>The key technologies in this foundation help Web developers meet user expectations about the âlook and feelâ of Web applications. Users naturally expect user experiences with certain âlook and feelâ characteristics of a consistent level of quality across the different platforms on which they use applicationsâincluding the Web; for example, users of native mobile apps expect Web applications to have some of the same desirable âlook and feelâ UX characteristics that their native mobile apps have.<br />
<br />
So in part, this foundation can be seen as aiming to provide developers with the tools they need to build applications with âlook and feelâ UX characteristics of the same level of quality as they experience with native mobile apps and other application platforms.<br />
<br />
This foundation includes CSS, graphics formats, animation mechanisms, typography, HTML, the DOM, and JavaScriptâand the high-level goals are to have a âcore toolboxâ of technologies for controlling âlook and feelâ UX characteristics that is:<br />
<br />
* reliably <b>interoperable</b> across all browsers<br />
* as <b>easy-to-use for developers</b> as possible<br />
<br />
Relevant specs:<br />
* [http://www.w3.org/Style/CSS/current-work#roadmap CSS (roadmap)] - Houdini helps developer pain points there<br />
* [http://w3c.github.io/web-animations/ Web Animations] - consistent model integrating CSS Anim, SMIL Anim<br />
* [https://html.spec.whatwg.org/multipage/embedded-content.html The picture element (responsive images)]<br />
* [https://svgwg.org/svg2-draft/ SVG.next]<br />
* [http://dev.w3.org/webfonts/WOFF2/spec/ WOFF 2.0]<br />
* [http://www.w3.org/html/wg/drafts/html/master/ HTML5.next]<br />
* [http://w3c.github.io/editing-explainer/ HTML rich-text editing]<br />
* [http://w3c.github.io/selection-api/ Selection API]<br />
* [http://webaudio.github.io/web-audio-api/ WebAudio API]<br />
* [https://dom.spec.whatwg.org/ DOM]<br />
* [https://streams.spec.whatwg.org/ Streams]<br />
* [https://html.spec.whatwg.org/multipage/workers.html#workers Web Workers]<br />
* [http://wicg.github.io/webcomponents/spec/custom/ Custom Elements]<br />
* [http://wicg.github.io/webcomponents/spec/shadow/ Shadow DOM]<br />
<br />
Also the various language requirements guides: [http://www.w3.org/TR/jlreq/ Japanese], [http://www.chinaw3c.org/layout-workshop-report.html Chinese], [http://www.w3.org/International/docs/indic-layout/ Indic], [http://w3c.github.io/dpub-pagination/ Latin] etc and the requirements from digital publishing.<br />
<br />
== Goals ==<br />
* document <b>developer</b> use-case scenarios that fall under this foundation<br />
* <b>document current developer âpain pointsâ related to developing engaging and compelling Web applications using CSS, graphics formats, animation mechanisms, and typography</b>; for example, lack of ability to easily create compelling users experiences with drag-and-drop mechanisms across browsers; or lack of ability to create compelling user experiences with rich-text editing across browsers<br />
* <b>document "success stories" we've had so far for addressing developer pain points; e.g., Responsive Images (the picture element), CSS-TAG [https://lists.w3.org/Archives/Public/public-houdini/ "Houdini"] work just starting to make CSS layout more user extensible</b><br />
* define a prioritization framework for these various <ins>developer</ins> use cases <ins>can be addressed</ins><br />
* evaluate how much of these use cases are currently achievable with existing techs<br />
* <b>evaluate how much of the developer âpain pointsâ are currently achievable with existing techs</b><br />
* for use cases that are not achievable (or in unsatisfactory ways), determine which technologies are needed (Houdini working on this)<br />
* <b>for pain points that are not addressable (or in unsatisfactory ways), determine which fixes/refinements are needed</b><br />
* among those that are needed and in progress, determine how to accelerate their development<br />
* among those that are needed and not in progress, determine how to get them started<br />
<br />
== Potential milestones ==<br />
* Feb 15: document some existing â<b>âcore toolboxâ technologies that are the most-severe pain points for developers</b>; the model example of a document of this kind is the [http://w3c.github.io/editing-explainer Editing Explainer] developed by the [http://w3c.github.io/editing-explainer/tf-charter.html HTML Editing Task Force]<br />
* Feb 15: <b>document some existing âsuccess storiesâ for âcore toolboxâ technologies that have solved some severe pain points for developers</b>âwith an eye toward figuring out how to reproduce those successes (e.g., Responsive Images (the picture element)<br />
* Feb 19: Review of capabilities of native platforms in this space<br />
* Feb 28: proposed framework for prioritizing <b>consideration of the identified âpriority pain pointsâ</b><br />
* Feb 28: Outreach to the developers on the proposed framework<br />
* April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment<br />
* April 24: Report for progress on application foundation due for AC meeting<br />
* May 5: AC meeting starts<br />
<br />
== Progress ==<br />
Over the last year to 18 months, work in several Core Design/Development groups has been informed by the notion of extensibility and in particular the ''composability'' of multiple extensions. Early work showed that single extensions were relatively easy t make in some areas, but tended to step on each other's toes. Applicattion Foundations has driven some of that, although the major impetus was the [https://extensiblewebmanifesto.org/ Extensible Web Manifesto].<br />
<br />
As a result, functionality has been shifted from SVG to CSS with the expectation of using it in Web Components. CSS has done good work on styling the Shadow DOM, which allows integrating the styling of extensions into the overall site style; it has also started the Houdini project together with the TAG, to provide APIs that expose previously hidden functionality that already exists in the browser and which extensions would otherwise have to re-implement. Other changes include a focus on not specifying special-case functionality, but instead favouring generality and composability (particularly in layout models); and ongoing discussions about the styling and functionality of rich text selection, annotation, and editing.<br />
<br />
There is starting to be a conversation on ''maintenance'' of large websites (in particular the CSS) and learning from frameworks like SASS which are increasingly used. On the downside, there is a tendency to ignore/reimplement large sections of te OWP in JavaScript, which is extension but is rarely composable.<br />
<br />
The impact of extensibility on ''performance'' continues to be a hot topic. As an example, WebAudio abandoned a previous extensibility design (ScriptProcessor node) because it blocked the main layout thread; instead a new although more complex design was introduced ([https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API#Audio_Workers Audio Workers]) which provides non-blocking and low-jitter extensibility, after content developer feedback raised significant concerns about the older design. Performance improvements based on responsive images are also increasingly discussed.</div>Plehegarhttps://www.w3.org/wiki/index.php?title=TPAC/2020&diff=112754TPAC/20202020-10-30T16:52:22Z<p>Plehegar: </p>
<hr />
<div>{{stub}}<br />
<br />
TPAC 2020 is virtual:<br />
* WG/IG/BG/CG meetings: self-organized; NOT overlapping the TPAC breakout week (26 to 30 October)<br />
* Joint Group meetings week: self-organized; 12-16 October<br />
* TPAC Breakout week: 26-30 October<br />
<br />
For all information, see [https://www.w3.org/2020/10/TPAC/ W3C TPAC 2020]<br />
<br />
== Plan to be there ==<br />
* [https://wiki.csswg.org/planning#upcoming-meetings CSSWG]<br />
* DID WG<br />
* (and others)<br />
<br />
== See Also ==<br />
* Previously: [[TPAC/2019]]<br />
* [[TPAC]] - list of past TPACs</div>Plehegarhttps://www.w3.org/wiki/index.php?title=TPAC&diff=112752TPAC2020-10-30T16:42:00Z<p>Plehegar: </p>
<hr />
<div>{{stub}}<br />
<br />
The next TPAC is:<br />
* [[TPAC/2021|TPAC 2021]]<br />
<br />
Farther in the future:<br />
* [[TPAC/2022|TPAC 2022]]<br />
<br />
Past:<br />
* [[TPAC/2020|TPAC 2020]]<br />
* [[TPAC/2019|TPAC 2019]]<br />
* [[TPAC/2018|TPAC 2018]]<br />
* [[TPAC/2017|TPAC 2017]]<br />
* [[TPAC/2016|TPAC 2016]]<br />
* [[TPAC/2015|TPAC 2015]]<br />
* [[TPAC/2014|TPAC 2014]]<br />
* [[TPAC/2013|TPAC 2013]]<br />
* [[TPAC/2012|TPAC 2012]]<br />
* [[TPAC/2011|TPAC 2011]]<br />
* Previous TPACs had no "unconference/breakouts" on the Plenary Day<br />
<br />
The W3C site has a [https://www.w3.org/2002/09/TPOverview.html list of all TPAC meetings]<br />
<br />
Number of breakout sessions held during the TPACs Technical Plenary Day:<br />
* 2011: 30 sessions (santa clara)<br />
* 2012: 39 sessions (lyon)<br />
* 2013: 26 sessions (shenzhen)<br />
* 2014: 30 sessions (santa clara)<br />
* 2015: 47 sessions (sapporo)<br />
* 2016: 35 sessions (lisbon)<br />
* 2017: 40 sessions (burlingame)<br />
* 2018: 47 sessions (lyon)<br />
* 2019: [https://w3c.github.io/tpac-breakouts/sessions.html 59 sessions] (fukuoka)</div>Plehegarhttps://www.w3.org/wiki/index.php?title=TPAC/2020/SessionIdeas&diff=112672TPAC/2020/SessionIdeas2020-10-19T12:34:21Z<p>Plehegar: Fixed proposer for real</p>
<hr />
<div>You are invited to propose [https://www.w3.org/2020/10/TPAC/ TPAC 2020] '''TPAC Breakout week (October 26-30)''' sessions in advance of the meeting. <br />
See the [[TPAC/2020/FAQ | TPAC 2020 FAQ]] for more information. Please contact dom@w3.org for any question regarding the organization of TPAC breakouts.<br />
<br />
<div style="float:right;clear:right">__TOC__</div><br />
<br />
== How to use this page ==<br />
<br />
Please use this page to:<br />
<br />
* Propose sessions you wish to lead<br />
* '''Please place new proposals at the bottom of this document'''<br />
<br />
== How to propose a session ==<br />
<br />
Please provide:<br />
<ul class="show_items"><br />
* session name (as a === subhead === )<br />
* session proposer (yourself, if so sign using 4 tildes; optional: name a desired session leader) and an email address<br />
* one sentence session summary<br />
* type of session: (e.g.: open discussion, talk, panel, tutorial, demo, etc.)<br />
* goals of session<br />
* additional speakers/panelists (to help reduce conflicts when one person is needed in more than one place)<br />
* opt-in to be a [[#Public_Breakout]] open to participation from the public at large<br />
* a shortname that can be used to associate an IRC or Slack channel to your breakout<br />
* by default, we expect breakout to happen at 2pm UTC for '''one hour''' during the week of October 26 to allow participation from as many timezones as possible; if your breakout cannot happen at 2pm UTC, or if your breakout can be scheduled to happen across multiple repeated instances at different time (e.g. for a tutorial, demos), please indicate it<br />
** single instance TPAC breakout sessions proposed outside of the 2pm slot are subject to validation by the organizing committee<br />
* if your breakout needs to happen on a subset of the 5 days of the week, please also indicate it<br />
</ul><br />
<br />
== Public Breakout ==<br />
<br />
In addition to the usual breakout discussions organized for the traditional TPAC community (IG/WG participants, W3C member representatives), we are trying something new this year. We plan to open a set of breakouts to the broader public, in an effort to bring more diverse voices into the W3C community. We feel this is necessary to ensure the fullest range of users and perspectives is represented and encoded in our web standards. <br />
<br />
Breakout proposers are invited to opt-in to make their breakout open to the public in order to invite a wider and more diverse set. While there aren't clearly defined limits to what topics would benefit from this, we encourage Public Breakouts to focus on use cases or ergonomics of a technology, and to provide upfront onboarding and context for any breakouts that include deep technical dive.<br />
<br />
The W3C devrel team and their partners will work with Public Breakout proposers to ensure their breakouts are as welcoming and kind as possible when joining their first W3C or Web standardization discussion. For anyone who opts in to propose a Public Breakout , we will be offering dedicated training sessions the week before TPAC breakouts on the topic of facilitating accessible discussions.<br />
<br />
(Many thanks to Boaz Sender, Sheila Moussavi, Jory Burson, Laura Lee McCarthy who have been working with Marie-Claire Forgue and Dominique Hazael-Massieux in setting this up)<br />
<br />
== Proposed sessions ==<br />
<br />
=== EXAMPLE session with session name ===<br />
* Proposer: <nowiki>~~~~</nowiki> (Instruction: remove <nowiki><nowiki> and </nowiki></nowiki> around the tildas. Explanation: The 4 tildas will sign YOUR name and include a timestamp of your proposal.)<br />
* Email address of proposer: <br />
* Summary (one-sentence or so): <br />
* Type of session (e.g.: open discussion, talk, panel, etc.): <br />
* Goals:<br />
* shortname (used for minting an IRC channel for the breakout)<br />
* [optional] Additional speakers/panelists:<br />
* [optional] Apply to be a [[#Public_Breakout]] (breakouts open to the world at large, not just the W3C community)<br />
* [optional] Timeslot: 2pm UTC ("the golden hour" - 7am US West Coast, 11pm Japan) - if you can't run your breakout proposal at 2pm UTC, we ask that you consider carefully alternatives in the 12pm-5pm UTC, knowing that a number of people won't be able to make it; alternatively, if your breakout can happen as a repeated instance (e.g. for a tutorial or a demo), please indicate so and we will schedule these instances away from the golden hour<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Wednesday, Thursday, Friday<br />
<br />
=== IAB Europe's Transparency and Control Framework ===<br />
* Proposer: [[User:Benhum|Ben Humphry]] <br />
* Email address of proposer: humphry@iabeurope.eu<br />
* Summary (one-sentence or so): Internet Advertising Bureau (IAB) Europe to brief W3C members on Transparency and Consent Framework (TCF), developed over many years to capture peopleâs consent choices and inform multiple parties. [https://github.com/w3c/web-advertising/issues/86/ Web-Advertising Github Issue]<br />
* Type of session: talk and open discussion<br />
* Goals: Explain this existing framework which provides consumers with a transparent and fair mechanism for control of their privacy preferences.<br />
* shortname: TCF<br />
* Additional speakers/panelists: TBD - Experts from IAB Europe<br />
* Apply to be a [[#Public_Breakout]]: yes<br />
* Timeslot: Any of 12pmâ5pm UTC.<br />
<br />
=== MDN Developer Need Assessments: results and next steps ===<br />
* Proposer: [[User:Dom|Dominique HazaĂŤl-Massieux]] <br />
* Email address of proposer: dom@w3.org<br />
* Summary (one-sentence or so): Review outcome of the [https://insights.developer.mozilla.org/ MDN DNA survey 2019], incl recently released [https://mdn-web-dna.s3-us-west-2.amazonaws.com/MDN-Browser-Compatibility-Report-2020.pdf MDN Browser Compat Report] and expectations on MDN DNA Survey 2020<br />
* Type of session: talk and open discussion<br />
* Goals: Inform how large-scale developer input has impacted and should impact standardization priorities<br />
* shortname: mdn-dna<br />
* Additional speakers/panelists: Philip Jägenstedt, Robert Nyman, Chris Mills, Boaz Sender<br />
* Apply to be a [[#Public_Breakout]]: yes<br />
<br />
=== Learning from Mini Apps ===<br />
* Proposer: [[User:Tsteiner|Thomas Steiner]] <br />
* Email address of proposer: tomac@google.com<br />
* Summary: In this breakout session, I will first explain what mini apps are and how to build them, and then move on to an open discussion focused on what Web developers can learn from mini apps and their developer experience. <br />
* Type of session: Talk followed by discussion.<br />
* Goals: Having a better understanding of mini apps.<br />
* Shortname: miniappslearnings<br />
* [optional] Additional speakers/panelists: You?<br />
* [optional] Apply to be a [[#Public_Breakout]]: Yes.<br />
* [optional] Timeslot: Any of 12pmâ5pm UTC.<br />
* [optional] Constraints on days in which the breakout can run: No constraints.<br />
<br />
=== Web Packaging ===<br />
* Proposer: [[User:Jyasskin|Jeffrey Yasskin]] <br />
* Email address of proposer: jyasskin@google.com<br />
* Summary (one-sentence or so): Discuss Web Packaging issues that [https://github.com/WICG/webpackage/issues?q=is%3Aopen+is%3Aissue+label%3Adiscuss need discussion].<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Open Discussion<br />
* Goals: Resolve or make progress on some open issues with the web packaging design<br />
* Shortname: web-packaging<br />
* [optional] Additional speakers/panelists:<br />
* [optional] Apply to be a [[#Public_Breakout]]: yes<br />
* [optional] Timeslot: 2pm UTC<br />
* [optional] constraints on days in which the breakout can run: No constraints.<br />
<br />
=== Memory copies & zero-copy operations on the Web ===<br />
* Proposer: [[User:Fd|François Daoust]] <br />
* Email address of proposer: fd@w3.org<br />
* Summary (one-sentence or so): In scenarios such as real-time processing of media frames with ML algorithms, memory copies made along the processing pipeline may account for a non negligible part of the overall performance budget of the said processing. See [https://github.com/w3c/machine-learning-workshop/issues/93 Memory copies discussion in the Web and Machine Learning workshop] for context. Could the Web do better?<br />
* Type of session: Open discussion<br />
* Goals: Explore needs to copy memory in various Web technologies (JS, WebAssembly, WebGPU, Machine Learning, WebRTC, Media) and identify possible architectural updates to the Web Platform that could help reduce unneeded memory copies.<br />
* shortname: zerocopy<br />
* Timeslot: 2pm UTC<br />
<br />
=== Video Metadata For Moving Objects &amp; Sensors On The Web (WebVMT) ===<br />
* Proposer: [[User:Rjksmith|Rob Smith]] <br />
* Email address of proposer: rob.smith@awayteam.co.uk<br />
* Summary: Emerging markets in 'mobile video devices' such as dashcams, drones, body-worn video and smartphones are increasing consumer demand for geotagged video on the web and especially with access to moving objects, e.g. distance &amp; speed for vehicles, and sensor data, e.g. heart rate for fitness users. More details at [https://github.com/w3c/sdw/issues/1194 w3c/sdw #1194]<br />
* Type of session: Short talk followed by discussion<br />
* Goals: Identify properties of moving objects &amp; sensors required in a web API to access timed video metadata exported for the web, i.e. WebVMT, from mobile video devices.<br />
* Shortname video-location<br />
* Apply to be a [[#Public_Breakout]]<br />
* Timeslot: 2pm UTC<br />
<br />
=== Improve definition of parties and trust relationships across W3C ===<br />
* Proposer: [[User:Jwrosewell|James Rosewell]] <br />
* Email address of proposer: james@51degrees.com<br />
* Summary (one-sentence or so): First and third party are poorly defined and lack the granularity to resolve many of the problems W3C are working on. Debate definitions of parties considering their relationship with one another, trust, choice, scale and varying conditions in relation to people. See IWA BG issue for commentary and pre session discussion. [https://github.com/w3c/web-advertising/issues/87]<br />
* Type of session: Presentations followed by discussion<br />
* Goals: Agreement on approach to define parties consistently and appropriately across W3C including TAG and PING documents.<br />
* shortname: party-time<br />
* Speakers/panelists: TBD â would like to add advocates for different view points.<br />
* Apply to be a [[#Public_Breakout]] (as a minimum should include Improving Web Advertising Business Group members)<br />
* Timeslot: 2pm to 4pm UTC<br />
* Monday, Tuesday, Wednesday<br />
<br />
=== Web Components ===<br />
* Proposer: [[User:rniwa|Ryosuke Niwa]] <br />
* Email address of proposer: rniwa at apple<br />
* Summary (one-sentence or so): Discussion of various topics related to web components<br />
* Type of session: Multi-topic discussion; Agenda and logistics is tracked at https://github.com/w3c/webcomponents/issues/877<br />
* Goals: Reaching consensus on various topics<br />
* shortname: components<br />
* Apply to be a #Public_Breakout: yes<br />
* Timeslot: 5pm UTC<br />
<br />
=== Parts and Template Instantiation ===<br />
* Proposer: [[User:rniwa|Ryosuke Niwa]] <br />
* Email address of proposer: rniwa at apple<br />
* Summary (one-sentence or so): Discussion of APIs to help instantiate templates.<br />
* Type of session: A presentation followed by discussion<br />
* Goals: Make progress on the proposal and reach some consensus on minimal viable product.<br />
* shortname: components<br />
* Apply to be a #Public_Breakout: yes<br />
* Timeslot: 5pm UTC<br />
<br />
=== Declarative Shadow DOM ===<br />
* Proposer: [[User:mfreed|Mason Freed]] <br />
* Email address of proposer: masonfreed@chromium.org<br />
* Summary (one-sentence or so): Discussion of the declarative Shadow DOM [https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md proposal]/[https://github.com/whatwg/dom/issues/831 issue]<br />
* Type of session: A presentation followed by discussion.<br />
* Goals: Reach some consensus on the proposal and spec.<br />
* shortname: components<br />
* Apply to be a #Public_Breakout: yes<br />
* Timeslot: 5pm UTC<br />
<br />
=== Making math a first class citizen on the Web ===<br />
* Proposer: [[User:Nsoiffer2|Neil Soiffer]] <br />
* Email address of proposer: neil.soiffer@gmail.com<br />
* Summary: The MathML Refresh CG is forming a WG and we would like to discuss our [https://mathml-refresh.github.io/charter-drafts/math-2020.html proposed charter] with interested parties. The group has coordinated with the CSS WG, WhatWG, and TAG over some issues and there are many remaining open questions involving Shadow DOM, Houdini, Links, the accessibility tree, search and other parts of the Web platform.<br />
* Type of session: open discussion<br />
* Goals: Provoke discussions on some of the subtle issues of including math in the Web platform and get guidance on resolving them.<br />
* shortname: math<br />
* Additional speakers/panelists: Brian Karkell (bkardell@gmail.com)<br />
* Apply to be a [[#Public_Breakout]]: yes<br />
* Timeslot: 3:00pm UTC<br />
<br />
=== All your spec are belong to us - irrigating dev resources from specs ===<br />
* Proposer: [[User:Dom|Dominique HazaÍl-Massieux]], [[User:Fd|François Daoust]]<br />
* Email address of proposer: dom@w3.org, fd@w3.org<br />
* Summary: Machines read specs too. This breakout session will review existing and possible tools and projects that make use of content automatically extracted from specs.<br />
* Type of session: Talk and open discussion<br />
* Goals: Raise awareness and learn about existing internal and external projects (such as webref, Bikeshed, Respec, MDN, Visual Studio, Web Platform Tests) that depend on content extracted from specs, to irrigate CSS/IDL tests and interface headers in browser codebases, validate cross-references, enrich IDE tools, identify dependencies, detect anomalies, and otherwise improve the quality of the specifications. Clarify what happens when e.g. IDL content is no longer valid or machine-readable. Discuss usage scenarios that additional formalism for writing specs could perhaps enable.<br />
* shortname: specmining<br />
* Apply to be a [[#Public_Breakout]]<br />
<br />
=== Maps for HTML Community Group ===<br />
* Proposer: [[User:Prushfor|Peter Rushforth]] <br />
* Email address of proposer: peter.rushforth@canada.ca<br />
* Summary: The Maps for HTML community recently concluded a successful [https://www.w3.org/2020/maps/agenda#day-1 workshop] about standardizing maps for the Web platform, and we would like to invite those interested to take part in a follow up meeting.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Summary presentation of workshop, followed by open discussion.<br />
* Goals: Provide and receive information on specific topics<br />
* shortname: maps4html (used for minting an IRC channel for the breakout)<br />
* Apply to be a [[#Public_Breakout]]: yes<br />
* Timeslot: 2pm UTC<br />
<br />
=== EPUB 3 History and Future ===<br />
* Proposer: [[User:Tzviya|Tzviya Siegman]] Tzviya Siegman and Wendy Reid <br />
* Email address of proposer: tsiegman@wiley.com<br />
* Summary (one-sentence or so): Learn about the 20+ year history of EPUB, how it came to the W3C, and what the new EPUB 3 WG will accomplish. <br />
* Type of session: talk with time for questions <br />
* Goals: Provide info about EPUB and Publishing Activity<br />
* shortname EPUB3<br />
* [optional] Additional speakers/panelists: Wendy Reid and (possibly) Shinya Takami<br />
* [optional] Apply to be a [[#Public_Breakout]]: yes<br />
<br />
=== Delegated Ink Trails ===<br />
* Proposer: [[User:Mabian|Mario Bianucci]] <br />
* Email address of proposer: mabian@microsoft.com<br />
* Summary: Delegated Ink Trail Presentation Paradigm: Prototype status and learnings from web developers feedback.<br />
* Type of session: open discussion<br />
* Goals: Discuss the proposed paradigm, and reach consensus on next steps.<br />
* shortname: delegated_ink_trail<br />
* Apply to be a [[#Public_Breakout]]: yes.<br />
* Timeslot: 2pm UTC<br />
* constraints on days in which the breakout can run: Tuesday, Wednesday, Thursday, Friday<br />
<br />
=== W3C New York Metro Chapter Meetup ===<br />
* Proposer: Rachel Yager <br />
* Email address of proposer: rachel@fortunetimesgroup.com / ryager@w3.org<br />
* Summary (one-sentence or so): Inviting Web Community to Join the W3C New York Metro Chapter. W3C Members and Non-Members are Welcome! The Chapter provides a point of presence of W3C within the Metropolitan New York City to build and enhance the Web Community, to assist W3C Members, and to invite W3C Members participation in WebInnovationX Center for World Wide Web research and education initiatives.<br />
* Type of session: Seminar Talks and Presentations<br />
* Goals: Provide information on W3C NY Metro Chapter Member Benefits, Activities, Events, Strategic Partnership, Leadership, and Technology Innovation Initiatives.<br />
* shortname: WebInnovationX<br />
* Additional speakers/panelists: TBD<br />
* Apply to be a [[#Public_Breakout]]: yes<br />
* Timeslot: 4pm UTC<br />
* constraints on days in which the breakout can run: Wednesday<br />
<br />
=== Media Publishers of the Web, Unite! ===<br />
* Proposer: [[User:Rberjon|Robin Berjon]] <br />
* Email address of proposer: robin.berjon@nytimes.com<br />
* Summary (one-sentence or so): Media publishers have long been absent or under-represented in Web standards, but there is a growing sense that we should speak up in the making of tech and a growing set of members. This session is to share fears, hopes, tips, and more.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): <br />
* Goals: Get media publishers to meet and help each other out navigate the strange but beautiful world of standards.<br />
* shortname (used for minting an IRC channel for the breakout): media-pubs<br />
* Apply to be a [[#Public_Breakout]]: yeah<br />
* Timeslot: 2pm UTC<br />
<br />
=== Revenue Models for the Web ===<br />
* Proposer: [[User:Ahopebai|Adrian Hope-Bailie]] <br />
* Email address of proposer: Ali Spivak (ali@coil.com) and Adrian Hope-Bailie (adrian@coil.com)<br />
* Summary (one-sentence or so): There has been a lot of discussion and [[https://webmonetization.org experimentation]] looking at alternatives to advertising for monetization on the Web. In this panel we aim to explore these alternative models, debate whether or not advertising still has a role to play, and discuss the potential for standards to enable a broader set of business models.<br />
* Type of session: Panel followed by open discussion<br />
* Goals: Discuss options for generating revenue on the Web and how standards can enable more options.<br />
* shortname (used for minting an IRC channel for the breakout): monetization<br />
* Additional speakers/panelists: Panel currently being confirmed. Please email the proposers if you wish to join the panel.<br />
* Apply to be a [[#Public_Breakout]]: YES<br />
* Timeslot: 2pm UTC ("the golden hour" - 7am US West Coast, 11pm Japan)<br />
<br />
=== Online Harms â a European and UK perspective ===<br />
* Proposer: [[User:Jwrosewell|James Rosewell]] <br />
* Email address of proposer: james@51degrees.com<br />
* Summary (one-sentence or so): Presentation to cover a) the current state of online harm legislation in the UK and Europe including the Audio-Visual Media Services Directive (AVMS-D) on 1st November 2020; * b) child safety and the impact DNS over HTTPs is having; and c) the role of standards, laws and industry adoption in solutions.<br />
* Type of session: presentation (20 mins) followed by Q&A<br />
* Goals: Inform attendees about a full range of on line harms, the risk of unintended consequences when addressing a narrow set in isolation, and the role that a technical standards body can play in improving the web for all.<br />
* Additional speakers/panelists: Alistair Kelman (ali.kelman@safecast.co.uk)<br />
* Apply to be a #Public_Breakout: yes<br />
* Timeslot: Any of 12pmâ5pm UTC.<br />
* Monday, Tuesday, Wednesday<br />
<br />
=== Web Monetization and Grant for the Web ===<br />
* Proposer: [[User:Aspivak|Ali Spivak]]<br />
* Email address of proposer: ali@coil.com, info@grantfortheweb.org<br />
* Summary (one-sentence or so): A deep dive into Grant for the Web's advocacy of the (proposed) Web Monetization standard.<br />
* Type of session: Conversation with opportunity for audience questions.<br />
* Goals: Share Grant for the Web's mission and how early grantees are contributing to the growing Web Monetization ecosystem through use of the (proposed) Web Monetization standard and the Interledger Protocol.<br />
* shortname (used for minting an IRC channel for the breakout) Grant-for-the-Web<br />
* Additional speakers/panelists: Chris Lawrence (Grant for the Web), Ali Spivak (Coil), more participants to be announced.<br />
* Apply to be a #Public_Breakout: yes<br />
* Timeslot: any that are not in conflict with "Revenue Models for the Web" breakout (see above)<br />
<br />
=== The Waning Web Platform Engine Diversity ===<br />
* Proposer: [[User:Chriswilson|Chris Wilson]]<br />
* Email address of proposer: cwilso@google.com<br />
* Summary (one-sentence or so): How should the W3C Process adapt to a world with fewer engine implementers, but more browsers and stakeholders? The open source browser projects are shipping tested, interoperable implementations of new specs well before they reach Recommendation. Horizontal review must happen at the incubation stage or shortly thereafter to have any impact on what browser teams ship. What if anything can the Process do to encourage early engagement by user representatives and horizontal review communities rather than using the PR stage as the checkpoint to ensure this happens? How do we define what web stakeholders should treat as the "real" web standards?<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): open discussion<br />
* Goals: Gather ideas for the future of the W3C Process and incubation process.<br />
* shortname (used for minting an IRC channel for the breakout): engine-scion<br />
* Apply to be a [[#Public_Breakout]]: yes<br />
* Timeslot: 2pm UTC - 6pm UTC<br />
<br />
=== What would it mean for W3C to REALLY prioritize end users? === <br />
* Proposer: [[User:Mchampio2|Michael Champion]] ([[User talk:Mchampio2|talk]]) 01:04, 14 October 2020 (UTC) <br />
* Email address of proposer: michaelc.champion@gmail.com<br />
* Summary : Prioritizing the interests of end users has been a hot topic lately [https://www.rfc-editor.org/rfc/rfc8890.html in IETF], [https://www.w3.org/2001/tag/doc/ethical-web-principles/ in W3C] , and [https://www.eff.org/deeplinks/2020/10/we-fight-users from EFF]. It's not clear what it would CONCRETELY mean for W3C to prioritize the needs of end-users over those of the platform implementers, website developers, "horizontal" specialists, and researchers who make up most of W3C's membership. This breakout will explore the problem of insufficient end-user input into web standards discussions, and seek consensus on ways to address it. See https://github.com/WebStdFuture/Users1st for more context and hopefully pre-meeting and post-meeting discussion. <br />
* Type of session : Open Discussion of https://www.rfc-editor.org/rfc/rfc8890.html and what adopting something similar might mean for W3C<br />
* Goals: Rough consensus whether this is something W3C should do, and what next steps might be<br />
* shortname (used for minting an IRC channel for the breakout): users1st<br />
* [optional] Additional speakers/panelists: Use https://github.com/WebStdFuture/Users1st/issues to request time take a position and request time to present it.<br />
* [optional] Timeslot: 2pm UTC<br />
<br />
=== W3C Group calendaring === <br />
* Proposer: [[User:Jean-gui|Jean-Guilhem Rouel]] <br />
* Email address of proposer: jean-gui@w3.org<br />
* Summary : Providing groups with a good solution to manage their meetings has been requested for a long time. This breakout will consist in a demo of what W3C is currently working on and a discussion to gather initial feedback from interested parties.<br />
* Type of session : Demo/Open Discussion<br />
* Goals: Present and gather feedback on the current state of the project<br />
* shortname (used for minting an IRC channel for the breakout): group-calendaring<br />
* Additional speakers/panelists: Philippe le HĂŠgaret, Vivien Lacourba<br />
* Timeslot: 2pm UTC<br />
* Days in which the breakout can run: Monday, Tuesday, Thurday, Friday<br />
<br />
=== Web of Things (WoT) Applications and Use Cases ===<br />
* Proposer: [[User:Mmccool|Michael McCool]] <br />
* Email address of proposer: michael.mccool@intel.com<br />
* Summary: Update on Web of Things (WoT) progress in extending web standards to IoT, and a showcase for recent applications and use case scenarios from our online plugfest.<br />
* Type of session: 30m presentation, 30m discussion and Q&A.<br />
* Goals: Present recent practical work on applying WoT to specific use-case scenarios, including from our recent plugfest, and to gather feedback on future priorities and use cases.<br />
* Shortname: wot-breakout<br />
* Apply to be a [[#Public_Breakout]] (breakouts open to the world at large, not just the W3C community)<br />
* Timeslot: 1pm UTC (12pm (noon) UTC *might* be acceptable, but would have to be discussed with the rest of the group). Unfortunately, conflicts at 2pm UTC.<br />
** potentially would have a second session at an Asian-friendly time, e.g., 5-7am UTC, but concrete time still needs to be identified.<br />
* Day: Tuesday.<br />
<br />
=== Connected Vehicle Interface Initiative ===<br />
* Proposer: [[User:Ted|Ted Guild]] ([[User talk:Ted|talk]]) 20:34, 16 October 2020 (UTC) <br />
* Email address of proposer: ted@w3.org<br />
* Summary (one-sentence or so): Joint GENIVI / W3C workshop on Connected Vehicle Interface Initiative, summary of current standards, technology stack, past roundtables and stakeholder perspectives.<br />
* Type of session: Workshop<br />
* Goals: Establish wider understanding of standards efforts, refinement and agreement on scope of initiative.<br />
* shortname: CVII<br />
* Additional speakers/panelists: [https://www.w3.org/2020/10/GENIVI_AMM_CVII_Working_Sessions.pdf partial list, will be updated]<br />
* Audience: Restricted to GENIVI and W3C Members plus invitees<br />
* Timeslot: 14-17:30 GMT<br />
* Day: Tuesday<br />
<br />
=== The Responsible Use of Geospatial Data ===<br />
* Proposer: [[User:Eparsons|Ed Parsons]] <br />
* Email address of proposer: eparsons@google.com<br />
* Summary: Progress on developing a framework for the responsible and ethical use of Geospatial tools and data <br />
* Type of session: Open discussion<br />
* Goals: Present and gather feedback on the work so far<br />
* shortname: ResGeo<br />
* Additional speakers/panelists: Joseph Abhayaratnaâ<br />
* Apply to be a [[#Public_Breakout]] Yes<br />
* Timeslot: 2pm UTC<br />
<br />
=== Storage Buckets API ===<br />
* Proposer: [[User:Ayuishii|Ayu Ishii]] <br />
* Email address of proposer: ayui@chromium.org <br />
* Summary: Discussion on Storage Buckets API [https://github.com/WICG/storage-buckets/blob/gh-pages/explainer.md proposal]<br />
* Type of session: Presentation followed by discussion <br />
* Goals: Learn use cases and concerns and reach consensus on proposal<br />
* Shortname: storage-buckets<br />
* Additional speakers/panelists: Victor Costan<br />
* Apply to be a [[#Public_Breakout]]: Yes<br />
* Timeslot: 4pm UTC<br />
* Constraints on days in which the breakout can run: Thursday, Friday<br />
<br />
=== MiniApp Standardization in W3C ===<br />
* Proposer: [[User: Angel Li| Angel Li]] <br />
* Email address of proposer: angelli.laq@alibaba-inc.com<br />
* Summary: Discussion on MiniApp Standardization in W3C <br />
* Type of session: Presentation followed by discussion <br />
* Goals: introduce the current progress of MiniApp specifications incubation, discuss possible cooperation with related groups and collect community feedback on the proposed MiniApp WG charter <br />
* Shortname: MiniApp Standardization<br />
* Apply to be a [[#Public_Breakout]]: Yes<br />
* Timeslot: 2pm UTC<br />
<br />
=== Web Install API ===<br />
* Proposer: [[User:Peconn|Peter Conn]] <br />
* Email address of proposer: peconn@chromium.org<br />
* Summary: Discuss the need, use cases and considerations of a general web install API.<br />
* Type of session: Brief talk followed by an open discussion.<br />
* Goals: Identify appetite and concerns for such an API.<br />
* Shortname: web-install<br />
* Timeslot: 2pm UTC<br />
* Days in which the breakout can run: Monday, Tuesday, Wednesday, Friday<br />
<br />
=== WebID, a federated SignIn API ===<br />
* Proposer: [[User: majidvp| Majid Valipour]]<br />
* Email address of proposer: majidvp@chromium.org<br />
* Summary: Discuss the usecases, requirements and explore solution space for a privacy-preserving federates SignIn API. <br />
* Type of session : Brief talks followed by open discussion / brainstorming <br />
* Goals: Understand current federated sign-in state on the web and brainstorm various ideas on how to make it more privacy-preserving. Present the current thinking and ideas in [https://wicg.github.io/WebID/README.html WebID proposal] and brainstorm solutions.<br />
* Shortname: webid<br />
* Additional speakers/panelists: Samuel Goto, Ken Buchanan<br />
* Apply to be a [[#Public_Breakout]]: Yes<br />
* Timeslot: 2pm UTC<br />
<br />
=== CSS Module Scripts ===<br />
* Proposer: [[User:Daniec|Daniel Clark]] ([[User talk:Daniec|talk]]) 21:01, 16 October 2020 (UTC)<br />
* Email address of proposer: daniec@microsoft.com<br />
* Summary (one-sentence or so): Discuss [https://github.com/w3c/webcomponents/blob/gh-pages/proposals/css-modules-v1-explainer.md CSS Module Scripts] now that they are unblocked by [https://github.com/tc39/proposal-import-assertions Import Assertions]. Confirm positions on the minimal semantics, discuss the status of DocumentOrShadowRoot.adoptedStyleSheets, and potential further steps after initial support, like bundling CSS and exporting other objects from a stylesheet.<br />
* Type of session: Open Discussion.<br />
* Goals: Reach consensus on the minimal semantics and make progress on further directions.<br />
* shortname: components<br />
* Apply to be a #Public_Breakout: yes<br />
* Timeslot: 5pm UTC<br />
<br />
=== Virtual Keyboard Control ===<br />
* Proposer: [[User:Pcupp|Bo Cupp]] ([[User talk:Pcupp|talk]]) 08:18, 17 October 2020 (UTC)<br />
* Email address of proposer: pcupp@microsoft.com<br />
* Summary: Discuss the [https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/VirtualKeyboardAPI/explainer.md Virtual Keyboard API] and [https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/VirtualKeyboardPolicy/explainer.md Virtual Keyboard Policy].<br />
* Type of session: Open Discussion<br />
* Goals: Ensure interested parties understand the proposal, build consensus, and seek collaborators interested in helping author a spec.<br />
* shortname: editing<br />
* Additional speakers/panelists: Anupam Snigdha (snianu@microsoft.com)<br />
* Timeslot: 2pm UTC<br />
* Constraints on days in which the breakout can run: Wednesday, Thursday, Friday<br />
<br />
=== EditContext API ===<br />
* Proposer: [[User:Shihken|Alex Keng]] ([[User talk:Shihken|talk]]) 08:22, 17 October 2020 (UTC)<br />
* Email address of proposer: shihken@microsoft.com<br />
* Summary: Demo and discussion of the [https://w3c.github.io/editing/docs/EditContext/explainer.html EditContext API].<br />
* Type of session: Open Discussion<br />
* Goals: Provide an update on our progress since the introduction of the API at last year's TPAC.<br />
* shortname: editing<br />
* Timeslot: 2pm UTC<br />
* Constraints on days in which the breakout can run: Wednesday, Thursday, Friday<br />
<br />
=== European Publishers Council â Future of the Open Web ===<br />
* Proposer: [[User:Jwrosewell|James Rosewell]] ([[User talk:Jwrosewell|talk]]) 11:03, 18 October 2020 (UTC)<br />
* Email address of proposer: james@51degrees.com<br />
* Summary (one-sentence or so): Phillip Eligio from the [https://www.epceurope.eu/ EPC] will present the high-level summary of their positioning paper on the future of digital include the need for an effective, fair, transparent and privacy-centric identifier and the need for neutral oversight.<br />
* Type of session: talk + Q&A<br />
* Goals: Provide W3C membership and stakeholders with the authoritative position on publishers requirements from the open web.<br />
* shortname: #EPC<br />
* Additional speakers/panelists: Phillip Eligio<br />
* Apply to be a [#Public_Breakout]<br />
* Timeslot: 2pm UTC to 4pm UTC<br />
* Monday, Tuesday, Wednesday<br />
<br />
=== Defining a privacy baseline ===<br />
* Proposer: [[User:Jwrosewell|James Rosewell]] ([[User talk:Jwrosewell|talk]]) 11:03, 18 October 2020 (UTC)<br />
* Email address of proposer: james@51degrees.com<br />
* Summary: Follow on from [https://cryptpad.w3ctag.org/code/#/2/code/edit/4ht9YHtVS9AB4UBlh-oPvHej/ 15th October 2020 PING meeting] a session to debate the need for a privacy baseline definition. If all user agents must appear the same in every way what does this mean for innovation and diversity? If not, what should the comformity baseline be? How are different regional laws assessed to form a global baseline? Does the W3C want or need to create standards that design to, or even exceed, such a legal baseline?<br />
* Type of session: open discussion<br />
* Goals: Understand the gap in participants views on these questions and appetite for defining a privacy a baseline which all W3C members and stakeholders can understand and work to.<br />
* shortname: #privacy-baseline<br />
* Additional speakers/panelists: TBC<br />
* Apply to be a [#Public_Breakout]<br />
* Timeslot: 2pm UTC to 4pm UTC<br />
* Monday, Tuesday, Wednesday<br />
<br />
=== User Agent Client Hints ===<br />
* Proposer: [[User:Jwrosewell|James Rosewell]] ([[User talk:Jwrosewell|talk]]) 11:21, 18 October 2020 (UTC)<br />
* Email address of proposer: james@51degrees.com<br />
* Summary: Opportunity to debate and progress the many [https://github.com/WICG/ua-client-hints/issues open issues] raised in relation to the proposal to introduce [https://github.com/WICG/ua-client-hints client hints for user agent] data and deprecate the HTTP User-Agent field.<br />
* Type of session: Issue debate and resolution<br />
* Goals: Progress resolution of the issues related to the proposal to provide greater clarity to stakeholders.<br />
* shortname: #uach<br />
* Additional speakers/panelists: TBC<br />
* Apply to be a [#Public_Breakout]<br />
* Timeslot: 2pm UTC to 4pm UTC<br />
* Monday, Tuesday, Wednesday<br />
<br />
=== Innovative adaptation, personalization and assistive technologies ===<br />
<br />
* Proposer: [[User:Matkinson|Matthew Atkinson]] ([[User talk:Matkinson|talk]]) 14:38, 18 October 2020 (UTC)<br />
* Email address of proposer: matkinson@paciellogroup.com<br />
* Summary: The world of research has developed a numbers of super-helpful, user-tailored and also fairly transparent adaptations that could help a wide range of people more easily access devices, computers and the web. This session will introduce a few of these, but the primary goal is to discuss them and seek feedback on how we might incorporate them into the web. You can get a flavour of the adaptations at http://matatk.agrip.org.uk/articles/the-promise-of-personalised-interfaces/<br />
* Type of session: short informal talk to introduce a few key adaptations, followed by open discussion.<br />
* Goals: (1) Raise awareness of some ways that interfaces and content can be adapted that can help a wide range of people; (2) Seek ideas as to how these sorts of adaptations could be applied in the context of the web (standards, content, browsers, ...)<br />
* Shortname: TBC<br />
* Additional speakers/panelists: TBC<br />
* Apply to be a #Public_Breakout<br />
* Timeslot: 12pm-5pm UTC<br />
* Days on which the breakout can be run: Monday, Tuesday, Thursday, Friday<br />
<br />
=== Smart Cities ===<br />
* Proposer: [[User:Ashimura|Kazuyuki Ashimura]] ([[User talk:Ashimura|talk]]) 01:49, 19 October 2020 (UTC)<br />
* Email address of proposer: ashimura@w3.org<br />
* Summary (one-sentence or so): Based on the discussion during the [https://www.w3.org/WoT/ws-2019/minutes.html#day2-item02 Second WoT Workshop in Munich], [https://w3c.github.io/wot-usecases/#smart-city use cases on Smart Cities] have been proposed to the Web of Thing IG. However, we need to collect even more use cases and system implmentation experiences of actual smart cities from all over the world, because Smart Cities topic depends on the cities' location, culture, etc., and include various sub-systems from many different vendors. So we'd like to hold discussion on the possible standardization for Smart Cities before forming a concrete discussion group within W3C.<br />
* Type of session: Background description + Open discussion<br />
* Goals:<br />
** identify the stakeholders of Smart Cities standardization to drive the development of Web standards aligned with the real needs of Smart Cities<br />
** and then discuss how to proceed including the possibility of holding a dedicated Workshop and forming a dedicated IG<br />
* shortname: smart-cities<br />
* [optional] Additional speakers/panelists: tbd<br />
* [optional] Apply to be a [[#Public_Breakout]] (breakouts open to the world at large, not just the W3C community)=== Smart Cities ===<br />
* Proposer: [[User:Ashimura|Kazuyuki Ashimura]] ([[User talk:Ashimura|talk]]) 01:52, 19 October 2020 (UTC)<br />
* Email address of proposer: ashimura@w3.org<br />
* Summary (one-sentence or so): Based on the discussion during the [https://www.w3.org/WoT/ws-2019/minutes.html#day2-item02 Second WoT Workshop in Munich], [https://w3c.github.io/wot-usecases/#smart-city use cases on Smart Cities] have been proposed to the Web of Thing IG. However, we need to collect even more use cases and system implmentation experiences of actual smart cities from all over the world, because Smart Cities topic depends on the cities' location, culture, etc., and include various sub-systems from many different vendors. So we'd like to hold discussion on the possible standardization for Smart Cities before forming a concrete discussion group within W3C.<br />
* Type of session: Background description + Open discussion<br />
* Goals:<br />
** identify the stakeholders of Smart Cities standardization to drive the development of Web standards aligned with the real needs of Smart Cities<br />
** and then discuss how to proceed including the possibility of holding a dedicated Workshop and forming a dedicated IG<br />
* shortname: smart-cities<br />
* [optional] Additional speakers/panelists: tbd<br />
* [optional] Apply to be a [[#Public_Breakout]] (breakouts open to the world at large, not just the W3C community)<br />
* [optional] Timeslot: 12pm-4pm UTC (but need to avoid conflicts with the related sessions, e.g., [https://www.w3.org/wiki/TPAC/2020/SessionIdeas#Web_of_Things_.28WoT.29_Applications_and_Use_Cases WoT Applications and Use Cases], [https://www.w3.org/wiki/TPAC/2020/SessionIdeas#Video_Metadata_For_Moving_Objects_.26_Sensors_On_The_Web_.28WebVMT.29 Video metadata] and [https://www.w3.org/wiki/TPAC/2020/SessionIdeas#Voice_Agents Voice Agents]) - Detail on preferred date/time below<br />
** Monday, 12pm-1pm UTC<br />
** Monday, 2pm-3pm UTC<br />
** Tuesday, 12pm-1pm UTC<br />
** Tuesday, 2pm-3pm UTC<br />
** Thursday, 2pm-3pm UTC<br />
** Friday, 12pm-1pm UTC<br />
** Friday, 1pm-2pm UTC<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Thursday, Friday<br />
<br />
* [optional] Timeslot: 12pm-4pm UTC (but need to avoid conflicts with the related sessions, e.g., [https://www.w3.org/wiki/TPAC/2020/SessionIdeas#Web_of_Things_.28WoT.29_Applications_and_Use_Cases WoT Applications and Use Cases], [https://www.w3.org/wiki/TPAC/2020/SessionIdeas#Video_Metadata_For_Moving_Objects_.26_Sensors_On_The_Web_.28WebVMT.29 Video metadata] and [https://www.w3.org/wiki/TPAC/2020/SessionIdeas#Voice_Agents Voice Agents]) - Detail on preferred date/time below<br />
** Monday, 12pm-1pm UTC<br />
** Monday, 2pm-3pm UTC<br />
** Tuesday, 12pm-1pm UTC<br />
** Tuesday, 2pm-3pm UTC<br />
** Thursday, 2pm-3pm UTC<br />
** Friday, 12pm-1pm UTC<br />
** Friday, 1pm-2pm UTC<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Thursday, Friday<br />
<br />
=== Voice Agents ===<br />
* Proposer: [[User:Ashimura|Kazuyuki Ashimura]] ([[User talk:Ashimura|talk]]) 01:52, 19 October 2020 (UTC)<br />
* Email address of proposer: ashimura@w3.org<br />
* Summary (one-sentence or so): During [https://www.w3.org/2019/09/18-voice-minutes.html one of the breakout sessions at TPAC 2019] in Fukuoka, there was discusison about needs for improved voice agents for web services. And we'd like to proceed with the preparation for the expectd [W3C Workshop on User-friendly Smart Agents on the Web](https://github.com/w3c/strategy/issues/221)<br />
* Type of session: Background description + Open discussion<br />
* Goals:<br />
** identify people interested as (1) the expected Program Committee for the workshop and (2) participants in the workshop<br />
** also would get insights for the potential agenda for the expected workshop<br />
* shortname: voice-agents<br />
* [optional] Additional speakers/panelists: tbd<br />
* [optional] Apply to be a [[#Public_Breakout]] (breakouts open to the world at large, not just the W3C community)<br />
* [optional] Timeslot: 12pm-4pm UTC (but need to avoid conflicts with the related sessions, e.g., [https://www.w3.org/wiki/TPAC/2020/SessionIdeas#Web_of_Things_.28WoT.29_Applications_and_Use_Cases WoT Applications and Use Cases], [https://www.w3.org/wiki/TPAC/2020/SessionIdeas#Video_Metadata_For_Moving_Objects_.26_Sensors_On_The_Web_.28WebVMT.29 Video metadata] and [https://www.w3.org/wiki/TPAC/2020/SessionIdeas#Smart_Cities Smart Cities]) - Detail on preferred date/time below<br />
** Monday, 12pm-1pm UTC<br />
** Monday, 2pm-3pm UTC<br />
** Tuesday, 12pm-1pm UTC<br />
** Tuesday, 2pm-3pm UTC<br />
** Thursday, 2pm-3pm UTC<br />
** Friday, 12pm-1pm UTC<br />
** Friday, 1pm-2pm UTC<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Thursday, Friday<br />
<br />
=== Cloud Gaming on the Web ===<br />
* Proposer: [[User:Lzm|Zhaoming Li]] ([[User talk:Lzm|talk]]) 08:10, 19 October 2020 (UTC)<br />
* Email address of proposer: lizhaoming@tingyutech.com<br />
* Summary: This session will include a basic introduction about cloud gaming, why cloud gaming is powerful, how cloud gaming run on the web, how can the web help cloud gaming, and shortages we currently have on the browser.<br />
* Type of session: talk and open discussion<br />
* Goals: We are looking to start a community group to work on providing a fast and stable user experience of cloud gaming.<br />
* shortname: cloudgaming<br />
* Additional speakers/panelists: Qingqian Tao, Alicia Nie<br />
<br />
=== W3C 2020: Living Standards and Reviews ===<br />
<br />
* Proposer: [[User:Plehegar|PLH]] <br />
* Email address of proposer: plh@w3.org<br />
* Summary: This session will decrypt the new W3C Process to helps editors and participants find their ways. It will also give the latest information on how to do wide reviews and transitions.<br />
* Type of session: talk and open discussion<br />
* Goals: Avoid getting lost into the W3C Process maze.<br />
* shortname: w3cprocess<br />
* Additional speakers/panelists: none</div>Plehegarhttps://www.w3.org/wiki/index.php?title=TPAC/2020/SessionIdeas&diff=112671TPAC/2020/SessionIdeas2020-10-19T12:33:55Z<p>Plehegar: Fixed proposer</p>
<hr />
<div>You are invited to propose [https://www.w3.org/2020/10/TPAC/ TPAC 2020] '''TPAC Breakout week (October 26-30)''' sessions in advance of the meeting. <br />
See the [[TPAC/2020/FAQ | TPAC 2020 FAQ]] for more information. Please contact dom@w3.org for any question regarding the organization of TPAC breakouts.<br />
<br />
<div style="float:right;clear:right">__TOC__</div><br />
<br />
== How to use this page ==<br />
<br />
Please use this page to:<br />
<br />
* Propose sessions you wish to lead<br />
* '''Please place new proposals at the bottom of this document'''<br />
<br />
== How to propose a session ==<br />
<br />
Please provide:<br />
<ul class="show_items"><br />
* session name (as a === subhead === )<br />
* session proposer (yourself, if so sign using 4 tildes; optional: name a desired session leader) and an email address<br />
* one sentence session summary<br />
* type of session: (e.g.: open discussion, talk, panel, tutorial, demo, etc.)<br />
* goals of session<br />
* additional speakers/panelists (to help reduce conflicts when one person is needed in more than one place)<br />
* opt-in to be a [[#Public_Breakout]] open to participation from the public at large<br />
* a shortname that can be used to associate an IRC or Slack channel to your breakout<br />
* by default, we expect breakout to happen at 2pm UTC for '''one hour''' during the week of October 26 to allow participation from as many timezones as possible; if your breakout cannot happen at 2pm UTC, or if your breakout can be scheduled to happen across multiple repeated instances at different time (e.g. for a tutorial, demos), please indicate it<br />
** single instance TPAC breakout sessions proposed outside of the 2pm slot are subject to validation by the organizing committee<br />
* if your breakout needs to happen on a subset of the 5 days of the week, please also indicate it<br />
</ul><br />
<br />
== Public Breakout ==<br />
<br />
In addition to the usual breakout discussions organized for the traditional TPAC community (IG/WG participants, W3C member representatives), we are trying something new this year. We plan to open a set of breakouts to the broader public, in an effort to bring more diverse voices into the W3C community. We feel this is necessary to ensure the fullest range of users and perspectives is represented and encoded in our web standards. <br />
<br />
Breakout proposers are invited to opt-in to make their breakout open to the public in order to invite a wider and more diverse set. While there aren't clearly defined limits to what topics would benefit from this, we encourage Public Breakouts to focus on use cases or ergonomics of a technology, and to provide upfront onboarding and context for any breakouts that include deep technical dive.<br />
<br />
The W3C devrel team and their partners will work with Public Breakout proposers to ensure their breakouts are as welcoming and kind as possible when joining their first W3C or Web standardization discussion. For anyone who opts in to propose a Public Breakout , we will be offering dedicated training sessions the week before TPAC breakouts on the topic of facilitating accessible discussions.<br />
<br />
(Many thanks to Boaz Sender, Sheila Moussavi, Jory Burson, Laura Lee McCarthy who have been working with Marie-Claire Forgue and Dominique Hazael-Massieux in setting this up)<br />
<br />
== Proposed sessions ==<br />
<br />
=== EXAMPLE session with session name ===<br />
* Proposer: <nowiki>~~~~</nowiki> (Instruction: remove <nowiki><nowiki> and </nowiki></nowiki> around the tildas. Explanation: The 4 tildas will sign YOUR name and include a timestamp of your proposal.)<br />
* Email address of proposer: <br />
* Summary (one-sentence or so): <br />
* Type of session (e.g.: open discussion, talk, panel, etc.): <br />
* Goals:<br />
* shortname (used for minting an IRC channel for the breakout)<br />
* [optional] Additional speakers/panelists:<br />
* [optional] Apply to be a [[#Public_Breakout]] (breakouts open to the world at large, not just the W3C community)<br />
* [optional] Timeslot: 2pm UTC ("the golden hour" - 7am US West Coast, 11pm Japan) - if you can't run your breakout proposal at 2pm UTC, we ask that you consider carefully alternatives in the 12pm-5pm UTC, knowing that a number of people won't be able to make it; alternatively, if your breakout can happen as a repeated instance (e.g. for a tutorial or a demo), please indicate so and we will schedule these instances away from the golden hour<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Wednesday, Thursday, Friday<br />
<br />
=== IAB Europe's Transparency and Control Framework ===<br />
* Proposer: [[User:Benhum|Ben Humphry]] <br />
* Email address of proposer: humphry@iabeurope.eu<br />
* Summary (one-sentence or so): Internet Advertising Bureau (IAB) Europe to brief W3C members on Transparency and Consent Framework (TCF), developed over many years to capture peopleâs consent choices and inform multiple parties. [https://github.com/w3c/web-advertising/issues/86/ Web-Advertising Github Issue]<br />
* Type of session: talk and open discussion<br />
* Goals: Explain this existing framework which provides consumers with a transparent and fair mechanism for control of their privacy preferences.<br />
* shortname: TCF<br />
* Additional speakers/panelists: TBD - Experts from IAB Europe<br />
* Apply to be a [[#Public_Breakout]]: yes<br />
* Timeslot: Any of 12pmâ5pm UTC.<br />
<br />
=== MDN Developer Need Assessments: results and next steps ===<br />
* Proposer: [[User:Dom|Dominique HazaĂŤl-Massieux]] <br />
* Email address of proposer: dom@w3.org<br />
* Summary (one-sentence or so): Review outcome of the [https://insights.developer.mozilla.org/ MDN DNA survey 2019], incl recently released [https://mdn-web-dna.s3-us-west-2.amazonaws.com/MDN-Browser-Compatibility-Report-2020.pdf MDN Browser Compat Report] and expectations on MDN DNA Survey 2020<br />
* Type of session: talk and open discussion<br />
* Goals: Inform how large-scale developer input has impacted and should impact standardization priorities<br />
* shortname: mdn-dna<br />
* Additional speakers/panelists: Philip Jägenstedt, Robert Nyman, Chris Mills, Boaz Sender<br />
* Apply to be a [[#Public_Breakout]]: yes<br />
<br />
=== Learning from Mini Apps ===<br />
* Proposer: [[User:Tsteiner|Thomas Steiner]] <br />
* Email address of proposer: tomac@google.com<br />
* Summary: In this breakout session, I will first explain what mini apps are and how to build them, and then move on to an open discussion focused on what Web developers can learn from mini apps and their developer experience. <br />
* Type of session: Talk followed by discussion.<br />
* Goals: Having a better understanding of mini apps.<br />
* Shortname: miniappslearnings<br />
* [optional] Additional speakers/panelists: You?<br />
* [optional] Apply to be a [[#Public_Breakout]]: Yes.<br />
* [optional] Timeslot: Any of 12pmâ5pm UTC.<br />
* [optional] Constraints on days in which the breakout can run: No constraints.<br />
<br />
=== Web Packaging ===<br />
* Proposer: [[User:Jyasskin|Jeffrey Yasskin]] <br />
* Email address of proposer: jyasskin@google.com<br />
* Summary (one-sentence or so): Discuss Web Packaging issues that [https://github.com/WICG/webpackage/issues?q=is%3Aopen+is%3Aissue+label%3Adiscuss need discussion].<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Open Discussion<br />
* Goals: Resolve or make progress on some open issues with the web packaging design<br />
* Shortname: web-packaging<br />
* [optional] Additional speakers/panelists:<br />
* [optional] Apply to be a [[#Public_Breakout]]: yes<br />
* [optional] Timeslot: 2pm UTC<br />
* [optional] constraints on days in which the breakout can run: No constraints.<br />
<br />
=== Memory copies & zero-copy operations on the Web ===<br />
* Proposer: [[User:Fd|François Daoust]] <br />
* Email address of proposer: fd@w3.org<br />
* Summary (one-sentence or so): In scenarios such as real-time processing of media frames with ML algorithms, memory copies made along the processing pipeline may account for a non negligible part of the overall performance budget of the said processing. See [https://github.com/w3c/machine-learning-workshop/issues/93 Memory copies discussion in the Web and Machine Learning workshop] for context. Could the Web do better?<br />
* Type of session: Open discussion<br />
* Goals: Explore needs to copy memory in various Web technologies (JS, WebAssembly, WebGPU, Machine Learning, WebRTC, Media) and identify possible architectural updates to the Web Platform that could help reduce unneeded memory copies.<br />
* shortname: zerocopy<br />
* Timeslot: 2pm UTC<br />
<br />
=== Video Metadata For Moving Objects &amp; Sensors On The Web (WebVMT) ===<br />
* Proposer: [[User:Rjksmith|Rob Smith]] <br />
* Email address of proposer: rob.smith@awayteam.co.uk<br />
* Summary: Emerging markets in 'mobile video devices' such as dashcams, drones, body-worn video and smartphones are increasing consumer demand for geotagged video on the web and especially with access to moving objects, e.g. distance &amp; speed for vehicles, and sensor data, e.g. heart rate for fitness users. More details at [https://github.com/w3c/sdw/issues/1194 w3c/sdw #1194]<br />
* Type of session: Short talk followed by discussion<br />
* Goals: Identify properties of moving objects &amp; sensors required in a web API to access timed video metadata exported for the web, i.e. WebVMT, from mobile video devices.<br />
* Shortname video-location<br />
* Apply to be a [[#Public_Breakout]]<br />
* Timeslot: 2pm UTC<br />
<br />
=== Improve definition of parties and trust relationships across W3C ===<br />
* Proposer: [[User:Jwrosewell|James Rosewell]] <br />
* Email address of proposer: james@51degrees.com<br />
* Summary (one-sentence or so): First and third party are poorly defined and lack the granularity to resolve many of the problems W3C are working on. Debate definitions of parties considering their relationship with one another, trust, choice, scale and varying conditions in relation to people. See IWA BG issue for commentary and pre session discussion. [https://github.com/w3c/web-advertising/issues/87]<br />
* Type of session: Presentations followed by discussion<br />
* Goals: Agreement on approach to define parties consistently and appropriately across W3C including TAG and PING documents.<br />
* shortname: party-time<br />
* Speakers/panelists: TBD â would like to add advocates for different view points.<br />
* Apply to be a [[#Public_Breakout]] (as a minimum should include Improving Web Advertising Business Group members)<br />
* Timeslot: 2pm to 4pm UTC<br />
* Monday, Tuesday, Wednesday<br />
<br />
=== Web Components ===<br />
* Proposer: [[User:rniwa|Ryosuke Niwa]] <br />
* Email address of proposer: rniwa at apple<br />
* Summary (one-sentence or so): Discussion of various topics related to web components<br />
* Type of session: Multi-topic discussion; Agenda and logistics is tracked at https://github.com/w3c/webcomponents/issues/877<br />
* Goals: Reaching consensus on various topics<br />
* shortname: components<br />
* Apply to be a #Public_Breakout: yes<br />
* Timeslot: 5pm UTC<br />
<br />
=== Parts and Template Instantiation ===<br />
* Proposer: [[User:rniwa|Ryosuke Niwa]] <br />
* Email address of proposer: rniwa at apple<br />
* Summary (one-sentence or so): Discussion of APIs to help instantiate templates.<br />
* Type of session: A presentation followed by discussion<br />
* Goals: Make progress on the proposal and reach some consensus on minimal viable product.<br />
* shortname: components<br />
* Apply to be a #Public_Breakout: yes<br />
* Timeslot: 5pm UTC<br />
<br />
=== Declarative Shadow DOM ===<br />
* Proposer: [[User:mfreed|Mason Freed]] <br />
* Email address of proposer: masonfreed@chromium.org<br />
* Summary (one-sentence or so): Discussion of the declarative Shadow DOM [https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md proposal]/[https://github.com/whatwg/dom/issues/831 issue]<br />
* Type of session: A presentation followed by discussion.<br />
* Goals: Reach some consensus on the proposal and spec.<br />
* shortname: components<br />
* Apply to be a #Public_Breakout: yes<br />
* Timeslot: 5pm UTC<br />
<br />
=== Making math a first class citizen on the Web ===<br />
* Proposer: [[User:Nsoiffer2|Neil Soiffer]] <br />
* Email address of proposer: neil.soiffer@gmail.com<br />
* Summary: The MathML Refresh CG is forming a WG and we would like to discuss our [https://mathml-refresh.github.io/charter-drafts/math-2020.html proposed charter] with interested parties. The group has coordinated with the CSS WG, WhatWG, and TAG over some issues and there are many remaining open questions involving Shadow DOM, Houdini, Links, the accessibility tree, search and other parts of the Web platform.<br />
* Type of session: open discussion<br />
* Goals: Provoke discussions on some of the subtle issues of including math in the Web platform and get guidance on resolving them.<br />
* shortname: math<br />
* Additional speakers/panelists: Brian Karkell (bkardell@gmail.com)<br />
* Apply to be a [[#Public_Breakout]]: yes<br />
* Timeslot: 3:00pm UTC<br />
<br />
=== All your spec are belong to us - irrigating dev resources from specs ===<br />
* Proposer: [[User:Dom|Dominique HazaÍl-Massieux]], [[User:Fd|François Daoust]]<br />
* Email address of proposer: dom@w3.org, fd@w3.org<br />
* Summary: Machines read specs too. This breakout session will review existing and possible tools and projects that make use of content automatically extracted from specs.<br />
* Type of session: Talk and open discussion<br />
* Goals: Raise awareness and learn about existing internal and external projects (such as webref, Bikeshed, Respec, MDN, Visual Studio, Web Platform Tests) that depend on content extracted from specs, to irrigate CSS/IDL tests and interface headers in browser codebases, validate cross-references, enrich IDE tools, identify dependencies, detect anomalies, and otherwise improve the quality of the specifications. Clarify what happens when e.g. IDL content is no longer valid or machine-readable. Discuss usage scenarios that additional formalism for writing specs could perhaps enable.<br />
* shortname: specmining<br />
* Apply to be a [[#Public_Breakout]]<br />
<br />
=== Maps for HTML Community Group ===<br />
* Proposer: [[User:Prushfor|Peter Rushforth]] <br />
* Email address of proposer: peter.rushforth@canada.ca<br />
* Summary: The Maps for HTML community recently concluded a successful [https://www.w3.org/2020/maps/agenda#day-1 workshop] about standardizing maps for the Web platform, and we would like to invite those interested to take part in a follow up meeting.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Summary presentation of workshop, followed by open discussion.<br />
* Goals: Provide and receive information on specific topics<br />
* shortname: maps4html (used for minting an IRC channel for the breakout)<br />
* Apply to be a [[#Public_Breakout]]: yes<br />
* Timeslot: 2pm UTC<br />
<br />
=== EPUB 3 History and Future ===<br />
* Proposer: [[User:Tzviya|Tzviya Siegman]] Tzviya Siegman and Wendy Reid <br />
* Email address of proposer: tsiegman@wiley.com<br />
* Summary (one-sentence or so): Learn about the 20+ year history of EPUB, how it came to the W3C, and what the new EPUB 3 WG will accomplish. <br />
* Type of session: talk with time for questions <br />
* Goals: Provide info about EPUB and Publishing Activity<br />
* shortname EPUB3<br />
* [optional] Additional speakers/panelists: Wendy Reid and (possibly) Shinya Takami<br />
* [optional] Apply to be a [[#Public_Breakout]]: yes<br />
<br />
=== Delegated Ink Trails ===<br />
* Proposer: [[User:Mabian|Mario Bianucci]] <br />
* Email address of proposer: mabian@microsoft.com<br />
* Summary: Delegated Ink Trail Presentation Paradigm: Prototype status and learnings from web developers feedback.<br />
* Type of session: open discussion<br />
* Goals: Discuss the proposed paradigm, and reach consensus on next steps.<br />
* shortname: delegated_ink_trail<br />
* Apply to be a [[#Public_Breakout]]: yes.<br />
* Timeslot: 2pm UTC<br />
* constraints on days in which the breakout can run: Tuesday, Wednesday, Thursday, Friday<br />
<br />
=== W3C New York Metro Chapter Meetup ===<br />
* Proposer: Rachel Yager <br />
* Email address of proposer: rachel@fortunetimesgroup.com / ryager@w3.org<br />
* Summary (one-sentence or so): Inviting Web Community to Join the W3C New York Metro Chapter. W3C Members and Non-Members are Welcome! The Chapter provides a point of presence of W3C within the Metropolitan New York City to build and enhance the Web Community, to assist W3C Members, and to invite W3C Members participation in WebInnovationX Center for World Wide Web research and education initiatives.<br />
* Type of session: Seminar Talks and Presentations<br />
* Goals: Provide information on W3C NY Metro Chapter Member Benefits, Activities, Events, Strategic Partnership, Leadership, and Technology Innovation Initiatives.<br />
* shortname: WebInnovationX<br />
* Additional speakers/panelists: TBD<br />
* Apply to be a [[#Public_Breakout]]: yes<br />
* Timeslot: 4pm UTC<br />
* constraints on days in which the breakout can run: Wednesday<br />
<br />
=== Media Publishers of the Web, Unite! ===<br />
* Proposer: [[User:Rberjon|Robin Berjon]] <br />
* Email address of proposer: robin.berjon@nytimes.com<br />
* Summary (one-sentence or so): Media publishers have long been absent or under-represented in Web standards, but there is a growing sense that we should speak up in the making of tech and a growing set of members. This session is to share fears, hopes, tips, and more.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): <br />
* Goals: Get media publishers to meet and help each other out navigate the strange but beautiful world of standards.<br />
* shortname (used for minting an IRC channel for the breakout): media-pubs<br />
* Apply to be a [[#Public_Breakout]]: yeah<br />
* Timeslot: 2pm UTC<br />
<br />
=== Revenue Models for the Web ===<br />
* Proposer: [[User:Ahopebai|Adrian Hope-Bailie]] <br />
* Email address of proposer: Ali Spivak (ali@coil.com) and Adrian Hope-Bailie (adrian@coil.com)<br />
* Summary (one-sentence or so): There has been a lot of discussion and [[https://webmonetization.org experimentation]] looking at alternatives to advertising for monetization on the Web. In this panel we aim to explore these alternative models, debate whether or not advertising still has a role to play, and discuss the potential for standards to enable a broader set of business models.<br />
* Type of session: Panel followed by open discussion<br />
* Goals: Discuss options for generating revenue on the Web and how standards can enable more options.<br />
* shortname (used for minting an IRC channel for the breakout): monetization<br />
* Additional speakers/panelists: Panel currently being confirmed. Please email the proposers if you wish to join the panel.<br />
* Apply to be a [[#Public_Breakout]]: YES<br />
* Timeslot: 2pm UTC ("the golden hour" - 7am US West Coast, 11pm Japan)<br />
<br />
=== Online Harms â a European and UK perspective ===<br />
* Proposer: [[User:Jwrosewell|James Rosewell]] <br />
* Email address of proposer: james@51degrees.com<br />
* Summary (one-sentence or so): Presentation to cover a) the current state of online harm legislation in the UK and Europe including the Audio-Visual Media Services Directive (AVMS-D) on 1st November 2020; * b) child safety and the impact DNS over HTTPs is having; and c) the role of standards, laws and industry adoption in solutions.<br />
* Type of session: presentation (20 mins) followed by Q&A<br />
* Goals: Inform attendees about a full range of on line harms, the risk of unintended consequences when addressing a narrow set in isolation, and the role that a technical standards body can play in improving the web for all.<br />
* Additional speakers/panelists: Alistair Kelman (ali.kelman@safecast.co.uk)<br />
* Apply to be a #Public_Breakout: yes<br />
* Timeslot: Any of 12pmâ5pm UTC.<br />
* Monday, Tuesday, Wednesday<br />
<br />
=== Web Monetization and Grant for the Web ===<br />
* Proposer: [[User:Aspivak|Ali Spivak]]<br />
* Email address of proposer: ali@coil.com, info@grantfortheweb.org<br />
* Summary (one-sentence or so): A deep dive into Grant for the Web's advocacy of the (proposed) Web Monetization standard.<br />
* Type of session: Conversation with opportunity for audience questions.<br />
* Goals: Share Grant for the Web's mission and how early grantees are contributing to the growing Web Monetization ecosystem through use of the (proposed) Web Monetization standard and the Interledger Protocol.<br />
* shortname (used for minting an IRC channel for the breakout) Grant-for-the-Web<br />
* Additional speakers/panelists: Chris Lawrence (Grant for the Web), Ali Spivak (Coil), more participants to be announced.<br />
* Apply to be a #Public_Breakout: yes<br />
* Timeslot: any that are not in conflict with "Revenue Models for the Web" breakout (see above)<br />
<br />
=== The Waning Web Platform Engine Diversity ===<br />
* Proposer: [[User:Chriswilson|Chris Wilson]]<br />
* Email address of proposer: cwilso@google.com<br />
* Summary (one-sentence or so): How should the W3C Process adapt to a world with fewer engine implementers, but more browsers and stakeholders? The open source browser projects are shipping tested, interoperable implementations of new specs well before they reach Recommendation. Horizontal review must happen at the incubation stage or shortly thereafter to have any impact on what browser teams ship. What if anything can the Process do to encourage early engagement by user representatives and horizontal review communities rather than using the PR stage as the checkpoint to ensure this happens? How do we define what web stakeholders should treat as the "real" web standards?<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): open discussion<br />
* Goals: Gather ideas for the future of the W3C Process and incubation process.<br />
* shortname (used for minting an IRC channel for the breakout): engine-scion<br />
* Apply to be a [[#Public_Breakout]]: yes<br />
* Timeslot: 2pm UTC - 6pm UTC<br />
<br />
=== What would it mean for W3C to REALLY prioritize end users? === <br />
* Proposer: [[User:Mchampio2|Michael Champion]] ([[User talk:Mchampio2|talk]]) 01:04, 14 October 2020 (UTC) <br />
* Email address of proposer: michaelc.champion@gmail.com<br />
* Summary : Prioritizing the interests of end users has been a hot topic lately [https://www.rfc-editor.org/rfc/rfc8890.html in IETF], [https://www.w3.org/2001/tag/doc/ethical-web-principles/ in W3C] , and [https://www.eff.org/deeplinks/2020/10/we-fight-users from EFF]. It's not clear what it would CONCRETELY mean for W3C to prioritize the needs of end-users over those of the platform implementers, website developers, "horizontal" specialists, and researchers who make up most of W3C's membership. This breakout will explore the problem of insufficient end-user input into web standards discussions, and seek consensus on ways to address it. See https://github.com/WebStdFuture/Users1st for more context and hopefully pre-meeting and post-meeting discussion. <br />
* Type of session : Open Discussion of https://www.rfc-editor.org/rfc/rfc8890.html and what adopting something similar might mean for W3C<br />
* Goals: Rough consensus whether this is something W3C should do, and what next steps might be<br />
* shortname (used for minting an IRC channel for the breakout): users1st<br />
* [optional] Additional speakers/panelists: Use https://github.com/WebStdFuture/Users1st/issues to request time take a position and request time to present it.<br />
* [optional] Timeslot: 2pm UTC<br />
<br />
=== W3C Group calendaring === <br />
* Proposer: [[User:Jean-gui|Jean-Guilhem Rouel]] <br />
* Email address of proposer: jean-gui@w3.org<br />
* Summary : Providing groups with a good solution to manage their meetings has been requested for a long time. This breakout will consist in a demo of what W3C is currently working on and a discussion to gather initial feedback from interested parties.<br />
* Type of session : Demo/Open Discussion<br />
* Goals: Present and gather feedback on the current state of the project<br />
* shortname (used for minting an IRC channel for the breakout): group-calendaring<br />
* Additional speakers/panelists: Philippe le HĂŠgaret, Vivien Lacourba<br />
* Timeslot: 2pm UTC<br />
* Days in which the breakout can run: Monday, Tuesday, Thurday, Friday<br />
<br />
=== Web of Things (WoT) Applications and Use Cases ===<br />
* Proposer: [[User:Mmccool|Michael McCool]] <br />
* Email address of proposer: michael.mccool@intel.com<br />
* Summary: Update on Web of Things (WoT) progress in extending web standards to IoT, and a showcase for recent applications and use case scenarios from our online plugfest.<br />
* Type of session: 30m presentation, 30m discussion and Q&A.<br />
* Goals: Present recent practical work on applying WoT to specific use-case scenarios, including from our recent plugfest, and to gather feedback on future priorities and use cases.<br />
* Shortname: wot-breakout<br />
* Apply to be a [[#Public_Breakout]] (breakouts open to the world at large, not just the W3C community)<br />
* Timeslot: 1pm UTC (12pm (noon) UTC *might* be acceptable, but would have to be discussed with the rest of the group). Unfortunately, conflicts at 2pm UTC.<br />
** potentially would have a second session at an Asian-friendly time, e.g., 5-7am UTC, but concrete time still needs to be identified.<br />
* Day: Tuesday.<br />
<br />
=== Connected Vehicle Interface Initiative ===<br />
* Proposer: [[User:Ted|Ted Guild]] ([[User talk:Ted|talk]]) 20:34, 16 October 2020 (UTC) <br />
* Email address of proposer: ted@w3.org<br />
* Summary (one-sentence or so): Joint GENIVI / W3C workshop on Connected Vehicle Interface Initiative, summary of current standards, technology stack, past roundtables and stakeholder perspectives.<br />
* Type of session: Workshop<br />
* Goals: Establish wider understanding of standards efforts, refinement and agreement on scope of initiative.<br />
* shortname: CVII<br />
* Additional speakers/panelists: [https://www.w3.org/2020/10/GENIVI_AMM_CVII_Working_Sessions.pdf partial list, will be updated]<br />
* Audience: Restricted to GENIVI and W3C Members plus invitees<br />
* Timeslot: 14-17:30 GMT<br />
* Day: Tuesday<br />
<br />
=== The Responsible Use of Geospatial Data ===<br />
* Proposer: [[User:Eparsons|Ed Parsons]] <br />
* Email address of proposer: eparsons@google.com<br />
* Summary: Progress on developing a framework for the responsible and ethical use of Geospatial tools and data <br />
* Type of session: Open discussion<br />
* Goals: Present and gather feedback on the work so far<br />
* shortname: ResGeo<br />
* Additional speakers/panelists: Joseph Abhayaratnaâ<br />
* Apply to be a [[#Public_Breakout]] Yes<br />
* Timeslot: 2pm UTC<br />
<br />
=== Storage Buckets API ===<br />
* Proposer: [[User:Ayuishii|Ayu Ishii]] <br />
* Email address of proposer: ayui@chromium.org <br />
* Summary: Discussion on Storage Buckets API [https://github.com/WICG/storage-buckets/blob/gh-pages/explainer.md proposal]<br />
* Type of session: Presentation followed by discussion <br />
* Goals: Learn use cases and concerns and reach consensus on proposal<br />
* Shortname: storage-buckets<br />
* Additional speakers/panelists: Victor Costan<br />
* Apply to be a [[#Public_Breakout]]: Yes<br />
* Timeslot: 4pm UTC<br />
* Constraints on days in which the breakout can run: Thursday, Friday<br />
<br />
=== MiniApp Standardization in W3C ===<br />
* Proposer: [[User: Angel Li| Angel Li]] <br />
* Email address of proposer: angelli.laq@alibaba-inc.com<br />
* Summary: Discussion on MiniApp Standardization in W3C <br />
* Type of session: Presentation followed by discussion <br />
* Goals: introduce the current progress of MiniApp specifications incubation, discuss possible cooperation with related groups and collect community feedback on the proposed MiniApp WG charter <br />
* Shortname: MiniApp Standardization<br />
* Apply to be a [[#Public_Breakout]]: Yes<br />
* Timeslot: 2pm UTC<br />
<br />
=== Web Install API ===<br />
* Proposer: [[User:Peconn|Peter Conn]] <br />
* Email address of proposer: peconn@chromium.org<br />
* Summary: Discuss the need, use cases and considerations of a general web install API.<br />
* Type of session: Brief talk followed by an open discussion.<br />
* Goals: Identify appetite and concerns for such an API.<br />
* Shortname: web-install<br />
* Timeslot: 2pm UTC<br />
* Days in which the breakout can run: Monday, Tuesday, Wednesday, Friday<br />
<br />
=== WebID, a federated SignIn API ===<br />
* Proposer: [[User: majidvp| Majid Valipour]]<br />
* Email address of proposer: majidvp@chromium.org<br />
* Summary: Discuss the usecases, requirements and explore solution space for a privacy-preserving federates SignIn API. <br />
* Type of session : Brief talks followed by open discussion / brainstorming <br />
* Goals: Understand current federated sign-in state on the web and brainstorm various ideas on how to make it more privacy-preserving. Present the current thinking and ideas in [https://wicg.github.io/WebID/README.html WebID proposal] and brainstorm solutions.<br />
* Shortname: webid<br />
* Additional speakers/panelists: Samuel Goto, Ken Buchanan<br />
* Apply to be a [[#Public_Breakout]]: Yes<br />
* Timeslot: 2pm UTC<br />
<br />
=== CSS Module Scripts ===<br />
* Proposer: [[User:Daniec|Daniel Clark]] ([[User talk:Daniec|talk]]) 21:01, 16 October 2020 (UTC)<br />
* Email address of proposer: daniec@microsoft.com<br />
* Summary (one-sentence or so): Discuss [https://github.com/w3c/webcomponents/blob/gh-pages/proposals/css-modules-v1-explainer.md CSS Module Scripts] now that they are unblocked by [https://github.com/tc39/proposal-import-assertions Import Assertions]. Confirm positions on the minimal semantics, discuss the status of DocumentOrShadowRoot.adoptedStyleSheets, and potential further steps after initial support, like bundling CSS and exporting other objects from a stylesheet.<br />
* Type of session: Open Discussion.<br />
* Goals: Reach consensus on the minimal semantics and make progress on further directions.<br />
* shortname: components<br />
* Apply to be a #Public_Breakout: yes<br />
* Timeslot: 5pm UTC<br />
<br />
=== Virtual Keyboard Control ===<br />
* Proposer: [[User:Pcupp|Bo Cupp]] ([[User talk:Pcupp|talk]]) 08:18, 17 October 2020 (UTC)<br />
* Email address of proposer: pcupp@microsoft.com<br />
* Summary: Discuss the [https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/VirtualKeyboardAPI/explainer.md Virtual Keyboard API] and [https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/VirtualKeyboardPolicy/explainer.md Virtual Keyboard Policy].<br />
* Type of session: Open Discussion<br />
* Goals: Ensure interested parties understand the proposal, build consensus, and seek collaborators interested in helping author a spec.<br />
* shortname: editing<br />
* Additional speakers/panelists: Anupam Snigdha (snianu@microsoft.com)<br />
* Timeslot: 2pm UTC<br />
* Constraints on days in which the breakout can run: Wednesday, Thursday, Friday<br />
<br />
=== EditContext API ===<br />
* Proposer: [[User:Shihken|Alex Keng]] ([[User talk:Shihken|talk]]) 08:22, 17 October 2020 (UTC)<br />
* Email address of proposer: shihken@microsoft.com<br />
* Summary: Demo and discussion of the [https://w3c.github.io/editing/docs/EditContext/explainer.html EditContext API].<br />
* Type of session: Open Discussion<br />
* Goals: Provide an update on our progress since the introduction of the API at last year's TPAC.<br />
* shortname: editing<br />
* Timeslot: 2pm UTC<br />
* Constraints on days in which the breakout can run: Wednesday, Thursday, Friday<br />
<br />
=== European Publishers Council â Future of the Open Web ===<br />
* Proposer: [[User:Jwrosewell|James Rosewell]] ([[User talk:Jwrosewell|talk]]) 11:03, 18 October 2020 (UTC)<br />
* Email address of proposer: james@51degrees.com<br />
* Summary (one-sentence or so): Phillip Eligio from the [https://www.epceurope.eu/ EPC] will present the high-level summary of their positioning paper on the future of digital include the need for an effective, fair, transparent and privacy-centric identifier and the need for neutral oversight.<br />
* Type of session: talk + Q&A<br />
* Goals: Provide W3C membership and stakeholders with the authoritative position on publishers requirements from the open web.<br />
* shortname: #EPC<br />
* Additional speakers/panelists: Phillip Eligio<br />
* Apply to be a [#Public_Breakout]<br />
* Timeslot: 2pm UTC to 4pm UTC<br />
* Monday, Tuesday, Wednesday<br />
<br />
=== Defining a privacy baseline ===<br />
* Proposer: [[User:Jwrosewell|James Rosewell]] ([[User talk:Jwrosewell|talk]]) 11:03, 18 October 2020 (UTC)<br />
* Email address of proposer: james@51degrees.com<br />
* Summary: Follow on from [https://cryptpad.w3ctag.org/code/#/2/code/edit/4ht9YHtVS9AB4UBlh-oPvHej/ 15th October 2020 PING meeting] a session to debate the need for a privacy baseline definition. If all user agents must appear the same in every way what does this mean for innovation and diversity? If not, what should the comformity baseline be? How are different regional laws assessed to form a global baseline? Does the W3C want or need to create standards that design to, or even exceed, such a legal baseline?<br />
* Type of session: open discussion<br />
* Goals: Understand the gap in participants views on these questions and appetite for defining a privacy a baseline which all W3C members and stakeholders can understand and work to.<br />
* shortname: #privacy-baseline<br />
* Additional speakers/panelists: TBC<br />
* Apply to be a [#Public_Breakout]<br />
* Timeslot: 2pm UTC to 4pm UTC<br />
* Monday, Tuesday, Wednesday<br />
<br />
=== User Agent Client Hints ===<br />
* Proposer: [[User:Jwrosewell|James Rosewell]] ([[User talk:Jwrosewell|talk]]) 11:21, 18 October 2020 (UTC)<br />
* Email address of proposer: james@51degrees.com<br />
* Summary: Opportunity to debate and progress the many [https://github.com/WICG/ua-client-hints/issues open issues] raised in relation to the proposal to introduce [https://github.com/WICG/ua-client-hints client hints for user agent] data and deprecate the HTTP User-Agent field.<br />
* Type of session: Issue debate and resolution<br />
* Goals: Progress resolution of the issues related to the proposal to provide greater clarity to stakeholders.<br />
* shortname: #uach<br />
* Additional speakers/panelists: TBC<br />
* Apply to be a [#Public_Breakout]<br />
* Timeslot: 2pm UTC to 4pm UTC<br />
* Monday, Tuesday, Wednesday<br />
<br />
=== Innovative adaptation, personalization and assistive technologies ===<br />
<br />
* Proposer: [[User:Matkinson|Matthew Atkinson]] ([[User talk:Matkinson|talk]]) 14:38, 18 October 2020 (UTC)<br />
* Email address of proposer: matkinson@paciellogroup.com<br />
* Summary: The world of research has developed a numbers of super-helpful, user-tailored and also fairly transparent adaptations that could help a wide range of people more easily access devices, computers and the web. This session will introduce a few of these, but the primary goal is to discuss them and seek feedback on how we might incorporate them into the web. You can get a flavour of the adaptations at http://matatk.agrip.org.uk/articles/the-promise-of-personalised-interfaces/<br />
* Type of session: short informal talk to introduce a few key adaptations, followed by open discussion.<br />
* Goals: (1) Raise awareness of some ways that interfaces and content can be adapted that can help a wide range of people; (2) Seek ideas as to how these sorts of adaptations could be applied in the context of the web (standards, content, browsers, ...)<br />
* Shortname: TBC<br />
* Additional speakers/panelists: TBC<br />
* Apply to be a #Public_Breakout<br />
* Timeslot: 12pm-5pm UTC<br />
* Days on which the breakout can be run: Monday, Tuesday, Thursday, Friday<br />
<br />
=== Smart Cities ===<br />
* Proposer: [[User:Ashimura|Kazuyuki Ashimura]] ([[User talk:Ashimura|talk]]) 01:49, 19 October 2020 (UTC)<br />
* Email address of proposer: ashimura@w3.org<br />
* Summary (one-sentence or so): Based on the discussion during the [https://www.w3.org/WoT/ws-2019/minutes.html#day2-item02 Second WoT Workshop in Munich], [https://w3c.github.io/wot-usecases/#smart-city use cases on Smart Cities] have been proposed to the Web of Thing IG. However, we need to collect even more use cases and system implmentation experiences of actual smart cities from all over the world, because Smart Cities topic depends on the cities' location, culture, etc., and include various sub-systems from many different vendors. So we'd like to hold discussion on the possible standardization for Smart Cities before forming a concrete discussion group within W3C.<br />
* Type of session: Background description + Open discussion<br />
* Goals:<br />
** identify the stakeholders of Smart Cities standardization to drive the development of Web standards aligned with the real needs of Smart Cities<br />
** and then discuss how to proceed including the possibility of holding a dedicated Workshop and forming a dedicated IG<br />
* shortname: smart-cities<br />
* [optional] Additional speakers/panelists: tbd<br />
* [optional] Apply to be a [[#Public_Breakout]] (breakouts open to the world at large, not just the W3C community)=== Smart Cities ===<br />
* Proposer: [[User:Ashimura|Kazuyuki Ashimura]] ([[User talk:Ashimura|talk]]) 01:52, 19 October 2020 (UTC)<br />
* Email address of proposer: ashimura@w3.org<br />
* Summary (one-sentence or so): Based on the discussion during the [https://www.w3.org/WoT/ws-2019/minutes.html#day2-item02 Second WoT Workshop in Munich], [https://w3c.github.io/wot-usecases/#smart-city use cases on Smart Cities] have been proposed to the Web of Thing IG. However, we need to collect even more use cases and system implmentation experiences of actual smart cities from all over the world, because Smart Cities topic depends on the cities' location, culture, etc., and include various sub-systems from many different vendors. So we'd like to hold discussion on the possible standardization for Smart Cities before forming a concrete discussion group within W3C.<br />
* Type of session: Background description + Open discussion<br />
* Goals:<br />
** identify the stakeholders of Smart Cities standardization to drive the development of Web standards aligned with the real needs of Smart Cities<br />
** and then discuss how to proceed including the possibility of holding a dedicated Workshop and forming a dedicated IG<br />
* shortname: smart-cities<br />
* [optional] Additional speakers/panelists: tbd<br />
* [optional] Apply to be a [[#Public_Breakout]] (breakouts open to the world at large, not just the W3C community)<br />
* [optional] Timeslot: 12pm-4pm UTC (but need to avoid conflicts with the related sessions, e.g., [https://www.w3.org/wiki/TPAC/2020/SessionIdeas#Web_of_Things_.28WoT.29_Applications_and_Use_Cases WoT Applications and Use Cases], [https://www.w3.org/wiki/TPAC/2020/SessionIdeas#Video_Metadata_For_Moving_Objects_.26_Sensors_On_The_Web_.28WebVMT.29 Video metadata] and [https://www.w3.org/wiki/TPAC/2020/SessionIdeas#Voice_Agents Voice Agents]) - Detail on preferred date/time below<br />
** Monday, 12pm-1pm UTC<br />
** Monday, 2pm-3pm UTC<br />
** Tuesday, 12pm-1pm UTC<br />
** Tuesday, 2pm-3pm UTC<br />
** Thursday, 2pm-3pm UTC<br />
** Friday, 12pm-1pm UTC<br />
** Friday, 1pm-2pm UTC<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Thursday, Friday<br />
<br />
* [optional] Timeslot: 12pm-4pm UTC (but need to avoid conflicts with the related sessions, e.g., [https://www.w3.org/wiki/TPAC/2020/SessionIdeas#Web_of_Things_.28WoT.29_Applications_and_Use_Cases WoT Applications and Use Cases], [https://www.w3.org/wiki/TPAC/2020/SessionIdeas#Video_Metadata_For_Moving_Objects_.26_Sensors_On_The_Web_.28WebVMT.29 Video metadata] and [https://www.w3.org/wiki/TPAC/2020/SessionIdeas#Voice_Agents Voice Agents]) - Detail on preferred date/time below<br />
** Monday, 12pm-1pm UTC<br />
** Monday, 2pm-3pm UTC<br />
** Tuesday, 12pm-1pm UTC<br />
** Tuesday, 2pm-3pm UTC<br />
** Thursday, 2pm-3pm UTC<br />
** Friday, 12pm-1pm UTC<br />
** Friday, 1pm-2pm UTC<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Thursday, Friday<br />
<br />
=== Voice Agents ===<br />
* Proposer: [[User:Ashimura|Kazuyuki Ashimura]] ([[User talk:Ashimura|talk]]) 01:52, 19 October 2020 (UTC)<br />
* Email address of proposer: ashimura@w3.org<br />
* Summary (one-sentence or so): During [https://www.w3.org/2019/09/18-voice-minutes.html one of the breakout sessions at TPAC 2019] in Fukuoka, there was discusison about needs for improved voice agents for web services. And we'd like to proceed with the preparation for the expectd [W3C Workshop on User-friendly Smart Agents on the Web](https://github.com/w3c/strategy/issues/221)<br />
* Type of session: Background description + Open discussion<br />
* Goals:<br />
** identify people interested as (1) the expected Program Committee for the workshop and (2) participants in the workshop<br />
** also would get insights for the potential agenda for the expected workshop<br />
* shortname: voice-agents<br />
* [optional] Additional speakers/panelists: tbd<br />
* [optional] Apply to be a [[#Public_Breakout]] (breakouts open to the world at large, not just the W3C community)<br />
* [optional] Timeslot: 12pm-4pm UTC (but need to avoid conflicts with the related sessions, e.g., [https://www.w3.org/wiki/TPAC/2020/SessionIdeas#Web_of_Things_.28WoT.29_Applications_and_Use_Cases WoT Applications and Use Cases], [https://www.w3.org/wiki/TPAC/2020/SessionIdeas#Video_Metadata_For_Moving_Objects_.26_Sensors_On_The_Web_.28WebVMT.29 Video metadata] and [https://www.w3.org/wiki/TPAC/2020/SessionIdeas#Smart_Cities Smart Cities]) - Detail on preferred date/time below<br />
** Monday, 12pm-1pm UTC<br />
** Monday, 2pm-3pm UTC<br />
** Tuesday, 12pm-1pm UTC<br />
** Tuesday, 2pm-3pm UTC<br />
** Thursday, 2pm-3pm UTC<br />
** Friday, 12pm-1pm UTC<br />
** Friday, 1pm-2pm UTC<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Thursday, Friday<br />
<br />
=== Cloud Gaming on the Web ===<br />
* Proposer: [[User:Lzm|Zhaoming Li]] ([[User talk:Lzm|talk]]) 08:10, 19 October 2020 (UTC)<br />
* Email address of proposer: lizhaoming@tingyutech.com<br />
* Summary: This session will include a basic introduction about cloud gaming, why cloud gaming is powerful, how cloud gaming run on the web, how can the web help cloud gaming, and shortages we currently have on the browser.<br />
* Type of session: talk and open discussion<br />
* Goals: We are looking to start a community group to work on providing a fast and stable user experience of cloud gaming.<br />
* shortname: cloudgaming<br />
* Additional speakers/panelists: Qingqian Tao, Alicia Nie<br />
<br />
=== W3C 2020: Living Standards and Reviews ===<br />
<br />
* Proposer: [[User:PlehegarPLH]] <br />
* Email address of proposer: plh@w3.org<br />
* Summary: This session will decrypt the new W3C Process to helps editors and participants find their ways. It will also give the latest information on how to do wide reviews and transitions.<br />
* Type of session: talk and open discussion<br />
* Goals: Avoid getting lost into the W3C Process maze.<br />
* shortname: w3cprocess<br />
* Additional speakers/panelists: none</div>Plehegarhttps://www.w3.org/wiki/index.php?title=TPAC/2020/SessionIdeas&diff=112670TPAC/2020/SessionIdeas2020-10-19T12:32:35Z<p>Plehegar: W3C 2020</p>
<hr />
<div>You are invited to propose [https://www.w3.org/2020/10/TPAC/ TPAC 2020] '''TPAC Breakout week (October 26-30)''' sessions in advance of the meeting. <br />
See the [[TPAC/2020/FAQ | TPAC 2020 FAQ]] for more information. Please contact dom@w3.org for any question regarding the organization of TPAC breakouts.<br />
<br />
<div style="float:right;clear:right">__TOC__</div><br />
<br />
== How to use this page ==<br />
<br />
Please use this page to:<br />
<br />
* Propose sessions you wish to lead<br />
* '''Please place new proposals at the bottom of this document'''<br />
<br />
== How to propose a session ==<br />
<br />
Please provide:<br />
<ul class="show_items"><br />
* session name (as a === subhead === )<br />
* session proposer (yourself, if so sign using 4 tildes; optional: name a desired session leader) and an email address<br />
* one sentence session summary<br />
* type of session: (e.g.: open discussion, talk, panel, tutorial, demo, etc.)<br />
* goals of session<br />
* additional speakers/panelists (to help reduce conflicts when one person is needed in more than one place)<br />
* opt-in to be a [[#Public_Breakout]] open to participation from the public at large<br />
* a shortname that can be used to associate an IRC or Slack channel to your breakout<br />
* by default, we expect breakout to happen at 2pm UTC for '''one hour''' during the week of October 26 to allow participation from as many timezones as possible; if your breakout cannot happen at 2pm UTC, or if your breakout can be scheduled to happen across multiple repeated instances at different time (e.g. for a tutorial, demos), please indicate it<br />
** single instance TPAC breakout sessions proposed outside of the 2pm slot are subject to validation by the organizing committee<br />
* if your breakout needs to happen on a subset of the 5 days of the week, please also indicate it<br />
</ul><br />
<br />
== Public Breakout ==<br />
<br />
In addition to the usual breakout discussions organized for the traditional TPAC community (IG/WG participants, W3C member representatives), we are trying something new this year. We plan to open a set of breakouts to the broader public, in an effort to bring more diverse voices into the W3C community. We feel this is necessary to ensure the fullest range of users and perspectives is represented and encoded in our web standards. <br />
<br />
Breakout proposers are invited to opt-in to make their breakout open to the public in order to invite a wider and more diverse set. While there aren't clearly defined limits to what topics would benefit from this, we encourage Public Breakouts to focus on use cases or ergonomics of a technology, and to provide upfront onboarding and context for any breakouts that include deep technical dive.<br />
<br />
The W3C devrel team and their partners will work with Public Breakout proposers to ensure their breakouts are as welcoming and kind as possible when joining their first W3C or Web standardization discussion. For anyone who opts in to propose a Public Breakout , we will be offering dedicated training sessions the week before TPAC breakouts on the topic of facilitating accessible discussions.<br />
<br />
(Many thanks to Boaz Sender, Sheila Moussavi, Jory Burson, Laura Lee McCarthy who have been working with Marie-Claire Forgue and Dominique Hazael-Massieux in setting this up)<br />
<br />
== Proposed sessions ==<br />
<br />
=== EXAMPLE session with session name ===<br />
* Proposer: <nowiki>~~~~</nowiki> (Instruction: remove <nowiki><nowiki> and </nowiki></nowiki> around the tildas. Explanation: The 4 tildas will sign YOUR name and include a timestamp of your proposal.)<br />
* Email address of proposer: <br />
* Summary (one-sentence or so): <br />
* Type of session (e.g.: open discussion, talk, panel, etc.): <br />
* Goals:<br />
* shortname (used for minting an IRC channel for the breakout)<br />
* [optional] Additional speakers/panelists:<br />
* [optional] Apply to be a [[#Public_Breakout]] (breakouts open to the world at large, not just the W3C community)<br />
* [optional] Timeslot: 2pm UTC ("the golden hour" - 7am US West Coast, 11pm Japan) - if you can't run your breakout proposal at 2pm UTC, we ask that you consider carefully alternatives in the 12pm-5pm UTC, knowing that a number of people won't be able to make it; alternatively, if your breakout can happen as a repeated instance (e.g. for a tutorial or a demo), please indicate so and we will schedule these instances away from the golden hour<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Wednesday, Thursday, Friday<br />
<br />
=== IAB Europe's Transparency and Control Framework ===<br />
* Proposer: [[User:Benhum|Ben Humphry]] <br />
* Email address of proposer: humphry@iabeurope.eu<br />
* Summary (one-sentence or so): Internet Advertising Bureau (IAB) Europe to brief W3C members on Transparency and Consent Framework (TCF), developed over many years to capture peopleâs consent choices and inform multiple parties. [https://github.com/w3c/web-advertising/issues/86/ Web-Advertising Github Issue]<br />
* Type of session: talk and open discussion<br />
* Goals: Explain this existing framework which provides consumers with a transparent and fair mechanism for control of their privacy preferences.<br />
* shortname: TCF<br />
* Additional speakers/panelists: TBD - Experts from IAB Europe<br />
* Apply to be a [[#Public_Breakout]]: yes<br />
* Timeslot: Any of 12pmâ5pm UTC.<br />
<br />
=== MDN Developer Need Assessments: results and next steps ===<br />
* Proposer: [[User:Dom|Dominique HazaĂŤl-Massieux]] <br />
* Email address of proposer: dom@w3.org<br />
* Summary (one-sentence or so): Review outcome of the [https://insights.developer.mozilla.org/ MDN DNA survey 2019], incl recently released [https://mdn-web-dna.s3-us-west-2.amazonaws.com/MDN-Browser-Compatibility-Report-2020.pdf MDN Browser Compat Report] and expectations on MDN DNA Survey 2020<br />
* Type of session: talk and open discussion<br />
* Goals: Inform how large-scale developer input has impacted and should impact standardization priorities<br />
* shortname: mdn-dna<br />
* Additional speakers/panelists: Philip Jägenstedt, Robert Nyman, Chris Mills, Boaz Sender<br />
* Apply to be a [[#Public_Breakout]]: yes<br />
<br />
=== Learning from Mini Apps ===<br />
* Proposer: [[User:Tsteiner|Thomas Steiner]] <br />
* Email address of proposer: tomac@google.com<br />
* Summary: In this breakout session, I will first explain what mini apps are and how to build them, and then move on to an open discussion focused on what Web developers can learn from mini apps and their developer experience. <br />
* Type of session: Talk followed by discussion.<br />
* Goals: Having a better understanding of mini apps.<br />
* Shortname: miniappslearnings<br />
* [optional] Additional speakers/panelists: You?<br />
* [optional] Apply to be a [[#Public_Breakout]]: Yes.<br />
* [optional] Timeslot: Any of 12pmâ5pm UTC.<br />
* [optional] Constraints on days in which the breakout can run: No constraints.<br />
<br />
=== Web Packaging ===<br />
* Proposer: [[User:Jyasskin|Jeffrey Yasskin]] <br />
* Email address of proposer: jyasskin@google.com<br />
* Summary (one-sentence or so): Discuss Web Packaging issues that [https://github.com/WICG/webpackage/issues?q=is%3Aopen+is%3Aissue+label%3Adiscuss need discussion].<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Open Discussion<br />
* Goals: Resolve or make progress on some open issues with the web packaging design<br />
* Shortname: web-packaging<br />
* [optional] Additional speakers/panelists:<br />
* [optional] Apply to be a [[#Public_Breakout]]: yes<br />
* [optional] Timeslot: 2pm UTC<br />
* [optional] constraints on days in which the breakout can run: No constraints.<br />
<br />
=== Memory copies & zero-copy operations on the Web ===<br />
* Proposer: [[User:Fd|François Daoust]] <br />
* Email address of proposer: fd@w3.org<br />
* Summary (one-sentence or so): In scenarios such as real-time processing of media frames with ML algorithms, memory copies made along the processing pipeline may account for a non negligible part of the overall performance budget of the said processing. See [https://github.com/w3c/machine-learning-workshop/issues/93 Memory copies discussion in the Web and Machine Learning workshop] for context. Could the Web do better?<br />
* Type of session: Open discussion<br />
* Goals: Explore needs to copy memory in various Web technologies (JS, WebAssembly, WebGPU, Machine Learning, WebRTC, Media) and identify possible architectural updates to the Web Platform that could help reduce unneeded memory copies.<br />
* shortname: zerocopy<br />
* Timeslot: 2pm UTC<br />
<br />
=== Video Metadata For Moving Objects &amp; Sensors On The Web (WebVMT) ===<br />
* Proposer: [[User:Rjksmith|Rob Smith]] <br />
* Email address of proposer: rob.smith@awayteam.co.uk<br />
* Summary: Emerging markets in 'mobile video devices' such as dashcams, drones, body-worn video and smartphones are increasing consumer demand for geotagged video on the web and especially with access to moving objects, e.g. distance &amp; speed for vehicles, and sensor data, e.g. heart rate for fitness users. More details at [https://github.com/w3c/sdw/issues/1194 w3c/sdw #1194]<br />
* Type of session: Short talk followed by discussion<br />
* Goals: Identify properties of moving objects &amp; sensors required in a web API to access timed video metadata exported for the web, i.e. WebVMT, from mobile video devices.<br />
* Shortname video-location<br />
* Apply to be a [[#Public_Breakout]]<br />
* Timeslot: 2pm UTC<br />
<br />
=== Improve definition of parties and trust relationships across W3C ===<br />
* Proposer: [[User:Jwrosewell|James Rosewell]] <br />
* Email address of proposer: james@51degrees.com<br />
* Summary (one-sentence or so): First and third party are poorly defined and lack the granularity to resolve many of the problems W3C are working on. Debate definitions of parties considering their relationship with one another, trust, choice, scale and varying conditions in relation to people. See IWA BG issue for commentary and pre session discussion. [https://github.com/w3c/web-advertising/issues/87]<br />
* Type of session: Presentations followed by discussion<br />
* Goals: Agreement on approach to define parties consistently and appropriately across W3C including TAG and PING documents.<br />
* shortname: party-time<br />
* Speakers/panelists: TBD â would like to add advocates for different view points.<br />
* Apply to be a [[#Public_Breakout]] (as a minimum should include Improving Web Advertising Business Group members)<br />
* Timeslot: 2pm to 4pm UTC<br />
* Monday, Tuesday, Wednesday<br />
<br />
=== Web Components ===<br />
* Proposer: [[User:rniwa|Ryosuke Niwa]] <br />
* Email address of proposer: rniwa at apple<br />
* Summary (one-sentence or so): Discussion of various topics related to web components<br />
* Type of session: Multi-topic discussion; Agenda and logistics is tracked at https://github.com/w3c/webcomponents/issues/877<br />
* Goals: Reaching consensus on various topics<br />
* shortname: components<br />
* Apply to be a #Public_Breakout: yes<br />
* Timeslot: 5pm UTC<br />
<br />
=== Parts and Template Instantiation ===<br />
* Proposer: [[User:rniwa|Ryosuke Niwa]] <br />
* Email address of proposer: rniwa at apple<br />
* Summary (one-sentence or so): Discussion of APIs to help instantiate templates.<br />
* Type of session: A presentation followed by discussion<br />
* Goals: Make progress on the proposal and reach some consensus on minimal viable product.<br />
* shortname: components<br />
* Apply to be a #Public_Breakout: yes<br />
* Timeslot: 5pm UTC<br />
<br />
=== Declarative Shadow DOM ===<br />
* Proposer: [[User:mfreed|Mason Freed]] <br />
* Email address of proposer: masonfreed@chromium.org<br />
* Summary (one-sentence or so): Discussion of the declarative Shadow DOM [https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md proposal]/[https://github.com/whatwg/dom/issues/831 issue]<br />
* Type of session: A presentation followed by discussion.<br />
* Goals: Reach some consensus on the proposal and spec.<br />
* shortname: components<br />
* Apply to be a #Public_Breakout: yes<br />
* Timeslot: 5pm UTC<br />
<br />
=== Making math a first class citizen on the Web ===<br />
* Proposer: [[User:Nsoiffer2|Neil Soiffer]] <br />
* Email address of proposer: neil.soiffer@gmail.com<br />
* Summary: The MathML Refresh CG is forming a WG and we would like to discuss our [https://mathml-refresh.github.io/charter-drafts/math-2020.html proposed charter] with interested parties. The group has coordinated with the CSS WG, WhatWG, and TAG over some issues and there are many remaining open questions involving Shadow DOM, Houdini, Links, the accessibility tree, search and other parts of the Web platform.<br />
* Type of session: open discussion<br />
* Goals: Provoke discussions on some of the subtle issues of including math in the Web platform and get guidance on resolving them.<br />
* shortname: math<br />
* Additional speakers/panelists: Brian Karkell (bkardell@gmail.com)<br />
* Apply to be a [[#Public_Breakout]]: yes<br />
* Timeslot: 3:00pm UTC<br />
<br />
=== All your spec are belong to us - irrigating dev resources from specs ===<br />
* Proposer: [[User:Dom|Dominique HazaÍl-Massieux]], [[User:Fd|François Daoust]]<br />
* Email address of proposer: dom@w3.org, fd@w3.org<br />
* Summary: Machines read specs too. This breakout session will review existing and possible tools and projects that make use of content automatically extracted from specs.<br />
* Type of session: Talk and open discussion<br />
* Goals: Raise awareness and learn about existing internal and external projects (such as webref, Bikeshed, Respec, MDN, Visual Studio, Web Platform Tests) that depend on content extracted from specs, to irrigate CSS/IDL tests and interface headers in browser codebases, validate cross-references, enrich IDE tools, identify dependencies, detect anomalies, and otherwise improve the quality of the specifications. Clarify what happens when e.g. IDL content is no longer valid or machine-readable. Discuss usage scenarios that additional formalism for writing specs could perhaps enable.<br />
* shortname: specmining<br />
* Apply to be a [[#Public_Breakout]]<br />
<br />
=== Maps for HTML Community Group ===<br />
* Proposer: [[User:Prushfor|Peter Rushforth]] <br />
* Email address of proposer: peter.rushforth@canada.ca<br />
* Summary: The Maps for HTML community recently concluded a successful [https://www.w3.org/2020/maps/agenda#day-1 workshop] about standardizing maps for the Web platform, and we would like to invite those interested to take part in a follow up meeting.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Summary presentation of workshop, followed by open discussion.<br />
* Goals: Provide and receive information on specific topics<br />
* shortname: maps4html (used for minting an IRC channel for the breakout)<br />
* Apply to be a [[#Public_Breakout]]: yes<br />
* Timeslot: 2pm UTC<br />
<br />
=== EPUB 3 History and Future ===<br />
* Proposer: [[User:Tzviya|Tzviya Siegman]] Tzviya Siegman and Wendy Reid <br />
* Email address of proposer: tsiegman@wiley.com<br />
* Summary (one-sentence or so): Learn about the 20+ year history of EPUB, how it came to the W3C, and what the new EPUB 3 WG will accomplish. <br />
* Type of session: talk with time for questions <br />
* Goals: Provide info about EPUB and Publishing Activity<br />
* shortname EPUB3<br />
* [optional] Additional speakers/panelists: Wendy Reid and (possibly) Shinya Takami<br />
* [optional] Apply to be a [[#Public_Breakout]]: yes<br />
<br />
=== Delegated Ink Trails ===<br />
* Proposer: [[User:Mabian|Mario Bianucci]] <br />
* Email address of proposer: mabian@microsoft.com<br />
* Summary: Delegated Ink Trail Presentation Paradigm: Prototype status and learnings from web developers feedback.<br />
* Type of session: open discussion<br />
* Goals: Discuss the proposed paradigm, and reach consensus on next steps.<br />
* shortname: delegated_ink_trail<br />
* Apply to be a [[#Public_Breakout]]: yes.<br />
* Timeslot: 2pm UTC<br />
* constraints on days in which the breakout can run: Tuesday, Wednesday, Thursday, Friday<br />
<br />
=== W3C New York Metro Chapter Meetup ===<br />
* Proposer: Rachel Yager <br />
* Email address of proposer: rachel@fortunetimesgroup.com / ryager@w3.org<br />
* Summary (one-sentence or so): Inviting Web Community to Join the W3C New York Metro Chapter. W3C Members and Non-Members are Welcome! The Chapter provides a point of presence of W3C within the Metropolitan New York City to build and enhance the Web Community, to assist W3C Members, and to invite W3C Members participation in WebInnovationX Center for World Wide Web research and education initiatives.<br />
* Type of session: Seminar Talks and Presentations<br />
* Goals: Provide information on W3C NY Metro Chapter Member Benefits, Activities, Events, Strategic Partnership, Leadership, and Technology Innovation Initiatives.<br />
* shortname: WebInnovationX<br />
* Additional speakers/panelists: TBD<br />
* Apply to be a [[#Public_Breakout]]: yes<br />
* Timeslot: 4pm UTC<br />
* constraints on days in which the breakout can run: Wednesday<br />
<br />
=== Media Publishers of the Web, Unite! ===<br />
* Proposer: [[User:Rberjon|Robin Berjon]] <br />
* Email address of proposer: robin.berjon@nytimes.com<br />
* Summary (one-sentence or so): Media publishers have long been absent or under-represented in Web standards, but there is a growing sense that we should speak up in the making of tech and a growing set of members. This session is to share fears, hopes, tips, and more.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): <br />
* Goals: Get media publishers to meet and help each other out navigate the strange but beautiful world of standards.<br />
* shortname (used for minting an IRC channel for the breakout): media-pubs<br />
* Apply to be a [[#Public_Breakout]]: yeah<br />
* Timeslot: 2pm UTC<br />
<br />
=== Revenue Models for the Web ===<br />
* Proposer: [[User:Ahopebai|Adrian Hope-Bailie]] <br />
* Email address of proposer: Ali Spivak (ali@coil.com) and Adrian Hope-Bailie (adrian@coil.com)<br />
* Summary (one-sentence or so): There has been a lot of discussion and [[https://webmonetization.org experimentation]] looking at alternatives to advertising for monetization on the Web. In this panel we aim to explore these alternative models, debate whether or not advertising still has a role to play, and discuss the potential for standards to enable a broader set of business models.<br />
* Type of session: Panel followed by open discussion<br />
* Goals: Discuss options for generating revenue on the Web and how standards can enable more options.<br />
* shortname (used for minting an IRC channel for the breakout): monetization<br />
* Additional speakers/panelists: Panel currently being confirmed. Please email the proposers if you wish to join the panel.<br />
* Apply to be a [[#Public_Breakout]]: YES<br />
* Timeslot: 2pm UTC ("the golden hour" - 7am US West Coast, 11pm Japan)<br />
<br />
=== Online Harms â a European and UK perspective ===<br />
* Proposer: [[User:Jwrosewell|James Rosewell]] <br />
* Email address of proposer: james@51degrees.com<br />
* Summary (one-sentence or so): Presentation to cover a) the current state of online harm legislation in the UK and Europe including the Audio-Visual Media Services Directive (AVMS-D) on 1st November 2020; * b) child safety and the impact DNS over HTTPs is having; and c) the role of standards, laws and industry adoption in solutions.<br />
* Type of session: presentation (20 mins) followed by Q&A<br />
* Goals: Inform attendees about a full range of on line harms, the risk of unintended consequences when addressing a narrow set in isolation, and the role that a technical standards body can play in improving the web for all.<br />
* Additional speakers/panelists: Alistair Kelman (ali.kelman@safecast.co.uk)<br />
* Apply to be a #Public_Breakout: yes<br />
* Timeslot: Any of 12pmâ5pm UTC.<br />
* Monday, Tuesday, Wednesday<br />
<br />
=== Web Monetization and Grant for the Web ===<br />
* Proposer: [[User:Aspivak|Ali Spivak]]<br />
* Email address of proposer: ali@coil.com, info@grantfortheweb.org<br />
* Summary (one-sentence or so): A deep dive into Grant for the Web's advocacy of the (proposed) Web Monetization standard.<br />
* Type of session: Conversation with opportunity for audience questions.<br />
* Goals: Share Grant for the Web's mission and how early grantees are contributing to the growing Web Monetization ecosystem through use of the (proposed) Web Monetization standard and the Interledger Protocol.<br />
* shortname (used for minting an IRC channel for the breakout) Grant-for-the-Web<br />
* Additional speakers/panelists: Chris Lawrence (Grant for the Web), Ali Spivak (Coil), more participants to be announced.<br />
* Apply to be a #Public_Breakout: yes<br />
* Timeslot: any that are not in conflict with "Revenue Models for the Web" breakout (see above)<br />
<br />
=== The Waning Web Platform Engine Diversity ===<br />
* Proposer: [[User:Chriswilson|Chris Wilson]]<br />
* Email address of proposer: cwilso@google.com<br />
* Summary (one-sentence or so): How should the W3C Process adapt to a world with fewer engine implementers, but more browsers and stakeholders? The open source browser projects are shipping tested, interoperable implementations of new specs well before they reach Recommendation. Horizontal review must happen at the incubation stage or shortly thereafter to have any impact on what browser teams ship. What if anything can the Process do to encourage early engagement by user representatives and horizontal review communities rather than using the PR stage as the checkpoint to ensure this happens? How do we define what web stakeholders should treat as the "real" web standards?<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): open discussion<br />
* Goals: Gather ideas for the future of the W3C Process and incubation process.<br />
* shortname (used for minting an IRC channel for the breakout): engine-scion<br />
* Apply to be a [[#Public_Breakout]]: yes<br />
* Timeslot: 2pm UTC - 6pm UTC<br />
<br />
=== What would it mean for W3C to REALLY prioritize end users? === <br />
* Proposer: [[User:Mchampio2|Michael Champion]] ([[User talk:Mchampio2|talk]]) 01:04, 14 October 2020 (UTC) <br />
* Email address of proposer: michaelc.champion@gmail.com<br />
* Summary : Prioritizing the interests of end users has been a hot topic lately [https://www.rfc-editor.org/rfc/rfc8890.html in IETF], [https://www.w3.org/2001/tag/doc/ethical-web-principles/ in W3C] , and [https://www.eff.org/deeplinks/2020/10/we-fight-users from EFF]. It's not clear what it would CONCRETELY mean for W3C to prioritize the needs of end-users over those of the platform implementers, website developers, "horizontal" specialists, and researchers who make up most of W3C's membership. This breakout will explore the problem of insufficient end-user input into web standards discussions, and seek consensus on ways to address it. See https://github.com/WebStdFuture/Users1st for more context and hopefully pre-meeting and post-meeting discussion. <br />
* Type of session : Open Discussion of https://www.rfc-editor.org/rfc/rfc8890.html and what adopting something similar might mean for W3C<br />
* Goals: Rough consensus whether this is something W3C should do, and what next steps might be<br />
* shortname (used for minting an IRC channel for the breakout): users1st<br />
* [optional] Additional speakers/panelists: Use https://github.com/WebStdFuture/Users1st/issues to request time take a position and request time to present it.<br />
* [optional] Timeslot: 2pm UTC<br />
<br />
=== W3C Group calendaring === <br />
* Proposer: [[User:Jean-gui|Jean-Guilhem Rouel]] <br />
* Email address of proposer: jean-gui@w3.org<br />
* Summary : Providing groups with a good solution to manage their meetings has been requested for a long time. This breakout will consist in a demo of what W3C is currently working on and a discussion to gather initial feedback from interested parties.<br />
* Type of session : Demo/Open Discussion<br />
* Goals: Present and gather feedback on the current state of the project<br />
* shortname (used for minting an IRC channel for the breakout): group-calendaring<br />
* Additional speakers/panelists: Philippe le HĂŠgaret, Vivien Lacourba<br />
* Timeslot: 2pm UTC<br />
* Days in which the breakout can run: Monday, Tuesday, Thurday, Friday<br />
<br />
=== Web of Things (WoT) Applications and Use Cases ===<br />
* Proposer: [[User:Mmccool|Michael McCool]] <br />
* Email address of proposer: michael.mccool@intel.com<br />
* Summary: Update on Web of Things (WoT) progress in extending web standards to IoT, and a showcase for recent applications and use case scenarios from our online plugfest.<br />
* Type of session: 30m presentation, 30m discussion and Q&A.<br />
* Goals: Present recent practical work on applying WoT to specific use-case scenarios, including from our recent plugfest, and to gather feedback on future priorities and use cases.<br />
* Shortname: wot-breakout<br />
* Apply to be a [[#Public_Breakout]] (breakouts open to the world at large, not just the W3C community)<br />
* Timeslot: 1pm UTC (12pm (noon) UTC *might* be acceptable, but would have to be discussed with the rest of the group). Unfortunately, conflicts at 2pm UTC.<br />
** potentially would have a second session at an Asian-friendly time, e.g., 5-7am UTC, but concrete time still needs to be identified.<br />
* Day: Tuesday.<br />
<br />
=== Connected Vehicle Interface Initiative ===<br />
* Proposer: [[User:Ted|Ted Guild]] ([[User talk:Ted|talk]]) 20:34, 16 October 2020 (UTC) <br />
* Email address of proposer: ted@w3.org<br />
* Summary (one-sentence or so): Joint GENIVI / W3C workshop on Connected Vehicle Interface Initiative, summary of current standards, technology stack, past roundtables and stakeholder perspectives.<br />
* Type of session: Workshop<br />
* Goals: Establish wider understanding of standards efforts, refinement and agreement on scope of initiative.<br />
* shortname: CVII<br />
* Additional speakers/panelists: [https://www.w3.org/2020/10/GENIVI_AMM_CVII_Working_Sessions.pdf partial list, will be updated]<br />
* Audience: Restricted to GENIVI and W3C Members plus invitees<br />
* Timeslot: 14-17:30 GMT<br />
* Day: Tuesday<br />
<br />
=== The Responsible Use of Geospatial Data ===<br />
* Proposer: [[User:Eparsons|Ed Parsons]] <br />
* Email address of proposer: eparsons@google.com<br />
* Summary: Progress on developing a framework for the responsible and ethical use of Geospatial tools and data <br />
* Type of session: Open discussion<br />
* Goals: Present and gather feedback on the work so far<br />
* shortname: ResGeo<br />
* Additional speakers/panelists: Joseph Abhayaratnaâ<br />
* Apply to be a [[#Public_Breakout]] Yes<br />
* Timeslot: 2pm UTC<br />
<br />
=== Storage Buckets API ===<br />
* Proposer: [[User:Ayuishii|Ayu Ishii]] <br />
* Email address of proposer: ayui@chromium.org <br />
* Summary: Discussion on Storage Buckets API [https://github.com/WICG/storage-buckets/blob/gh-pages/explainer.md proposal]<br />
* Type of session: Presentation followed by discussion <br />
* Goals: Learn use cases and concerns and reach consensus on proposal<br />
* Shortname: storage-buckets<br />
* Additional speakers/panelists: Victor Costan<br />
* Apply to be a [[#Public_Breakout]]: Yes<br />
* Timeslot: 4pm UTC<br />
* Constraints on days in which the breakout can run: Thursday, Friday<br />
<br />
=== MiniApp Standardization in W3C ===<br />
* Proposer: [[User: Angel Li| Angel Li]] <br />
* Email address of proposer: angelli.laq@alibaba-inc.com<br />
* Summary: Discussion on MiniApp Standardization in W3C <br />
* Type of session: Presentation followed by discussion <br />
* Goals: introduce the current progress of MiniApp specifications incubation, discuss possible cooperation with related groups and collect community feedback on the proposed MiniApp WG charter <br />
* Shortname: MiniApp Standardization<br />
* Apply to be a [[#Public_Breakout]]: Yes<br />
* Timeslot: 2pm UTC<br />
<br />
=== Web Install API ===<br />
* Proposer: [[User:Peconn|Peter Conn]] <br />
* Email address of proposer: peconn@chromium.org<br />
* Summary: Discuss the need, use cases and considerations of a general web install API.<br />
* Type of session: Brief talk followed by an open discussion.<br />
* Goals: Identify appetite and concerns for such an API.<br />
* Shortname: web-install<br />
* Timeslot: 2pm UTC<br />
* Days in which the breakout can run: Monday, Tuesday, Wednesday, Friday<br />
<br />
=== WebID, a federated SignIn API ===<br />
* Proposer: [[User: majidvp| Majid Valipour]]<br />
* Email address of proposer: majidvp@chromium.org<br />
* Summary: Discuss the usecases, requirements and explore solution space for a privacy-preserving federates SignIn API. <br />
* Type of session : Brief talks followed by open discussion / brainstorming <br />
* Goals: Understand current federated sign-in state on the web and brainstorm various ideas on how to make it more privacy-preserving. Present the current thinking and ideas in [https://wicg.github.io/WebID/README.html WebID proposal] and brainstorm solutions.<br />
* Shortname: webid<br />
* Additional speakers/panelists: Samuel Goto, Ken Buchanan<br />
* Apply to be a [[#Public_Breakout]]: Yes<br />
* Timeslot: 2pm UTC<br />
<br />
=== CSS Module Scripts ===<br />
* Proposer: [[User:Daniec|Daniel Clark]] ([[User talk:Daniec|talk]]) 21:01, 16 October 2020 (UTC)<br />
* Email address of proposer: daniec@microsoft.com<br />
* Summary (one-sentence or so): Discuss [https://github.com/w3c/webcomponents/blob/gh-pages/proposals/css-modules-v1-explainer.md CSS Module Scripts] now that they are unblocked by [https://github.com/tc39/proposal-import-assertions Import Assertions]. Confirm positions on the minimal semantics, discuss the status of DocumentOrShadowRoot.adoptedStyleSheets, and potential further steps after initial support, like bundling CSS and exporting other objects from a stylesheet.<br />
* Type of session: Open Discussion.<br />
* Goals: Reach consensus on the minimal semantics and make progress on further directions.<br />
* shortname: components<br />
* Apply to be a #Public_Breakout: yes<br />
* Timeslot: 5pm UTC<br />
<br />
=== Virtual Keyboard Control ===<br />
* Proposer: [[User:Pcupp|Bo Cupp]] ([[User talk:Pcupp|talk]]) 08:18, 17 October 2020 (UTC)<br />
* Email address of proposer: pcupp@microsoft.com<br />
* Summary: Discuss the [https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/VirtualKeyboardAPI/explainer.md Virtual Keyboard API] and [https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/VirtualKeyboardPolicy/explainer.md Virtual Keyboard Policy].<br />
* Type of session: Open Discussion<br />
* Goals: Ensure interested parties understand the proposal, build consensus, and seek collaborators interested in helping author a spec.<br />
* shortname: editing<br />
* Additional speakers/panelists: Anupam Snigdha (snianu@microsoft.com)<br />
* Timeslot: 2pm UTC<br />
* Constraints on days in which the breakout can run: Wednesday, Thursday, Friday<br />
<br />
=== EditContext API ===<br />
* Proposer: [[User:Shihken|Alex Keng]] ([[User talk:Shihken|talk]]) 08:22, 17 October 2020 (UTC)<br />
* Email address of proposer: shihken@microsoft.com<br />
* Summary: Demo and discussion of the [https://w3c.github.io/editing/docs/EditContext/explainer.html EditContext API].<br />
* Type of session: Open Discussion<br />
* Goals: Provide an update on our progress since the introduction of the API at last year's TPAC.<br />
* shortname: editing<br />
* Timeslot: 2pm UTC<br />
* Constraints on days in which the breakout can run: Wednesday, Thursday, Friday<br />
<br />
=== European Publishers Council â Future of the Open Web ===<br />
* Proposer: [[User:Jwrosewell|James Rosewell]] ([[User talk:Jwrosewell|talk]]) 11:03, 18 October 2020 (UTC)<br />
* Email address of proposer: james@51degrees.com<br />
* Summary (one-sentence or so): Phillip Eligio from the [https://www.epceurope.eu/ EPC] will present the high-level summary of their positioning paper on the future of digital include the need for an effective, fair, transparent and privacy-centric identifier and the need for neutral oversight.<br />
* Type of session: talk + Q&A<br />
* Goals: Provide W3C membership and stakeholders with the authoritative position on publishers requirements from the open web.<br />
* shortname: #EPC<br />
* Additional speakers/panelists: Phillip Eligio<br />
* Apply to be a [#Public_Breakout]<br />
* Timeslot: 2pm UTC to 4pm UTC<br />
* Monday, Tuesday, Wednesday<br />
<br />
=== Defining a privacy baseline ===<br />
* Proposer: [[User:Jwrosewell|James Rosewell]] ([[User talk:Jwrosewell|talk]]) 11:03, 18 October 2020 (UTC)<br />
* Email address of proposer: james@51degrees.com<br />
* Summary: Follow on from [https://cryptpad.w3ctag.org/code/#/2/code/edit/4ht9YHtVS9AB4UBlh-oPvHej/ 15th October 2020 PING meeting] a session to debate the need for a privacy baseline definition. If all user agents must appear the same in every way what does this mean for innovation and diversity? If not, what should the comformity baseline be? How are different regional laws assessed to form a global baseline? Does the W3C want or need to create standards that design to, or even exceed, such a legal baseline?<br />
* Type of session: open discussion<br />
* Goals: Understand the gap in participants views on these questions and appetite for defining a privacy a baseline which all W3C members and stakeholders can understand and work to.<br />
* shortname: #privacy-baseline<br />
* Additional speakers/panelists: TBC<br />
* Apply to be a [#Public_Breakout]<br />
* Timeslot: 2pm UTC to 4pm UTC<br />
* Monday, Tuesday, Wednesday<br />
<br />
=== User Agent Client Hints ===<br />
* Proposer: [[User:Jwrosewell|James Rosewell]] ([[User talk:Jwrosewell|talk]]) 11:21, 18 October 2020 (UTC)<br />
* Email address of proposer: james@51degrees.com<br />
* Summary: Opportunity to debate and progress the many [https://github.com/WICG/ua-client-hints/issues open issues] raised in relation to the proposal to introduce [https://github.com/WICG/ua-client-hints client hints for user agent] data and deprecate the HTTP User-Agent field.<br />
* Type of session: Issue debate and resolution<br />
* Goals: Progress resolution of the issues related to the proposal to provide greater clarity to stakeholders.<br />
* shortname: #uach<br />
* Additional speakers/panelists: TBC<br />
* Apply to be a [#Public_Breakout]<br />
* Timeslot: 2pm UTC to 4pm UTC<br />
* Monday, Tuesday, Wednesday<br />
<br />
=== Innovative adaptation, personalization and assistive technologies ===<br />
<br />
* Proposer: [[User:Matkinson|Matthew Atkinson]] ([[User talk:Matkinson|talk]]) 14:38, 18 October 2020 (UTC)<br />
* Email address of proposer: matkinson@paciellogroup.com<br />
* Summary: The world of research has developed a numbers of super-helpful, user-tailored and also fairly transparent adaptations that could help a wide range of people more easily access devices, computers and the web. This session will introduce a few of these, but the primary goal is to discuss them and seek feedback on how we might incorporate them into the web. You can get a flavour of the adaptations at http://matatk.agrip.org.uk/articles/the-promise-of-personalised-interfaces/<br />
* Type of session: short informal talk to introduce a few key adaptations, followed by open discussion.<br />
* Goals: (1) Raise awareness of some ways that interfaces and content can be adapted that can help a wide range of people; (2) Seek ideas as to how these sorts of adaptations could be applied in the context of the web (standards, content, browsers, ...)<br />
* Shortname: TBC<br />
* Additional speakers/panelists: TBC<br />
* Apply to be a #Public_Breakout<br />
* Timeslot: 12pm-5pm UTC<br />
* Days on which the breakout can be run: Monday, Tuesday, Thursday, Friday<br />
<br />
=== Smart Cities ===<br />
* Proposer: [[User:Ashimura|Kazuyuki Ashimura]] ([[User talk:Ashimura|talk]]) 01:49, 19 October 2020 (UTC)<br />
* Email address of proposer: ashimura@w3.org<br />
* Summary (one-sentence or so): Based on the discussion during the [https://www.w3.org/WoT/ws-2019/minutes.html#day2-item02 Second WoT Workshop in Munich], [https://w3c.github.io/wot-usecases/#smart-city use cases on Smart Cities] have been proposed to the Web of Thing IG. However, we need to collect even more use cases and system implmentation experiences of actual smart cities from all over the world, because Smart Cities topic depends on the cities' location, culture, etc., and include various sub-systems from many different vendors. So we'd like to hold discussion on the possible standardization for Smart Cities before forming a concrete discussion group within W3C.<br />
* Type of session: Background description + Open discussion<br />
* Goals:<br />
** identify the stakeholders of Smart Cities standardization to drive the development of Web standards aligned with the real needs of Smart Cities<br />
** and then discuss how to proceed including the possibility of holding a dedicated Workshop and forming a dedicated IG<br />
* shortname: smart-cities<br />
* [optional] Additional speakers/panelists: tbd<br />
* [optional] Apply to be a [[#Public_Breakout]] (breakouts open to the world at large, not just the W3C community)=== Smart Cities ===<br />
* Proposer: [[User:Ashimura|Kazuyuki Ashimura]] ([[User talk:Ashimura|talk]]) 01:52, 19 October 2020 (UTC)<br />
* Email address of proposer: ashimura@w3.org<br />
* Summary (one-sentence or so): Based on the discussion during the [https://www.w3.org/WoT/ws-2019/minutes.html#day2-item02 Second WoT Workshop in Munich], [https://w3c.github.io/wot-usecases/#smart-city use cases on Smart Cities] have been proposed to the Web of Thing IG. However, we need to collect even more use cases and system implmentation experiences of actual smart cities from all over the world, because Smart Cities topic depends on the cities' location, culture, etc., and include various sub-systems from many different vendors. So we'd like to hold discussion on the possible standardization for Smart Cities before forming a concrete discussion group within W3C.<br />
* Type of session: Background description + Open discussion<br />
* Goals:<br />
** identify the stakeholders of Smart Cities standardization to drive the development of Web standards aligned with the real needs of Smart Cities<br />
** and then discuss how to proceed including the possibility of holding a dedicated Workshop and forming a dedicated IG<br />
* shortname: smart-cities<br />
* [optional] Additional speakers/panelists: tbd<br />
* [optional] Apply to be a [[#Public_Breakout]] (breakouts open to the world at large, not just the W3C community)<br />
* [optional] Timeslot: 12pm-4pm UTC (but need to avoid conflicts with the related sessions, e.g., [https://www.w3.org/wiki/TPAC/2020/SessionIdeas#Web_of_Things_.28WoT.29_Applications_and_Use_Cases WoT Applications and Use Cases], [https://www.w3.org/wiki/TPAC/2020/SessionIdeas#Video_Metadata_For_Moving_Objects_.26_Sensors_On_The_Web_.28WebVMT.29 Video metadata] and [https://www.w3.org/wiki/TPAC/2020/SessionIdeas#Voice_Agents Voice Agents]) - Detail on preferred date/time below<br />
** Monday, 12pm-1pm UTC<br />
** Monday, 2pm-3pm UTC<br />
** Tuesday, 12pm-1pm UTC<br />
** Tuesday, 2pm-3pm UTC<br />
** Thursday, 2pm-3pm UTC<br />
** Friday, 12pm-1pm UTC<br />
** Friday, 1pm-2pm UTC<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Thursday, Friday<br />
<br />
* [optional] Timeslot: 12pm-4pm UTC (but need to avoid conflicts with the related sessions, e.g., [https://www.w3.org/wiki/TPAC/2020/SessionIdeas#Web_of_Things_.28WoT.29_Applications_and_Use_Cases WoT Applications and Use Cases], [https://www.w3.org/wiki/TPAC/2020/SessionIdeas#Video_Metadata_For_Moving_Objects_.26_Sensors_On_The_Web_.28WebVMT.29 Video metadata] and [https://www.w3.org/wiki/TPAC/2020/SessionIdeas#Voice_Agents Voice Agents]) - Detail on preferred date/time below<br />
** Monday, 12pm-1pm UTC<br />
** Monday, 2pm-3pm UTC<br />
** Tuesday, 12pm-1pm UTC<br />
** Tuesday, 2pm-3pm UTC<br />
** Thursday, 2pm-3pm UTC<br />
** Friday, 12pm-1pm UTC<br />
** Friday, 1pm-2pm UTC<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Thursday, Friday<br />
<br />
=== Voice Agents ===<br />
* Proposer: [[User:Ashimura|Kazuyuki Ashimura]] ([[User talk:Ashimura|talk]]) 01:52, 19 October 2020 (UTC)<br />
* Email address of proposer: ashimura@w3.org<br />
* Summary (one-sentence or so): During [https://www.w3.org/2019/09/18-voice-minutes.html one of the breakout sessions at TPAC 2019] in Fukuoka, there was discusison about needs for improved voice agents for web services. And we'd like to proceed with the preparation for the expectd [W3C Workshop on User-friendly Smart Agents on the Web](https://github.com/w3c/strategy/issues/221)<br />
* Type of session: Background description + Open discussion<br />
* Goals:<br />
** identify people interested as (1) the expected Program Committee for the workshop and (2) participants in the workshop<br />
** also would get insights for the potential agenda for the expected workshop<br />
* shortname: voice-agents<br />
* [optional] Additional speakers/panelists: tbd<br />
* [optional] Apply to be a [[#Public_Breakout]] (breakouts open to the world at large, not just the W3C community)<br />
* [optional] Timeslot: 12pm-4pm UTC (but need to avoid conflicts with the related sessions, e.g., [https://www.w3.org/wiki/TPAC/2020/SessionIdeas#Web_of_Things_.28WoT.29_Applications_and_Use_Cases WoT Applications and Use Cases], [https://www.w3.org/wiki/TPAC/2020/SessionIdeas#Video_Metadata_For_Moving_Objects_.26_Sensors_On_The_Web_.28WebVMT.29 Video metadata] and [https://www.w3.org/wiki/TPAC/2020/SessionIdeas#Smart_Cities Smart Cities]) - Detail on preferred date/time below<br />
** Monday, 12pm-1pm UTC<br />
** Monday, 2pm-3pm UTC<br />
** Tuesday, 12pm-1pm UTC<br />
** Tuesday, 2pm-3pm UTC<br />
** Thursday, 2pm-3pm UTC<br />
** Friday, 12pm-1pm UTC<br />
** Friday, 1pm-2pm UTC<br />
* [optional] constraints on days in which the breakout can run: Monday, Tuesday, Thursday, Friday<br />
<br />
=== Cloud Gaming on the Web ===<br />
* Proposer: [[User:Lzm|Zhaoming Li]] ([[User talk:Lzm|talk]]) 08:10, 19 October 2020 (UTC)<br />
* Email address of proposer: lizhaoming@tingyutech.com<br />
* Summary: This session will include a basic introduction about cloud gaming, why cloud gaming is powerful, how cloud gaming run on the web, how can the web help cloud gaming, and shortages we currently have on the browser.<br />
* Type of session: talk and open discussion<br />
* Goals: We are looking to start a community group to work on providing a fast and stable user experience of cloud gaming.<br />
* shortname: cloudgaming<br />
* Additional speakers/panelists: Qingqian Tao, Alicia Nie<br />
<br />
=== W3C 2020: Living Standards and Reviews ===<br />
<br />
* Proposer: PLH<br />
* Email address of proposer: plh@w3.org<br />
* Summary: This session will decrypt the new W3C Process to helps editors and participants find their ways. It will also give the latest information on how to do wide reviews and transitions.<br />
* Type of session: talk and open discussion<br />
* Goals: Avoid getting lost into the W3C Process maze.<br />
* shortname: w3cprocess<br />
* Additional speakers/panelists: none</div>Plehegarhttps://www.w3.org/wiki/index.php?title=DocumentReview&diff=112483DocumentReview2020-10-01T21:54:37Z<p>Plehegar: Re-enable /Guide redirect</p>
<hr />
<div>This document has been moved to [https://www.w3.org/Guide/documentreview/ https://www.w3.org/Guide/documentreview/].</div>Plehegarhttps://www.w3.org/wiki/index.php?title=TPAC/2020/GroupMeetings&diff=112481TPAC/2020/GroupMeetings2020-10-01T18:00:46Z<p>Plehegar: TT/CSS agenda discussion</p>
<hr />
<div>==Introduction ==<br />
<br />
Due to COVID-19, [https://www.w3.org/2020/10/TPAC/ TPAC 2020] will be a fully remote event. The usual TPAC objectives remain:<br />
<br />
* Groups schedule a Group meeting to which observers are invited so that members of our community have the opportunity to see the work of the W3C groups.<br />
* Groups schedule joint meetings with other Groups<br />
* Breakout sessions will discuss specific topics of interest.<br />
<br />
All meetings will be held on-line ("virtually"). Because we will not be all together in the same timezone, scheduling the meetings has new challenges. However, we also will not try to force all of the above into just five days.<br />
<br />
[https://www.w3.org/2020/10/TPAC/ TPAC 2020] will spread over several weeks:<br />
<br />
* September and October: WG/IG/BG/CG meetings, inviting observers<br>['''Not overlapping TPAC breakout week 26â30 October''' as the main objective of that week is to focus on breakout sessions, connect with people and work on new ideas. The objective is to give the participants the time and the chance to fully participate in this week without having to attend any other W3C Meetings that same week.] <br />
* 12-16 October: Joint Group Meetings (please reserve this week for that purpose)<br />
* 26-30 October: Breakout sessions (please reserve the "golden hour" of 1400-1500 UTC each day of this week for this activity)<br />
<br />
Those who are eligible to attend the group and joint meetings are:<br />
<br />
* a participant in a W3C Working, Interest, Business or Community Group scheduled to meet for TPAC<br />
* a W3C Member Advisory Committee Representative<br />
* a participant on the Advisory Board or the TAG<br />
* an employee of a W3C member organization<br />
* an invited Guest<br />
* a W3C Evangelist<br />
* W3C staff or W3C Office chapter<br />
<br />
'''Observer and Guest Attendance:''' Eligible participants may request to attend as an Observer via the registration form. <br /><br />
'''Community Group Participants:''' Any participant of a CG scheduled to meet will be able to attend other group meetings if one of the above criteria is fulfilled.<br />
<br />
'''Group chairs, please read the details below and fill in the appropriate table(s). <br />'''<br />
There are three different tables for the following meetings:<br />
* Working Group [WG], Interest Group [IG], Business Group [BG] Meetings<br />
* Community Group [CG] Meetings<br />
* Joint Group Meetings<br />
<br />
Please indicate the meeting status codes when you will fill in the tables:<br/><br />
* CONFIRMED [The meeting is totally confirmed]<br />
* TENTATIVE [Set of dates chosen but the meeting is not 100% confirmed]<br />
* ON HOLD [Possible dates and times; we are still narrowing down]<br />
<br />
Note that only the groups with the [CONFIRMED] status will be added to the global meeting schedule [1] and to the registration form. Please do your best to confirm your meetings before registration opens on 8 September.<br />
However, if you are unable to confirm your meeting before registration opens, it will be added to the schedule and the registration form later when you do confirm.<br />
<br />
Please do your best to select times that will allow a broad participation among meeting attendees and observers all around the globe.<br />
<br />
== WG/IG/BG Group Meetings details ==<br />
<br />
This year, the groups will organize their distributed meetings and decide whether they want to appear on the global meeting schedule W3C will publish. The groups decide when and for how long they want to meet.<br/><br />
While the schedule will be public, the specific teleconference details should remain Member-only.<br/><br />
<br />
{| class="wikitable"<br />
|-<br />
! '''Meeting status code - Choose one (see [[#fn-status|below]])''' !! '''Chair name''' !! '''Group name''' !! '''Date and times in [https://www.timeanddate.com/worldclock/converter.html?iso=20201001T140000&p1=tz_gmt&p2=43&p3=33&p4=248&p5=195&p6=224 UTC]''' !! '''With which groups there should be no overlap''' !! '''Link to agenda''' || '''Link to Meeting coordinates (service, code, password)'''<br />
|-<br />
| CONFIRMED<br>TENTATIVE<br>ON HOLD || || || || || || [https://lists.w3.org/Archives/Member/ Member-only archive]<br />
|-<br />
| TENTATIVE || [mailto:k@w3.org Coralie Mercier] & [mailto:lwatson@tetralogical.com LĂŠonie Watson] & [mailto:tsiegman@wiley.com Tzviya Siegman] || Joint [https://www.w3.org/community/idcg/ Inclusion & Diversity CG] and [https://www.w3.org/community/pwe/ Positive Work Environment CG] meeting || [https://www.timeanddate.com/worldclock/converter.html?iso=20201015T1400000&p1=43&p2=33&p3=248&p4=195&p5=224 October 13 or 15 at 2PM UTC] || || || <br />
|-<br />
| CONFIRMED || [mailto:ylafon.w3.org Yves Lafon] & [mailto:wilaw@akamai.com Will Law] & [mailto:jib@mozilla.com Jan-Ivar Bruaroey] || WebTransport WG || [https://www.timeanddate.com/worldclock/converter.html?iso=20201019T160000&p1=43&p2=33&p3=248&p4=195&p5=224 Oct 19, 16:00-18:00 UTC], [https://www.timeanddate.com/worldclock/converter.html?iso=20201021T160000&p1=43&p2=33&p3=248&p4=195&p5=224 Oct 21, 16:00-18:00 UTC] || WebRTC WG || || <br />
|-<br />
| CONFIRMED || [mailto:jeff@w3.org Jeff Jaffe] || Advisory Committee || [https://www.timeanddate.com/worldclock/converter.html?iso=20201020T133000&p1=43&p2=33&p3=248&p4=195&p5=224 20 Oct 1330-1500 UTC] || || || <br />
|-<br />
| CONFIRMED || stearns@adobe.com Rossen.Atanassov@microsoft.com || CSS WG || October 19, 20 20:00-23:00. Oct 22, 23 14:00-17:00 || || [https://wiki.csswg.org/planning/tpac-2020 Agenda] ||<br />
|-<br />
| CONFIRMED || [mailto:brent.zundel@evernym.com Brent Zundel]<br/>[mailto:daniel.burnett@entethalliance.org Dan Burnett] || Decentralized Identifiers WG || [https://www.timeanddate.com/worldclock/fixedtime.html?msg=TPAC+DID+WG+Day+1&iso=20201102T10&p1=43&ah=3&am=30 November 2, 14 - 17:30 UTC]<br/>[https://www.timeanddate.com/worldclock/fixedtime.html?msg=TPAC+DID+WG+Day+2&iso=20201103T12&p1=43&ah=3&am=30 November 3, 16 - 19:30 UTC]<br/>[https://www.timeanddate.com/worldclock/fixedtime.html?msg=TPAC+DID+WG+Day+3&iso=20201104T10&p1=43&ah=3&am=30 November 4, 14 - 17:30 UTC]<br/>[https://www.timeanddate.com/worldclock/fixedtime.html?msg=TPAC+DID+WG+Day+4&iso=20201105T12&p1=43&ah=3&am=30 November 5, 16 - 19:30 UTC]|| WebAuthn WG || [https://www.w3.org/2019/did-wg/Meetings/F2F/2020.11.VirtualTPAC.html Meeting Information Page] || [https://lists.w3.org/Archives/Member/member-did-wg/2020Jun/0000.html Meeting Link]<br />
|-<br />
| CONFIRMED || anssi.kostiainen@intel.com || [https://www.w3.org/das/ Devices and Sensors WG] || October 22 5:00 UTC, October 23 5:00 UTC || Second Screen WG/CG, WebML CG || [https://github.com/w3c/devicesensors-wg/issues/31 Agenda] ||<br />
|-<br />
| CONFIRMED || [mailto:wendy.reid@rakuten.com Wendy Reid] || EPUB 3 WG || [https://www.timeanddate.com/worldclock/fixedtime.html?msg=EPUB+3+vF2F%2C+North-America+%2F+East+Asia&iso=20201023T09&p1=248&ah=3&am=30 October 23 00:00 UTC - 03:30 UTC] &amp; [https://www.timeanddate.com/worldclock/fixedtime.html?msg=EPUB+3+vF2F+Meeting%2C+North-America+%2F+Europe&iso=20201023T10&p1=43&ah=3&am=30 October 23 14:00 UTC - 17:30 UTC] || CSS WG, APA WG || || [https://www.w3.org/publishing/groups/epub-wg/Meetings/F2F/2020_October Meeting Info]<br />
|-<br />
| CONFIRMED || addison@amazon.com || Internationalization (I18N) WG || 20-October and 22-October @ 1500-1700 || || https://www.w3.org/wiki/I18N_2020_TPAC ||<br />
|-<br />
| CONFIRMED || [mailto:chris.needham@bbc.co.uk Chris Needham]<br/>[mailto:pal@sandflow.com Pierre-Anthony Lemieux]<br/>[mailto:Tatsuya.Igarashi@sony.com Tatsuya Igarashi] || Media & Entertainment IG || [https://www.timeanddate.com/worldclock/converter.html?iso=20201019T130000&p1=43&p2=33&p3=248&p4=195&p5=224 October 19 @ 1300-1400] and [https://www.timeanddate.com/worldclock/converter.html?iso=20201021T050000&p1=43&p2=33&p3=248&p4=195&p5=224 October 21 @ 0500-0700] || TTWG WICG, CSS WG, Media WG, WoT IG/WG || ||<br />
|-<br />
| CONFIRMED || anssi.kostiainen@intel.com || [https://www.w3.org/2014/secondscreen/ Second Screen WG/CG] || October 20 5:00 UTC, October 21 5:00 UTC || DAS WG, WebML CG, Media & Entertainment IG, Media WG || [https://github.com/w3c/secondscreen-wg/issues/1 Agenda] ||<br />
|-<br />
| CONFIRMED || wseltzer@w3.org || Web Advertising BG|| [https://github.com/w3c/web-advertising/blob/master/meetings/TPAC2020.md October 21, 22 1500-1900 UTC] || PrivacyCG, PING, WebAppSec || [https://github.com/w3c/web-advertising/blob/master/meetings/TPAC2020.md agenda draft] ||<br />
|-<br />
| CONFIRMED || lwatson@tetralogical.com mcaceres@mozilla.com || WebApps WG || [https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020&month=10&day=19&hour=21&min=0&sec=0&p1=152&p2=137&p3=179&p4=136&p5=33 9pm - 11pm UTC October 19] || || ||<br />
|-<br />
| CONFIRMED || [mailto:michael.mccool@intel.com Michael McCool]<br/>[mailto:sebastian.kaebisch@siemens.com Sebastian Kaebisch] || Web of Things (WoT) WG/IG || Plugfest: [https://www.timeanddate.com/worldclock/converter.html?iso=20200928T130000&p1=43&p2=33&p3=248&p4=195&p5=224 Sept28-Oct 2 @ 1300-1400]<br/><br/>vF2F: [https://www.timeanddate.com/worldclock/converter.html?iso=20201005T120000&p1=43&p2=33&p3=248&p4=195&p5=224 Oct 5, 7, 20, 21, 22 @ 1200-1500] ||JSON-LD WG, MEIG, PING, Service Workers WG, Web and Networks IG, DAS WG, TAG, APA WG || https://www.w3.org/WoT/IG/wiki/F2F_meeting,_October_2020 ||<br />
|-<br />
| CONFIRMED || njansma@akamai.com yoavweiss@google.com || Web Performance WG || October 19 to 22 (over 4 days) @ 1600-1900 || || ||<br />
|-<br />
| CONFIRMED || [mailto:w3@stormglass.consulting Nick Telford-Reed] || Web Payments WG || October 19-22 3-5pm UTC (TBC) || Web Authentication WG (at least one day)|| ||<br />
|-<br />
| CONFIRMED || Bernard.Aboba@microsoft.com hta@google.com jib@mozilla.org || WEBRTC WG || October 20, 22 3-5 PM UTC || Media WG, Media & Entertainment IG, WebTransport WG|| ||<br />
<br />
|-<br />
| CONFIRMED || [mailto:peter.winzell@volvocars.com Peter Winzell]<br />[mailto:patrick.luennemann@carmeq.com Patrick Luennemann] || Automotive WG & Automotive/Transportation BG || 12-15-October 15-17 UTC || || ||<br />
<br />
|-<br />
| CONFIRMED || [mailto:shiohama@mediado.jp Daihei Shiohama]<br />[mailto:lmccloy-kelley@penguinrandomhouse.com Liisa McCloy-Kelley]<br />[mailto:cristina.mussinelli@fondazionelia.org Cristina Mussinelli] || Publishing BG || 13 October 17:00-18:30 - 14 October 02:00 - 03:30 UTC || || ||<br />
<br />
|-<br />
| CONFIRMED || [mailto:ij@w3.org Ian Jacobs] || Web Payment Security IG || 6-7-October 2-4pm UTC || || ||<br />
<br />
|-<br />
| TENTATIVE || Ada Rose Cannon (Samsung), AyĹegĂźl YĂśnet (Microsoft) and Chris Wilson (Google) || Immersive-web WG || 13-15 October, 2h each ([https://www.w3.org/2020/05/26-immersive-web-minutes.html#t01 ref]) || || || <br />
<br />
|-<br />
| CONFIRMED || John Fontana (Yubico), Anthony Nadalin (IE)|| WebAuthn WG || 14 October, 1hr 1900 UTC || || || <br />
|-<br />
| CONFIRMED || smcgruer@chromium.org || WPT (web-platform-tests) || October 19 14:00-17:30, October 21 14:00-17:30 || || [https://docs.google.com/document/d/1XhUwVbitdV03eX2GefmokCliWjQdAxBgblwITwNqsgc/edit?ts=5f501f7f Agenda] ||<br />
|-<br />
| CONFIRMED || Christine Runnegar, Pete Snyder || Privacy IG (PING) || 15 October, 1600-1700 UTC || || Routine PING meeting || [https://www.w3.org/Privacy/IG/ Coordinates]<br />
|-<br />
| ON HOLD || Christine Runnegar, Pete Snyder || Privacy IG (PING) || 23 October, 1600-1700 UTC || || How to do a review || [https://www.w3.org/Privacy/IG/ Coordinates]<br />
|-<br />
|}<br />
<br />
== CG Group Meetings details ==<br />
<br />
Community Groups will be able to meet during the Fall 2020 TPAC event. The groups will organize their distributed meetings and decide whether they want to appear on the global meeting schedule we will publish<br/> <br />
Registered participants in W3C Community Groups may participate in their CG meeting. See the above participation rules for the attendance of any other meetings.<br />
<br />
CGs Chairs who can not edit this page should contact [mailto:w3t-tpregister@w3.org Events Team] stating their username . Access will be given.<br />
<br />
{| class="wikitable"<br />
|-<br />
! '''Meeting status code - Choose one (see [[#fn-status|below]])''' !! '''Chair name''' !! '''Group name''' !! '''Date and times in [https://www.timeanddate.com/worldclock/converter.html?iso=20201001T140000&p1=tz_gmt&p2=43&p3=33&p4=248&p5=195&p6=224 UTC]''' !! '''With which groups there should be no overlap''' !! '''Link to agenda''' !! '''Link to Meeting coordinates (service, code, password)'''<br />
|-<br />
| CONFIRMED<br>TENTATIVE<br>ON HOLD || || || || || || [https://lists.w3.org/Archives/ archive]<br />
|-<br />
| CONFIRMED || [https://www.researchgate.net/profile/Georg_Schneider3 Georg Ferdinand Schneider]<br/> [https://www.researchgate.net/profile/Dr_Kris_Mcglinn Kris McGlinn] [https://www.researchgate.net/profile/Mads_Holten_Rasmussen Mads Holten Rasmussen]<br/> [https://www.researchgate.net/profile/Maxime_Lefrancois2 Maxime Lefrancois]<br/> || [https://www.w3.org/community/lbd/ Linked Building Data CG] || [https://www.timeanddate.com/worldclock/fixedtime.html?msg=TPAC+2020+W3C+LBD+CG+Group+Call&iso=20201013T17&p1=37&ah=1&am=30 13 October 2020, 15:00-16:30@UTC (17:00-18:30@CEST/ 16:00-17:30@BST/ 8:00-9:30@PDT)] || WoT IG/WG || tbd || tbd<br />
|-<br />
| TENTATIVE || padenot@mozilla.com,matthew.paradis@bbc.co.uk || Audio CG || October 22 @ 16:00 || TTWG WICG, CSS WG, Media WG, WoT IG/WG || ||<br />
|-<br />
| ON HOLD || reillyg@google.com || Web Bluetooth CG || October 19 to 23 (TBD) || WICG || || <br />
|-<br />
| CONFIRMED || kimdhamilton@gmail.com || Credentials CG || October 14 15:00-16:00 UTC || || || <br />
|-<br />
|-<br />
| CONFIRMED || tomgreenaway@google.com, noelm@fb.com || Web Games CG || October 20 10:00 UTC || || || <br />
|-<br />
| CONFIRMED || yoav@yoav.ws, kleber@google.com, a.blanchard@criteo.com || WICG - TURTLEDOVE + SPARROW proposals || October 13 15:00 UTC || || || <br />
|-<br />
| CONFIRMED || yoav@yoav.ws, csharrison@google.com || WICG - Conversion measurement proposal || October 13 16:00 UTC || || || <br />
|-<br />
| CONFIRMED || yoav@yoav.ws, reillyg@google.com || WICG - Idle detection, Serial, WebHID, WebUSB proposals || October 13 17:00 UTC || || || <br />
|-<br />
| TENTATIVE || dahl@conversational-technologies.com, marco@kerwitz.com,dirk.schnelle@jvoicexml.org,brian.susko@gmail.com || Voice Interaction CG || October 21 15:00 UTC || || || <br />
|-<br />
| CONFIRMED || eric@alexandriaconsulting.com || Human Services Community Group https://www.w3.org/community/humanservices || Wednesday, October 21 18:00-19:30 UTC/14:00-15:30 EDT || || || <br />
|-<br />
| CONFIRMED || anssi.kostiainen@intel.com || [https://webmachinelearning.github.io Machine Learning for the Web Community Group] || Thursday, October 22 14:00-15:00 UTC || || [https://github.com/webmachinelearning/meetings/blob/master/2020-10-22-tpac2020/README.md Agenda] || <br />
|-<br />
| CONFIRMED || dchaves@fi.upm.es, anastasia.dimou@ugent.be || [https://www.w3.org/community/kg-construct/ Knowledge Graph Construction Community Group] || October 12,13,15,16 14:00-16:00 (UTC+2) || || || <br />
|-<br />
| CONFIRMED || angelli.laq@alibaba-inc.com || [https://www.w3.org/community/miniapps/ MiniApps Ecosystem Community Group] || October 15 12:00-14:00 || || ||<br />
|-<br />
| TENTATIVE || gwhitworth@salesforce.com || Open UI || TBD || || || <br />
|-<br />
|}<br />
<br />
== Joint Group meetings - Week of 12-16 October ==<br />
The joint meetings could be organized in a single week during the week of the 12-16 October.<br/><br />
As for the group meetings, observers will be allowed.<br/><br />
<br />
Group Chairs, <br />
please coordinate with the groups you would like to meet with and fill in the following table before '''Thursday 13 August'''. <br />
<br />
{| class="wikitable"<br />
|-<br />
! '''Meeting status code - Choose one (see [[#fn-status|below]])''' !! '''Chair names''' !! '''Group names''' !! '''Date and times in [https://www.timeanddate.com/worldclock/converter.html?iso=20201001T140000&p1=tz_gmt&p2=43&p3=33&p4=248&p5=195&p6=224 UTC]''' !! '''With which other groups there should be no overlap''' !! '''Link to agenda''' !! '''Link to Meeting coordinates (service, code, password)'''<br />
|-<br />
| CONFIRMED<br>TENTATIVE<br>ON HOLD || || || || || || [https://lists.w3.org/Archives/Member/ Member-only archive]<br />
|-<br />
| CONFIRMED || TTWG: Gary Katsevman, Nigel Megitt, Media WG: Jer Noble, Mounir Lamouri, MEIG: Chris Needham, Pierre-Anthony Lemieux || TTWG, MEIG, MediaWG || [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20201015T14&p1=1440 2020-10-15 1400-1600 UTC] || || [https://www.w3.org/2011/webtv/wiki/TPAC_2020_meeting#Thursday_15_October_2020:_Timed_Text_WG_.2F_Media_WG_.2F_Media_.26_Entertainment_IG_Joint_Meeting Agenda] || The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|-<br />
| ON HOLD || (to be chosen) || TTWG - CSS-WG || [https://lists.w3.org/Archives/Public/public-tt/2020Oct/0000.html (under discussion)] || || (under development) || (not yet defined)<br />
|-<br />
| ON HOLD (unlikely) || (to be chosen) || TTWG - ADCG || (under discussion) || || (under development) || (not yet defined)<br />
|-<br />
| CONFIRMED || (to be chosen) || APA, CSS || [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20201014T15&p1=1440 Wednesday, Oct 14, 15:00â16:00 UTC] || || [https://www.w3.org/WAI/APA/wiki/Meetings/TPAC_2020#Groups_to_coordinate_with Agenda] || The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|-<br />
| CONFIRMED || (to be chosen) || APA, Timed Text, Silver || [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20201013T14&p1=1440 Tuesday, Oct. 13 from 14:00-15:00 UTC] || || [https://www.w3.org/WAI/APA/wiki/Meetings/TPAC_2020#Groups_to_coordinate_with Agenda]) || The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|-<br />
| CONFIRMED || WEBRTC WG: Bernard.Aboba@microsoft.com hta@google.com jib@mozilla.org || WEBRTC, MEIG || Friday, Oct 16, 15:00-16:00 UTC || || [https://www.w3.org/2011/webtv/wiki/TPAC_2020_meeting#Friday_16_October_2020:_WebRTC_WG_.2F_Media_.26_Entertainment_IG_Joint_Meeting Agenda] || The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|-<br />
| ON HOLD || (to be chosen) || APA, HTML, TAG, WICG || (under discussion) || || (under development) || (not yet defined)<br />
|-<br />
| CONFIRMED || (to be chosen) || APA, EPub3, Silver || [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20201015T15&p1=1440 Thursday, Oct 15, 15:00â16:00 UTC] || || [https://www.w3.org/WAI/APA/wiki/Meetings/TPAC_2020#Groups_to_coordinate_with Agenda] || (The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom16meeting<br />
|-<br />
| CONFIRMED || (to be chosen) || APA, Immersive Web, Silver || [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20201015T16 Thursday, Oct. 15 from 16:00â17:00pm UTC] || || [https://www.w3.org/WAI/APA/wiki/Meetings/TPAC_2020#Groups_to_coordinate_with Agenda] || The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|-<br />
| CONFIRMED || WEBRTC WG: Bernard.Aboba@microsoft.com hta@google.com jib@mozilla.org || APA, WebRTC || Tuesday, October 13, 2020, 3 - 4 PM UTC || || [https://www.w3.org/WAI/APA/wiki/Meetings/TPAC_2020#Groups_to_coordinate_with Agenda] || The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|-<br />
| ON HOLD || (to be chosen) || PING, Privacy CG || (under discussion) || || (under development) || (not yet defined)<br />
|-<br />
| CONFIRMED || WEBRTC WG: Bernard.Aboba@microsoft.com hta@google.com jib@mozilla.org || PING, WEBRTC WG || Thursday, October 15, 2020, 3 - 4 PM UTC || || (under development) || The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|-<br />
| Confirmed || [mailto:Brent.Bakken@Pearson.com Brent Bakken] || ARIA, EO || Oct 15, 4:00 PM - 5:45 PM UTC || || [https://www.w3.org/WAI/ARIA/wiki/Meetings/APG_EO_Joint Agenda] || [https://www.w3.org/2017/08/telecon-info_aria-tpac Zoom Information]<br />
|-<br />
| CONFIRMED || [mailto:michael.mccool@intel.com Michael McCool]<br/>(to be chosen) || APA, WoT || [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20201014T13&p1=1440 Wednesday, Oct. 14 at 13:00â14:00 UTC] || || (under development) || The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|-<br />
| TENTATIVE || [mailto:michael.mccool@intel.com Michael McCool]<br/>[mailto:brent.zundel@evernym.com Brent Zundel]<br/>[mailto:daniel.burnett@entethalliance.org Daniel Burnett] || DID, WoT || October 13, 11:00am ET || || (under development) || ([https://lists.w3.org/Archives/Member/member-did-wg/2020Jun/0000.html Part of the regular DID WG Weekly call])<br />
|-<br />
| CONFIRMED || [mailto:michael.mccool@intel.com Michael McCool]<br/> [mailto:sudeep.divakaran@intel.com Sudeep Divakaran] || W&N IG, WoT <br />
|| [https://www.timeanddate.com/worldclock/fixedtime.html?msg=W3C+W%26N+and+WoT+Joint+Meeting&iso=20201015T13&p1=1440&ah=1&am=30 Thursday Oct 15 @ 13:00-14:30 UTC] || MEIG,<br/> Web Transport IG,<br/> Pub IG || [https://github.com/w3c/wot/issues/934 agenda] || [https://github.com/w3c/wot/issues/934 logistics] The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|-<br />
| ON HOLD || Aysegul Yonet, Ada Rose Cannon, Chris Wilson, Correntin Wallez, Dean Jackson || Immersive Web, WebGPU || (under discussion) || || (under development) || (not yet defined)<br />
|-<br />
| TENTATIVE || John Fontana || WPSIG and Web Authn WG and CG || 7 October 30min.(under discussion) || || (under development) || The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|-<br />
| TENTATIVE || John Fontana || Web Authn WG and Web Payments || 19 and 20 October || || (under development) || The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|-<br />
| CONFIRMED || MEIG: Chris Needham, Pierre-Anthony Lemieux, Color on the Web: Chris Lilley || MEIG, Color on the Web CG || [https://www.timeanddate.com/worldclock/converter.html?iso=20201019T140000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136 2020-10-19 @ 1400-1500 UTC] || || [https://www.w3.org/2011/webtv/wiki/TPAC_2020_meeting#Monday_19_October_2020:_Media_.26_Entertainment_IG_.2F_Color_on_the_Web_CG_Joint_Meeting Agenda] || The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|}<br />
<br />
<div id="fn-status"><br />
'''Meeting status codes''':<br />
Please choose one code below:<br />
<br />
* CONFIRMED - The meeting is totally confirmed<br />
* TENTATIVE - Set of dates chosen but the meeting is not 100% confirmed<br />
* ON HOLD - Possible dates and times; we are still narrowing down<br />
</div><br />
<br />
== Contacts ==<br />
If you need any assistance with planning your meeting, the [mailto:w3t-tpregister@w3.org Events Team] is here to help you.</div>Plehegarhttps://www.w3.org/wiki/index.php?title=TPAC/2020/GroupMeetings&diff=112480TPAC/2020/GroupMeetings2020-10-01T17:57:47Z<p>Plehegar: CSS Agenda</p>
<hr />
<div>==Introduction ==<br />
<br />
Due to COVID-19, [https://www.w3.org/2020/10/TPAC/ TPAC 2020] will be a fully remote event. The usual TPAC objectives remain:<br />
<br />
* Groups schedule a Group meeting to which observers are invited so that members of our community have the opportunity to see the work of the W3C groups.<br />
* Groups schedule joint meetings with other Groups<br />
* Breakout sessions will discuss specific topics of interest.<br />
<br />
All meetings will be held on-line ("virtually"). Because we will not be all together in the same timezone, scheduling the meetings has new challenges. However, we also will not try to force all of the above into just five days.<br />
<br />
[https://www.w3.org/2020/10/TPAC/ TPAC 2020] will spread over several weeks:<br />
<br />
* September and October: WG/IG/BG/CG meetings, inviting observers<br>['''Not overlapping TPAC breakout week 26â30 October''' as the main objective of that week is to focus on breakout sessions, connect with people and work on new ideas. The objective is to give the participants the time and the chance to fully participate in this week without having to attend any other W3C Meetings that same week.] <br />
* 12-16 October: Joint Group Meetings (please reserve this week for that purpose)<br />
* 26-30 October: Breakout sessions (please reserve the "golden hour" of 1400-1500 UTC each day of this week for this activity)<br />
<br />
Those who are eligible to attend the group and joint meetings are:<br />
<br />
* a participant in a W3C Working, Interest, Business or Community Group scheduled to meet for TPAC<br />
* a W3C Member Advisory Committee Representative<br />
* a participant on the Advisory Board or the TAG<br />
* an employee of a W3C member organization<br />
* an invited Guest<br />
* a W3C Evangelist<br />
* W3C staff or W3C Office chapter<br />
<br />
'''Observer and Guest Attendance:''' Eligible participants may request to attend as an Observer via the registration form. <br /><br />
'''Community Group Participants:''' Any participant of a CG scheduled to meet will be able to attend other group meetings if one of the above criteria is fulfilled.<br />
<br />
'''Group chairs, please read the details below and fill in the appropriate table(s). <br />'''<br />
There are three different tables for the following meetings:<br />
* Working Group [WG], Interest Group [IG], Business Group [BG] Meetings<br />
* Community Group [CG] Meetings<br />
* Joint Group Meetings<br />
<br />
Please indicate the meeting status codes when you will fill in the tables:<br/><br />
* CONFIRMED [The meeting is totally confirmed]<br />
* TENTATIVE [Set of dates chosen but the meeting is not 100% confirmed]<br />
* ON HOLD [Possible dates and times; we are still narrowing down]<br />
<br />
Note that only the groups with the [CONFIRMED] status will be added to the global meeting schedule [1] and to the registration form. Please do your best to confirm your meetings before registration opens on 8 September.<br />
However, if you are unable to confirm your meeting before registration opens, it will be added to the schedule and the registration form later when you do confirm.<br />
<br />
Please do your best to select times that will allow a broad participation among meeting attendees and observers all around the globe.<br />
<br />
== WG/IG/BG Group Meetings details ==<br />
<br />
This year, the groups will organize their distributed meetings and decide whether they want to appear on the global meeting schedule W3C will publish. The groups decide when and for how long they want to meet.<br/><br />
While the schedule will be public, the specific teleconference details should remain Member-only.<br/><br />
<br />
{| class="wikitable"<br />
|-<br />
! '''Meeting status code - Choose one (see [[#fn-status|below]])''' !! '''Chair name''' !! '''Group name''' !! '''Date and times in [https://www.timeanddate.com/worldclock/converter.html?iso=20201001T140000&p1=tz_gmt&p2=43&p3=33&p4=248&p5=195&p6=224 UTC]''' !! '''With which groups there should be no overlap''' !! '''Link to agenda''' || '''Link to Meeting coordinates (service, code, password)'''<br />
|-<br />
| CONFIRMED<br>TENTATIVE<br>ON HOLD || || || || || || [https://lists.w3.org/Archives/Member/ Member-only archive]<br />
|-<br />
| TENTATIVE || [mailto:k@w3.org Coralie Mercier] & [mailto:lwatson@tetralogical.com LĂŠonie Watson] & [mailto:tsiegman@wiley.com Tzviya Siegman] || Joint [https://www.w3.org/community/idcg/ Inclusion & Diversity CG] and [https://www.w3.org/community/pwe/ Positive Work Environment CG] meeting || [https://www.timeanddate.com/worldclock/converter.html?iso=20201015T1400000&p1=43&p2=33&p3=248&p4=195&p5=224 October 13 or 15 at 2PM UTC] || || || <br />
|-<br />
| CONFIRMED || [mailto:ylafon.w3.org Yves Lafon] & [mailto:wilaw@akamai.com Will Law] & [mailto:jib@mozilla.com Jan-Ivar Bruaroey] || WebTransport WG || [https://www.timeanddate.com/worldclock/converter.html?iso=20201019T160000&p1=43&p2=33&p3=248&p4=195&p5=224 Oct 19, 16:00-18:00 UTC], [https://www.timeanddate.com/worldclock/converter.html?iso=20201021T160000&p1=43&p2=33&p3=248&p4=195&p5=224 Oct 21, 16:00-18:00 UTC] || WebRTC WG || || <br />
|-<br />
| CONFIRMED || [mailto:jeff@w3.org Jeff Jaffe] || Advisory Committee || [https://www.timeanddate.com/worldclock/converter.html?iso=20201020T133000&p1=43&p2=33&p3=248&p4=195&p5=224 20 Oct 1330-1500 UTC] || || || <br />
|-<br />
| CONFIRMED || stearns@adobe.com Rossen.Atanassov@microsoft.com || CSS WG || October 19, 20 20:00-23:00. Oct 22, 23 14:00-17:00 || || [https://wiki.csswg.org/planning/tpac-2020 Agenda] ||<br />
|-<br />
| CONFIRMED || [mailto:brent.zundel@evernym.com Brent Zundel]<br/>[mailto:daniel.burnett@entethalliance.org Dan Burnett] || Decentralized Identifiers WG || [https://www.timeanddate.com/worldclock/fixedtime.html?msg=TPAC+DID+WG+Day+1&iso=20201102T10&p1=43&ah=3&am=30 November 2, 14 - 17:30 UTC]<br/>[https://www.timeanddate.com/worldclock/fixedtime.html?msg=TPAC+DID+WG+Day+2&iso=20201103T12&p1=43&ah=3&am=30 November 3, 16 - 19:30 UTC]<br/>[https://www.timeanddate.com/worldclock/fixedtime.html?msg=TPAC+DID+WG+Day+3&iso=20201104T10&p1=43&ah=3&am=30 November 4, 14 - 17:30 UTC]<br/>[https://www.timeanddate.com/worldclock/fixedtime.html?msg=TPAC+DID+WG+Day+4&iso=20201105T12&p1=43&ah=3&am=30 November 5, 16 - 19:30 UTC]|| WebAuthn WG || [https://www.w3.org/2019/did-wg/Meetings/F2F/2020.11.VirtualTPAC.html Meeting Information Page] || [https://lists.w3.org/Archives/Member/member-did-wg/2020Jun/0000.html Meeting Link]<br />
|-<br />
| CONFIRMED || anssi.kostiainen@intel.com || [https://www.w3.org/das/ Devices and Sensors WG] || October 22 5:00 UTC, October 23 5:00 UTC || Second Screen WG/CG, WebML CG || [https://github.com/w3c/devicesensors-wg/issues/31 Agenda] ||<br />
|-<br />
| CONFIRMED || [mailto:wendy.reid@rakuten.com Wendy Reid] || EPUB 3 WG || [https://www.timeanddate.com/worldclock/fixedtime.html?msg=EPUB+3+vF2F%2C+North-America+%2F+East+Asia&iso=20201023T09&p1=248&ah=3&am=30 October 23 00:00 UTC - 03:30 UTC] &amp; [https://www.timeanddate.com/worldclock/fixedtime.html?msg=EPUB+3+vF2F+Meeting%2C+North-America+%2F+Europe&iso=20201023T10&p1=43&ah=3&am=30 October 23 14:00 UTC - 17:30 UTC] || CSS WG, APA WG || || [https://www.w3.org/publishing/groups/epub-wg/Meetings/F2F/2020_October Meeting Info]<br />
|-<br />
| CONFIRMED || addison@amazon.com || Internationalization (I18N) WG || 20-October and 22-October @ 1500-1700 || || https://www.w3.org/wiki/I18N_2020_TPAC ||<br />
|-<br />
| CONFIRMED || [mailto:chris.needham@bbc.co.uk Chris Needham]<br/>[mailto:pal@sandflow.com Pierre-Anthony Lemieux]<br/>[mailto:Tatsuya.Igarashi@sony.com Tatsuya Igarashi] || Media & Entertainment IG || [https://www.timeanddate.com/worldclock/converter.html?iso=20201019T130000&p1=43&p2=33&p3=248&p4=195&p5=224 October 19 @ 1300-1400] and [https://www.timeanddate.com/worldclock/converter.html?iso=20201021T050000&p1=43&p2=33&p3=248&p4=195&p5=224 October 21 @ 0500-0700] || TTWG WICG, CSS WG, Media WG, WoT IG/WG || ||<br />
|-<br />
| CONFIRMED || anssi.kostiainen@intel.com || [https://www.w3.org/2014/secondscreen/ Second Screen WG/CG] || October 20 5:00 UTC, October 21 5:00 UTC || DAS WG, WebML CG, Media & Entertainment IG, Media WG || [https://github.com/w3c/secondscreen-wg/issues/1 Agenda] ||<br />
|-<br />
| CONFIRMED || wseltzer@w3.org || Web Advertising BG|| [https://github.com/w3c/web-advertising/blob/master/meetings/TPAC2020.md October 21, 22 1500-1900 UTC] || PrivacyCG, PING, WebAppSec || [https://github.com/w3c/web-advertising/blob/master/meetings/TPAC2020.md agenda draft] ||<br />
|-<br />
| CONFIRMED || lwatson@tetralogical.com mcaceres@mozilla.com || WebApps WG || [https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020&month=10&day=19&hour=21&min=0&sec=0&p1=152&p2=137&p3=179&p4=136&p5=33 9pm - 11pm UTC October 19] || || ||<br />
|-<br />
| CONFIRMED || [mailto:michael.mccool@intel.com Michael McCool]<br/>[mailto:sebastian.kaebisch@siemens.com Sebastian Kaebisch] || Web of Things (WoT) WG/IG || Plugfest: [https://www.timeanddate.com/worldclock/converter.html?iso=20200928T130000&p1=43&p2=33&p3=248&p4=195&p5=224 Sept28-Oct 2 @ 1300-1400]<br/><br/>vF2F: [https://www.timeanddate.com/worldclock/converter.html?iso=20201005T120000&p1=43&p2=33&p3=248&p4=195&p5=224 Oct 5, 7, 20, 21, 22 @ 1200-1500] ||JSON-LD WG, MEIG, PING, Service Workers WG, Web and Networks IG, DAS WG, TAG, APA WG || https://www.w3.org/WoT/IG/wiki/F2F_meeting,_October_2020 ||<br />
|-<br />
| CONFIRMED || njansma@akamai.com yoavweiss@google.com || Web Performance WG || October 19 to 22 (over 4 days) @ 1600-1900 || || ||<br />
|-<br />
| CONFIRMED || [mailto:w3@stormglass.consulting Nick Telford-Reed] || Web Payments WG || October 19-22 3-5pm UTC (TBC) || Web Authentication WG (at least one day)|| ||<br />
|-<br />
| CONFIRMED || Bernard.Aboba@microsoft.com hta@google.com jib@mozilla.org || WEBRTC WG || October 20, 22 3-5 PM UTC || Media WG, Media & Entertainment IG, WebTransport WG|| ||<br />
<br />
|-<br />
| CONFIRMED || [mailto:peter.winzell@volvocars.com Peter Winzell]<br />[mailto:patrick.luennemann@carmeq.com Patrick Luennemann] || Automotive WG & Automotive/Transportation BG || 12-15-October 15-17 UTC || || ||<br />
<br />
|-<br />
| CONFIRMED || [mailto:shiohama@mediado.jp Daihei Shiohama]<br />[mailto:lmccloy-kelley@penguinrandomhouse.com Liisa McCloy-Kelley]<br />[mailto:cristina.mussinelli@fondazionelia.org Cristina Mussinelli] || Publishing BG || 13 October 17:00-18:30 - 14 October 02:00 - 03:30 UTC || || ||<br />
<br />
|-<br />
| CONFIRMED || [mailto:ij@w3.org Ian Jacobs] || Web Payment Security IG || 6-7-October 2-4pm UTC || || ||<br />
<br />
|-<br />
| TENTATIVE || Ada Rose Cannon (Samsung), AyĹegĂźl YĂśnet (Microsoft) and Chris Wilson (Google) || Immersive-web WG || 13-15 October, 2h each ([https://www.w3.org/2020/05/26-immersive-web-minutes.html#t01 ref]) || || || <br />
<br />
|-<br />
| CONFIRMED || John Fontana (Yubico), Anthony Nadalin (IE)|| WebAuthn WG || 14 October, 1hr 1900 UTC || || || <br />
|-<br />
| CONFIRMED || smcgruer@chromium.org || WPT (web-platform-tests) || October 19 14:00-17:30, October 21 14:00-17:30 || || [https://docs.google.com/document/d/1XhUwVbitdV03eX2GefmokCliWjQdAxBgblwITwNqsgc/edit?ts=5f501f7f Agenda] ||<br />
|-<br />
| CONFIRMED || Christine Runnegar, Pete Snyder || Privacy IG (PING) || 15 October, 1600-1700 UTC || || Routine PING meeting || [https://www.w3.org/Privacy/IG/ Coordinates]<br />
|-<br />
| ON HOLD || Christine Runnegar, Pete Snyder || Privacy IG (PING) || 23 October, 1600-1700 UTC || || How to do a review || [https://www.w3.org/Privacy/IG/ Coordinates]<br />
|-<br />
|}<br />
<br />
== CG Group Meetings details ==<br />
<br />
Community Groups will be able to meet during the Fall 2020 TPAC event. The groups will organize their distributed meetings and decide whether they want to appear on the global meeting schedule we will publish<br/> <br />
Registered participants in W3C Community Groups may participate in their CG meeting. See the above participation rules for the attendance of any other meetings.<br />
<br />
CGs Chairs who can not edit this page should contact [mailto:w3t-tpregister@w3.org Events Team] stating their username . Access will be given.<br />
<br />
{| class="wikitable"<br />
|-<br />
! '''Meeting status code - Choose one (see [[#fn-status|below]])''' !! '''Chair name''' !! '''Group name''' !! '''Date and times in [https://www.timeanddate.com/worldclock/converter.html?iso=20201001T140000&p1=tz_gmt&p2=43&p3=33&p4=248&p5=195&p6=224 UTC]''' !! '''With which groups there should be no overlap''' !! '''Link to agenda''' !! '''Link to Meeting coordinates (service, code, password)'''<br />
|-<br />
| CONFIRMED<br>TENTATIVE<br>ON HOLD || || || || || || [https://lists.w3.org/Archives/ archive]<br />
|-<br />
| CONFIRMED || [https://www.researchgate.net/profile/Georg_Schneider3 Georg Ferdinand Schneider]<br/> [https://www.researchgate.net/profile/Dr_Kris_Mcglinn Kris McGlinn] [https://www.researchgate.net/profile/Mads_Holten_Rasmussen Mads Holten Rasmussen]<br/> [https://www.researchgate.net/profile/Maxime_Lefrancois2 Maxime Lefrancois]<br/> || [https://www.w3.org/community/lbd/ Linked Building Data CG] || [https://www.timeanddate.com/worldclock/fixedtime.html?msg=TPAC+2020+W3C+LBD+CG+Group+Call&iso=20201013T17&p1=37&ah=1&am=30 13 October 2020, 15:00-16:30@UTC (17:00-18:30@CEST/ 16:00-17:30@BST/ 8:00-9:30@PDT)] || WoT IG/WG || tbd || tbd<br />
|-<br />
| TENTATIVE || padenot@mozilla.com,matthew.paradis@bbc.co.uk || Audio CG || October 22 @ 16:00 || TTWG WICG, CSS WG, Media WG, WoT IG/WG || ||<br />
|-<br />
| ON HOLD || reillyg@google.com || Web Bluetooth CG || October 19 to 23 (TBD) || WICG || || <br />
|-<br />
| CONFIRMED || kimdhamilton@gmail.com || Credentials CG || October 14 15:00-16:00 UTC || || || <br />
|-<br />
|-<br />
| CONFIRMED || tomgreenaway@google.com, noelm@fb.com || Web Games CG || October 20 10:00 UTC || || || <br />
|-<br />
| CONFIRMED || yoav@yoav.ws, kleber@google.com, a.blanchard@criteo.com || WICG - TURTLEDOVE + SPARROW proposals || October 13 15:00 UTC || || || <br />
|-<br />
| CONFIRMED || yoav@yoav.ws, csharrison@google.com || WICG - Conversion measurement proposal || October 13 16:00 UTC || || || <br />
|-<br />
| CONFIRMED || yoav@yoav.ws, reillyg@google.com || WICG - Idle detection, Serial, WebHID, WebUSB proposals || October 13 17:00 UTC || || || <br />
|-<br />
| TENTATIVE || dahl@conversational-technologies.com, marco@kerwitz.com,dirk.schnelle@jvoicexml.org,brian.susko@gmail.com || Voice Interaction CG || October 21 15:00 UTC || || || <br />
|-<br />
| CONFIRMED || eric@alexandriaconsulting.com || Human Services Community Group https://www.w3.org/community/humanservices || Wednesday, October 21 18:00-19:30 UTC/14:00-15:30 EDT || || || <br />
|-<br />
| CONFIRMED || anssi.kostiainen@intel.com || [https://webmachinelearning.github.io Machine Learning for the Web Community Group] || Thursday, October 22 14:00-15:00 UTC || || [https://github.com/webmachinelearning/meetings/blob/master/2020-10-22-tpac2020/README.md Agenda] || <br />
|-<br />
| CONFIRMED || dchaves@fi.upm.es, anastasia.dimou@ugent.be || [https://www.w3.org/community/kg-construct/ Knowledge Graph Construction Community Group] || October 12,13,15,16 14:00-16:00 (UTC+2) || || || <br />
|-<br />
| CONFIRMED || angelli.laq@alibaba-inc.com || [https://www.w3.org/community/miniapps/ MiniApps Ecosystem Community Group] || October 15 12:00-14:00 || || ||<br />
|-<br />
| TENTATIVE || gwhitworth@salesforce.com || Open UI || TBD || || || <br />
|-<br />
|}<br />
<br />
== Joint Group meetings - Week of 12-16 October ==<br />
The joint meetings could be organized in a single week during the week of the 12-16 October.<br/><br />
As for the group meetings, observers will be allowed.<br/><br />
<br />
Group Chairs, <br />
please coordinate with the groups you would like to meet with and fill in the following table before '''Thursday 13 August'''. <br />
<br />
{| class="wikitable"<br />
|-<br />
! '''Meeting status code - Choose one (see [[#fn-status|below]])''' !! '''Chair names''' !! '''Group names''' !! '''Date and times in [https://www.timeanddate.com/worldclock/converter.html?iso=20201001T140000&p1=tz_gmt&p2=43&p3=33&p4=248&p5=195&p6=224 UTC]''' !! '''With which other groups there should be no overlap''' !! '''Link to agenda''' !! '''Link to Meeting coordinates (service, code, password)'''<br />
|-<br />
| CONFIRMED<br>TENTATIVE<br>ON HOLD || || || || || || [https://lists.w3.org/Archives/Member/ Member-only archive]<br />
|-<br />
| CONFIRMED || TTWG: Gary Katsevman, Nigel Megitt, Media WG: Jer Noble, Mounir Lamouri, MEIG: Chris Needham, Pierre-Anthony Lemieux || TTWG, MEIG, MediaWG || [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20201015T14&p1=1440 2020-10-15 1400-1600 UTC] || || [https://www.w3.org/2011/webtv/wiki/TPAC_2020_meeting#Thursday_15_October_2020:_Timed_Text_WG_.2F_Media_WG_.2F_Media_.26_Entertainment_IG_Joint_Meeting Agenda] || The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|-<br />
| ON HOLD || (to be chosen) || TTWG - CSS-WG || (under discussion) || || (under development) || (not yet defined)<br />
|-<br />
| ON HOLD (unlikely) || (to be chosen) || TTWG - ADCG || (under discussion) || || (under development) || (not yet defined)<br />
|-<br />
| CONFIRMED || (to be chosen) || APA, CSS || [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20201014T15&p1=1440 Wednesday, Oct 14, 15:00â16:00 UTC] || || [https://www.w3.org/WAI/APA/wiki/Meetings/TPAC_2020#Groups_to_coordinate_with Agenda] || The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|-<br />
| CONFIRMED || (to be chosen) || APA, Timed Text, Silver || [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20201013T14&p1=1440 Tuesday, Oct. 13 from 14:00-15:00 UTC] || || [https://www.w3.org/WAI/APA/wiki/Meetings/TPAC_2020#Groups_to_coordinate_with Agenda]) || The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|-<br />
| CONFIRMED || WEBRTC WG: Bernard.Aboba@microsoft.com hta@google.com jib@mozilla.org || WEBRTC, MEIG || Friday, Oct 16, 15:00-16:00 UTC || || [https://www.w3.org/2011/webtv/wiki/TPAC_2020_meeting#Friday_16_October_2020:_WebRTC_WG_.2F_Media_.26_Entertainment_IG_Joint_Meeting Agenda] || The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|-<br />
| ON HOLD || (to be chosen) || APA, HTML, TAG, WICG || (under discussion) || || (under development) || (not yet defined)<br />
|-<br />
| CONFIRMED || (to be chosen) || APA, EPub3, Silver || [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20201015T15&p1=1440 Thursday, Oct 15, 15:00â16:00 UTC] || || [https://www.w3.org/WAI/APA/wiki/Meetings/TPAC_2020#Groups_to_coordinate_with Agenda] || (The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom16meeting<br />
|-<br />
| CONFIRMED || (to be chosen) || APA, Immersive Web, Silver || [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20201015T16 Thursday, Oct. 15 from 16:00â17:00pm UTC] || || [https://www.w3.org/WAI/APA/wiki/Meetings/TPAC_2020#Groups_to_coordinate_with Agenda] || The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|-<br />
| CONFIRMED || WEBRTC WG: Bernard.Aboba@microsoft.com hta@google.com jib@mozilla.org || APA, WebRTC || Tuesday, October 13, 2020, 3 - 4 PM UTC || || [https://www.w3.org/WAI/APA/wiki/Meetings/TPAC_2020#Groups_to_coordinate_with Agenda] || The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|-<br />
| ON HOLD || (to be chosen) || PING, Privacy CG || (under discussion) || || (under development) || (not yet defined)<br />
|-<br />
| CONFIRMED || WEBRTC WG: Bernard.Aboba@microsoft.com hta@google.com jib@mozilla.org || PING, WEBRTC WG || Thursday, October 15, 2020, 3 - 4 PM UTC || || (under development) || The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|-<br />
| Confirmed || [mailto:Brent.Bakken@Pearson.com Brent Bakken] || ARIA, EO || Oct 15, 4:00 PM - 5:45 PM UTC || || [https://www.w3.org/WAI/ARIA/wiki/Meetings/APG_EO_Joint Agenda] || [https://www.w3.org/2017/08/telecon-info_aria-tpac Zoom Information]<br />
|-<br />
| CONFIRMED || [mailto:michael.mccool@intel.com Michael McCool]<br/>(to be chosen) || APA, WoT || [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20201014T13&p1=1440 Wednesday, Oct. 14 at 13:00â14:00 UTC] || || (under development) || The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|-<br />
| TENTATIVE || [mailto:michael.mccool@intel.com Michael McCool]<br/>[mailto:brent.zundel@evernym.com Brent Zundel]<br/>[mailto:daniel.burnett@entethalliance.org Daniel Burnett] || DID, WoT || October 13, 11:00am ET || || (under development) || ([https://lists.w3.org/Archives/Member/member-did-wg/2020Jun/0000.html Part of the regular DID WG Weekly call])<br />
|-<br />
| CONFIRMED || [mailto:michael.mccool@intel.com Michael McCool]<br/> [mailto:sudeep.divakaran@intel.com Sudeep Divakaran] || W&N IG, WoT <br />
|| [https://www.timeanddate.com/worldclock/fixedtime.html?msg=W3C+W%26N+and+WoT+Joint+Meeting&iso=20201015T13&p1=1440&ah=1&am=30 Thursday Oct 15 @ 13:00-14:30 UTC] || MEIG,<br/> Web Transport IG,<br/> Pub IG || [https://github.com/w3c/wot/issues/934 agenda] || [https://github.com/w3c/wot/issues/934 logistics] The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|-<br />
| ON HOLD || Aysegul Yonet, Ada Rose Cannon, Chris Wilson, Correntin Wallez, Dean Jackson || Immersive Web, WebGPU || (under discussion) || || (under development) || (not yet defined)<br />
|-<br />
| TENTATIVE || John Fontana || WPSIG and Web Authn WG and CG || 7 October 30min.(under discussion) || || (under development) || The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|-<br />
| TENTATIVE || John Fontana || Web Authn WG and Web Payments || 19 and 20 October || || (under development) || The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|-<br />
| CONFIRMED || MEIG: Chris Needham, Pierre-Anthony Lemieux, Color on the Web: Chris Lilley || MEIG, Color on the Web CG || [https://www.timeanddate.com/worldclock/converter.html?iso=20201019T140000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136 2020-10-19 @ 1400-1500 UTC] || || [https://www.w3.org/2011/webtv/wiki/TPAC_2020_meeting#Monday_19_October_2020:_Media_.26_Entertainment_IG_.2F_Color_on_the_Web_CG_Joint_Meeting Agenda] || The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|}<br />
<br />
<div id="fn-status"><br />
'''Meeting status codes''':<br />
Please choose one code below:<br />
<br />
* CONFIRMED - The meeting is totally confirmed<br />
* TENTATIVE - Set of dates chosen but the meeting is not 100% confirmed<br />
* ON HOLD - Possible dates and times; we are still narrowing down<br />
</div><br />
<br />
== Contacts ==<br />
If you need any assistance with planning your meeting, the [mailto:w3t-tpregister@w3.org Events Team] is here to help you.</div>Plehegarhttps://www.w3.org/wiki/index.php?title=TPAC/2020/GroupMeetings&diff=112479TPAC/2020/GroupMeetings2020-10-01T17:51:20Z<p>Plehegar: Added APA agenda page for joint meeting</p>
<hr />
<div>==Introduction ==<br />
<br />
Due to COVID-19, [https://www.w3.org/2020/10/TPAC/ TPAC 2020] will be a fully remote event. The usual TPAC objectives remain:<br />
<br />
* Groups schedule a Group meeting to which observers are invited so that members of our community have the opportunity to see the work of the W3C groups.<br />
* Groups schedule joint meetings with other Groups<br />
* Breakout sessions will discuss specific topics of interest.<br />
<br />
All meetings will be held on-line ("virtually"). Because we will not be all together in the same timezone, scheduling the meetings has new challenges. However, we also will not try to force all of the above into just five days.<br />
<br />
[https://www.w3.org/2020/10/TPAC/ TPAC 2020] will spread over several weeks:<br />
<br />
* September and October: WG/IG/BG/CG meetings, inviting observers<br>['''Not overlapping TPAC breakout week 26â30 October''' as the main objective of that week is to focus on breakout sessions, connect with people and work on new ideas. The objective is to give the participants the time and the chance to fully participate in this week without having to attend any other W3C Meetings that same week.] <br />
* 12-16 October: Joint Group Meetings (please reserve this week for that purpose)<br />
* 26-30 October: Breakout sessions (please reserve the "golden hour" of 1400-1500 UTC each day of this week for this activity)<br />
<br />
Those who are eligible to attend the group and joint meetings are:<br />
<br />
* a participant in a W3C Working, Interest, Business or Community Group scheduled to meet for TPAC<br />
* a W3C Member Advisory Committee Representative<br />
* a participant on the Advisory Board or the TAG<br />
* an employee of a W3C member organization<br />
* an invited Guest<br />
* a W3C Evangelist<br />
* W3C staff or W3C Office chapter<br />
<br />
'''Observer and Guest Attendance:''' Eligible participants may request to attend as an Observer via the registration form. <br /><br />
'''Community Group Participants:''' Any participant of a CG scheduled to meet will be able to attend other group meetings if one of the above criteria is fulfilled.<br />
<br />
'''Group chairs, please read the details below and fill in the appropriate table(s). <br />'''<br />
There are three different tables for the following meetings:<br />
* Working Group [WG], Interest Group [IG], Business Group [BG] Meetings<br />
* Community Group [CG] Meetings<br />
* Joint Group Meetings<br />
<br />
Please indicate the meeting status codes when you will fill in the tables:<br/><br />
* CONFIRMED [The meeting is totally confirmed]<br />
* TENTATIVE [Set of dates chosen but the meeting is not 100% confirmed]<br />
* ON HOLD [Possible dates and times; we are still narrowing down]<br />
<br />
Note that only the groups with the [CONFIRMED] status will be added to the global meeting schedule [1] and to the registration form. Please do your best to confirm your meetings before registration opens on 8 September.<br />
However, if you are unable to confirm your meeting before registration opens, it will be added to the schedule and the registration form later when you do confirm.<br />
<br />
Please do your best to select times that will allow a broad participation among meeting attendees and observers all around the globe.<br />
<br />
== WG/IG/BG Group Meetings details ==<br />
<br />
This year, the groups will organize their distributed meetings and decide whether they want to appear on the global meeting schedule W3C will publish. The groups decide when and for how long they want to meet.<br/><br />
While the schedule will be public, the specific teleconference details should remain Member-only.<br/><br />
<br />
{| class="wikitable"<br />
|-<br />
! '''Meeting status code - Choose one (see [[#fn-status|below]])''' !! '''Chair name''' !! '''Group name''' !! '''Date and times in [https://www.timeanddate.com/worldclock/converter.html?iso=20201001T140000&p1=tz_gmt&p2=43&p3=33&p4=248&p5=195&p6=224 UTC]''' !! '''With which groups there should be no overlap''' !! '''Link to agenda''' || '''Link to Meeting coordinates (service, code, password)'''<br />
|-<br />
| CONFIRMED<br>TENTATIVE<br>ON HOLD || || || || || || [https://lists.w3.org/Archives/Member/ Member-only archive]<br />
|-<br />
| TENTATIVE || [mailto:k@w3.org Coralie Mercier] & [mailto:lwatson@tetralogical.com LĂŠonie Watson] & [mailto:tsiegman@wiley.com Tzviya Siegman] || Joint [https://www.w3.org/community/idcg/ Inclusion & Diversity CG] and [https://www.w3.org/community/pwe/ Positive Work Environment CG] meeting || [https://www.timeanddate.com/worldclock/converter.html?iso=20201015T1400000&p1=43&p2=33&p3=248&p4=195&p5=224 October 13 or 15 at 2PM UTC] || || || <br />
|-<br />
| CONFIRMED || [mailto:ylafon.w3.org Yves Lafon] & [mailto:wilaw@akamai.com Will Law] & [mailto:jib@mozilla.com Jan-Ivar Bruaroey] || WebTransport WG || [https://www.timeanddate.com/worldclock/converter.html?iso=20201019T160000&p1=43&p2=33&p3=248&p4=195&p5=224 Oct 19, 16:00-18:00 UTC], [https://www.timeanddate.com/worldclock/converter.html?iso=20201021T160000&p1=43&p2=33&p3=248&p4=195&p5=224 Oct 21, 16:00-18:00 UTC] || WebRTC WG || || <br />
|-<br />
| CONFIRMED || [mailto:jeff@w3.org Jeff Jaffe] || Advisory Committee || [https://www.timeanddate.com/worldclock/converter.html?iso=20201020T133000&p1=43&p2=33&p3=248&p4=195&p5=224 20 Oct 1330-1500 UTC] || || || <br />
|-<br />
| CONFIRMED || stearns@adobe.com Rossen.Atanassov@microsoft.com || CSS WG || October 19, 20 20:00-23:00. Oct 22, 23 14:00-17:00 || || ||<br />
|-<br />
| CONFIRMED || [mailto:brent.zundel@evernym.com Brent Zundel]<br/>[mailto:daniel.burnett@entethalliance.org Dan Burnett] || Decentralized Identifiers WG || [https://www.timeanddate.com/worldclock/fixedtime.html?msg=TPAC+DID+WG+Day+1&iso=20201102T10&p1=43&ah=3&am=30 November 2, 14 - 17:30 UTC]<br/>[https://www.timeanddate.com/worldclock/fixedtime.html?msg=TPAC+DID+WG+Day+2&iso=20201103T12&p1=43&ah=3&am=30 November 3, 16 - 19:30 UTC]<br/>[https://www.timeanddate.com/worldclock/fixedtime.html?msg=TPAC+DID+WG+Day+3&iso=20201104T10&p1=43&ah=3&am=30 November 4, 14 - 17:30 UTC]<br/>[https://www.timeanddate.com/worldclock/fixedtime.html?msg=TPAC+DID+WG+Day+4&iso=20201105T12&p1=43&ah=3&am=30 November 5, 16 - 19:30 UTC]|| WebAuthn WG || [https://www.w3.org/2019/did-wg/Meetings/F2F/2020.11.VirtualTPAC.html Meeting Information Page] || [https://lists.w3.org/Archives/Member/member-did-wg/2020Jun/0000.html Meeting Link]<br />
|-<br />
| CONFIRMED || anssi.kostiainen@intel.com || [https://www.w3.org/das/ Devices and Sensors WG] || October 22 5:00 UTC, October 23 5:00 UTC || Second Screen WG/CG, WebML CG || [https://github.com/w3c/devicesensors-wg/issues/31 Agenda] ||<br />
|-<br />
| CONFIRMED || [mailto:wendy.reid@rakuten.com Wendy Reid] || EPUB 3 WG || [https://www.timeanddate.com/worldclock/fixedtime.html?msg=EPUB+3+vF2F%2C+North-America+%2F+East+Asia&iso=20201023T09&p1=248&ah=3&am=30 October 23 00:00 UTC - 03:30 UTC] &amp; [https://www.timeanddate.com/worldclock/fixedtime.html?msg=EPUB+3+vF2F+Meeting%2C+North-America+%2F+Europe&iso=20201023T10&p1=43&ah=3&am=30 October 23 14:00 UTC - 17:30 UTC] || CSS WG, APA WG || || [https://www.w3.org/publishing/groups/epub-wg/Meetings/F2F/2020_October Meeting Info]<br />
|-<br />
| CONFIRMED || addison@amazon.com || Internationalization (I18N) WG || 20-October and 22-October @ 1500-1700 || || https://www.w3.org/wiki/I18N_2020_TPAC ||<br />
|-<br />
| CONFIRMED || [mailto:chris.needham@bbc.co.uk Chris Needham]<br/>[mailto:pal@sandflow.com Pierre-Anthony Lemieux]<br/>[mailto:Tatsuya.Igarashi@sony.com Tatsuya Igarashi] || Media & Entertainment IG || [https://www.timeanddate.com/worldclock/converter.html?iso=20201019T130000&p1=43&p2=33&p3=248&p4=195&p5=224 October 19 @ 1300-1400] and [https://www.timeanddate.com/worldclock/converter.html?iso=20201021T050000&p1=43&p2=33&p3=248&p4=195&p5=224 October 21 @ 0500-0700] || TTWG WICG, CSS WG, Media WG, WoT IG/WG || ||<br />
|-<br />
| CONFIRMED || anssi.kostiainen@intel.com || [https://www.w3.org/2014/secondscreen/ Second Screen WG/CG] || October 20 5:00 UTC, October 21 5:00 UTC || DAS WG, WebML CG, Media & Entertainment IG, Media WG || [https://github.com/w3c/secondscreen-wg/issues/1 Agenda] ||<br />
|-<br />
| CONFIRMED || wseltzer@w3.org || Web Advertising BG|| [https://github.com/w3c/web-advertising/blob/master/meetings/TPAC2020.md October 21, 22 1500-1900 UTC] || PrivacyCG, PING, WebAppSec || [https://github.com/w3c/web-advertising/blob/master/meetings/TPAC2020.md agenda draft] ||<br />
|-<br />
| CONFIRMED || lwatson@tetralogical.com mcaceres@mozilla.com || WebApps WG || [https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020&month=10&day=19&hour=21&min=0&sec=0&p1=152&p2=137&p3=179&p4=136&p5=33 9pm - 11pm UTC October 19] || || ||<br />
|-<br />
| CONFIRMED || [mailto:michael.mccool@intel.com Michael McCool]<br/>[mailto:sebastian.kaebisch@siemens.com Sebastian Kaebisch] || Web of Things (WoT) WG/IG || Plugfest: [https://www.timeanddate.com/worldclock/converter.html?iso=20200928T130000&p1=43&p2=33&p3=248&p4=195&p5=224 Sept28-Oct 2 @ 1300-1400]<br/><br/>vF2F: [https://www.timeanddate.com/worldclock/converter.html?iso=20201005T120000&p1=43&p2=33&p3=248&p4=195&p5=224 Oct 5, 7, 20, 21, 22 @ 1200-1500] ||JSON-LD WG, MEIG, PING, Service Workers WG, Web and Networks IG, DAS WG, TAG, APA WG || https://www.w3.org/WoT/IG/wiki/F2F_meeting,_October_2020 ||<br />
|-<br />
| CONFIRMED || njansma@akamai.com yoavweiss@google.com || Web Performance WG || October 19 to 22 (over 4 days) @ 1600-1900 || || ||<br />
|-<br />
| CONFIRMED || [mailto:w3@stormglass.consulting Nick Telford-Reed] || Web Payments WG || October 19-22 3-5pm UTC (TBC) || Web Authentication WG (at least one day)|| ||<br />
|-<br />
| CONFIRMED || Bernard.Aboba@microsoft.com hta@google.com jib@mozilla.org || WEBRTC WG || October 20, 22 3-5 PM UTC || Media WG, Media & Entertainment IG, WebTransport WG|| ||<br />
<br />
|-<br />
| CONFIRMED || [mailto:peter.winzell@volvocars.com Peter Winzell]<br />[mailto:patrick.luennemann@carmeq.com Patrick Luennemann] || Automotive WG & Automotive/Transportation BG || 12-15-October 15-17 UTC || || ||<br />
<br />
|-<br />
| CONFIRMED || [mailto:shiohama@mediado.jp Daihei Shiohama]<br />[mailto:lmccloy-kelley@penguinrandomhouse.com Liisa McCloy-Kelley]<br />[mailto:cristina.mussinelli@fondazionelia.org Cristina Mussinelli] || Publishing BG || 13 October 17:00-18:30 - 14 October 02:00 - 03:30 UTC || || ||<br />
<br />
|-<br />
| CONFIRMED || [mailto:ij@w3.org Ian Jacobs] || Web Payment Security IG || 6-7-October 2-4pm UTC || || ||<br />
<br />
|-<br />
| TENTATIVE || Ada Rose Cannon (Samsung), AyĹegĂźl YĂśnet (Microsoft) and Chris Wilson (Google) || Immersive-web WG || 13-15 October, 2h each ([https://www.w3.org/2020/05/26-immersive-web-minutes.html#t01 ref]) || || || <br />
<br />
|-<br />
| CONFIRMED || John Fontana (Yubico), Anthony Nadalin (IE)|| WebAuthn WG || 14 October, 1hr 1900 UTC || || || <br />
|-<br />
| CONFIRMED || smcgruer@chromium.org || WPT (web-platform-tests) || October 19 14:00-17:30, October 21 14:00-17:30 || || [https://docs.google.com/document/d/1XhUwVbitdV03eX2GefmokCliWjQdAxBgblwITwNqsgc/edit?ts=5f501f7f Agenda] ||<br />
|-<br />
| CONFIRMED || Christine Runnegar, Pete Snyder || Privacy IG (PING) || 15 October, 1600-1700 UTC || || Routine PING meeting || [https://www.w3.org/Privacy/IG/ Coordinates]<br />
|-<br />
| ON HOLD || Christine Runnegar, Pete Snyder || Privacy IG (PING) || 23 October, 1600-1700 UTC || || How to do a review || [https://www.w3.org/Privacy/IG/ Coordinates]<br />
|-<br />
|}<br />
<br />
== CG Group Meetings details ==<br />
<br />
Community Groups will be able to meet during the Fall 2020 TPAC event. The groups will organize their distributed meetings and decide whether they want to appear on the global meeting schedule we will publish<br/> <br />
Registered participants in W3C Community Groups may participate in their CG meeting. See the above participation rules for the attendance of any other meetings.<br />
<br />
CGs Chairs who can not edit this page should contact [mailto:w3t-tpregister@w3.org Events Team] stating their username . Access will be given.<br />
<br />
{| class="wikitable"<br />
|-<br />
! '''Meeting status code - Choose one (see [[#fn-status|below]])''' !! '''Chair name''' !! '''Group name''' !! '''Date and times in [https://www.timeanddate.com/worldclock/converter.html?iso=20201001T140000&p1=tz_gmt&p2=43&p3=33&p4=248&p5=195&p6=224 UTC]''' !! '''With which groups there should be no overlap''' !! '''Link to agenda''' !! '''Link to Meeting coordinates (service, code, password)'''<br />
|-<br />
| CONFIRMED<br>TENTATIVE<br>ON HOLD || || || || || || [https://lists.w3.org/Archives/ archive]<br />
|-<br />
| CONFIRMED || [https://www.researchgate.net/profile/Georg_Schneider3 Georg Ferdinand Schneider]<br/> [https://www.researchgate.net/profile/Dr_Kris_Mcglinn Kris McGlinn] [https://www.researchgate.net/profile/Mads_Holten_Rasmussen Mads Holten Rasmussen]<br/> [https://www.researchgate.net/profile/Maxime_Lefrancois2 Maxime Lefrancois]<br/> || [https://www.w3.org/community/lbd/ Linked Building Data CG] || [https://www.timeanddate.com/worldclock/fixedtime.html?msg=TPAC+2020+W3C+LBD+CG+Group+Call&iso=20201013T17&p1=37&ah=1&am=30 13 October 2020, 15:00-16:30@UTC (17:00-18:30@CEST/ 16:00-17:30@BST/ 8:00-9:30@PDT)] || WoT IG/WG || tbd || tbd<br />
|-<br />
| TENTATIVE || padenot@mozilla.com,matthew.paradis@bbc.co.uk || Audio CG || October 22 @ 16:00 || TTWG WICG, CSS WG, Media WG, WoT IG/WG || ||<br />
|-<br />
| ON HOLD || reillyg@google.com || Web Bluetooth CG || October 19 to 23 (TBD) || WICG || || <br />
|-<br />
| CONFIRMED || kimdhamilton@gmail.com || Credentials CG || October 14 15:00-16:00 UTC || || || <br />
|-<br />
|-<br />
| CONFIRMED || tomgreenaway@google.com, noelm@fb.com || Web Games CG || October 20 10:00 UTC || || || <br />
|-<br />
| CONFIRMED || yoav@yoav.ws, kleber@google.com, a.blanchard@criteo.com || WICG - TURTLEDOVE + SPARROW proposals || October 13 15:00 UTC || || || <br />
|-<br />
| CONFIRMED || yoav@yoav.ws, csharrison@google.com || WICG - Conversion measurement proposal || October 13 16:00 UTC || || || <br />
|-<br />
| CONFIRMED || yoav@yoav.ws, reillyg@google.com || WICG - Idle detection, Serial, WebHID, WebUSB proposals || October 13 17:00 UTC || || || <br />
|-<br />
| TENTATIVE || dahl@conversational-technologies.com, marco@kerwitz.com,dirk.schnelle@jvoicexml.org,brian.susko@gmail.com || Voice Interaction CG || October 21 15:00 UTC || || || <br />
|-<br />
| CONFIRMED || eric@alexandriaconsulting.com || Human Services Community Group https://www.w3.org/community/humanservices || Wednesday, October 21 18:00-19:30 UTC/14:00-15:30 EDT || || || <br />
|-<br />
| CONFIRMED || anssi.kostiainen@intel.com || [https://webmachinelearning.github.io Machine Learning for the Web Community Group] || Thursday, October 22 14:00-15:00 UTC || || [https://github.com/webmachinelearning/meetings/blob/master/2020-10-22-tpac2020/README.md Agenda] || <br />
|-<br />
| CONFIRMED || dchaves@fi.upm.es, anastasia.dimou@ugent.be || [https://www.w3.org/community/kg-construct/ Knowledge Graph Construction Community Group] || October 12,13,15,16 14:00-16:00 (UTC+2) || || || <br />
|-<br />
| CONFIRMED || angelli.laq@alibaba-inc.com || [https://www.w3.org/community/miniapps/ MiniApps Ecosystem Community Group] || October 15 12:00-14:00 || || ||<br />
|-<br />
| TENTATIVE || gwhitworth@salesforce.com || Open UI || TBD || || || <br />
|-<br />
|}<br />
<br />
== Joint Group meetings - Week of 12-16 October ==<br />
The joint meetings could be organized in a single week during the week of the 12-16 October.<br/><br />
As for the group meetings, observers will be allowed.<br/><br />
<br />
Group Chairs, <br />
please coordinate with the groups you would like to meet with and fill in the following table before '''Thursday 13 August'''. <br />
<br />
{| class="wikitable"<br />
|-<br />
! '''Meeting status code - Choose one (see [[#fn-status|below]])''' !! '''Chair names''' !! '''Group names''' !! '''Date and times in [https://www.timeanddate.com/worldclock/converter.html?iso=20201001T140000&p1=tz_gmt&p2=43&p3=33&p4=248&p5=195&p6=224 UTC]''' !! '''With which other groups there should be no overlap''' !! '''Link to agenda''' !! '''Link to Meeting coordinates (service, code, password)'''<br />
|-<br />
| CONFIRMED<br>TENTATIVE<br>ON HOLD || || || || || || [https://lists.w3.org/Archives/Member/ Member-only archive]<br />
|-<br />
| CONFIRMED || TTWG: Gary Katsevman, Nigel Megitt, Media WG: Jer Noble, Mounir Lamouri, MEIG: Chris Needham, Pierre-Anthony Lemieux || TTWG, MEIG, MediaWG || [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20201015T14&p1=1440 2020-10-15 1400-1600 UTC] || || [https://www.w3.org/2011/webtv/wiki/TPAC_2020_meeting#Thursday_15_October_2020:_Timed_Text_WG_.2F_Media_WG_.2F_Media_.26_Entertainment_IG_Joint_Meeting Agenda] || The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|-<br />
| ON HOLD || (to be chosen) || TTWG - CSS-WG || (under discussion) || || (under development) || (not yet defined)<br />
|-<br />
| ON HOLD (unlikely) || (to be chosen) || TTWG - ADCG || (under discussion) || || (under development) || (not yet defined)<br />
|-<br />
| CONFIRMED || (to be chosen) || APA, CSS || [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20201014T15&p1=1440 Wednesday, Oct 14, 15:00â16:00 UTC] || || [https://www.w3.org/WAI/APA/wiki/Meetings/TPAC_2020#Groups_to_coordinate_with Agenda] || The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|-<br />
| CONFIRMED || (to be chosen) || APA, Timed Text, Silver || [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20201013T14&p1=1440 Tuesday, Oct. 13 from 14:00-15:00 UTC] || || [https://www.w3.org/WAI/APA/wiki/Meetings/TPAC_2020#Groups_to_coordinate_with Agenda]) || The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|-<br />
| CONFIRMED || WEBRTC WG: Bernard.Aboba@microsoft.com hta@google.com jib@mozilla.org || WEBRTC, MEIG || Friday, Oct 16, 15:00-16:00 UTC || || [https://www.w3.org/2011/webtv/wiki/TPAC_2020_meeting#Friday_16_October_2020:_WebRTC_WG_.2F_Media_.26_Entertainment_IG_Joint_Meeting Agenda] || The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|-<br />
| ON HOLD || (to be chosen) || APA, HTML, TAG, WICG || (under discussion) || || (under development) || (not yet defined)<br />
|-<br />
| CONFIRMED || (to be chosen) || APA, EPub3, Silver || [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20201015T15&p1=1440 Thursday, Oct 15, 15:00â16:00 UTC] || || [https://www.w3.org/WAI/APA/wiki/Meetings/TPAC_2020#Groups_to_coordinate_with Agenda] || (The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom16meeting<br />
|-<br />
| CONFIRMED || (to be chosen) || APA, Immersive Web, Silver || [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20201015T16 Thursday, Oct. 15 from 16:00â17:00pm UTC] || || [https://www.w3.org/WAI/APA/wiki/Meetings/TPAC_2020#Groups_to_coordinate_with Agenda] || The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|-<br />
| CONFIRMED || WEBRTC WG: Bernard.Aboba@microsoft.com hta@google.com jib@mozilla.org || APA, WebRTC || Tuesday, October 13, 2020, 3 - 4 PM UTC || || [https://www.w3.org/WAI/APA/wiki/Meetings/TPAC_2020#Groups_to_coordinate_with Agenda] || The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|-<br />
| ON HOLD || (to be chosen) || PING, Privacy CG || (under discussion) || || (under development) || (not yet defined)<br />
|-<br />
| CONFIRMED || WEBRTC WG: Bernard.Aboba@microsoft.com hta@google.com jib@mozilla.org || PING, WEBRTC WG || Thursday, October 15, 2020, 3 - 4 PM UTC || || (under development) || The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|-<br />
| Confirmed || [mailto:Brent.Bakken@Pearson.com Brent Bakken] || ARIA, EO || Oct 15, 4:00 PM - 5:45 PM UTC || || [https://www.w3.org/WAI/ARIA/wiki/Meetings/APG_EO_Joint Agenda] || [https://www.w3.org/2017/08/telecon-info_aria-tpac Zoom Information]<br />
|-<br />
| CONFIRMED || [mailto:michael.mccool@intel.com Michael McCool]<br/>(to be chosen) || APA, WoT || [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20201014T13&p1=1440 Wednesday, Oct. 14 at 13:00â14:00 UTC] || || (under development) || The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|-<br />
| TENTATIVE || [mailto:michael.mccool@intel.com Michael McCool]<br/>[mailto:brent.zundel@evernym.com Brent Zundel]<br/>[mailto:daniel.burnett@entethalliance.org Daniel Burnett] || DID, WoT || October 13, 11:00am ET || || (under development) || ([https://lists.w3.org/Archives/Member/member-did-wg/2020Jun/0000.html Part of the regular DID WG Weekly call])<br />
|-<br />
| CONFIRMED || [mailto:michael.mccool@intel.com Michael McCool]<br/> [mailto:sudeep.divakaran@intel.com Sudeep Divakaran] || W&N IG, WoT <br />
|| [https://www.timeanddate.com/worldclock/fixedtime.html?msg=W3C+W%26N+and+WoT+Joint+Meeting&iso=20201015T13&p1=1440&ah=1&am=30 Thursday Oct 15 @ 13:00-14:30 UTC] || MEIG,<br/> Web Transport IG,<br/> Pub IG || [https://github.com/w3c/wot/issues/934 agenda] || [https://github.com/w3c/wot/issues/934 logistics] The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|-<br />
| ON HOLD || Aysegul Yonet, Ada Rose Cannon, Chris Wilson, Correntin Wallez, Dean Jackson || Immersive Web, WebGPU || (under discussion) || || (under development) || (not yet defined)<br />
|-<br />
| TENTATIVE || John Fontana || WPSIG and Web Authn WG and CG || 7 October 30min.(under discussion) || || (under development) || The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|-<br />
| TENTATIVE || John Fontana || Web Authn WG and Web Payments || 19 and 20 October || || (under development) || The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|-<br />
| CONFIRMED || MEIG: Chris Needham, Pierre-Anthony Lemieux, Color on the Web: Chris Lilley || MEIG, Color on the Web CG || [https://www.timeanddate.com/worldclock/converter.html?iso=20201019T140000&p1=43&p2=33&p3=248&p4=195&p5=224&p6=136 2020-10-19 @ 1400-1500 UTC] || || [https://www.w3.org/2011/webtv/wiki/TPAC_2020_meeting#Monday_19_October_2020:_Media_.26_Entertainment_IG_.2F_Color_on_the_Web_CG_Joint_Meeting Agenda] || The platform will be Zoom. Contact [mailto:w3t-tpregister@w3.org w3t-tpregister@w3.org] if you need assistance in planning a Zoom meeting<br />
|}<br />
<br />
<div id="fn-status"><br />
'''Meeting status codes''':<br />
Please choose one code below:<br />
<br />
* CONFIRMED - The meeting is totally confirmed<br />
* TENTATIVE - Set of dates chosen but the meeting is not 100% confirmed<br />
* ON HOLD - Possible dates and times; we are still narrowing down<br />
</div><br />
<br />
== Contacts ==<br />
If you need any assistance with planning your meeting, the [mailto:w3t-tpregister@w3.org Events Team] is here to help you.</div>Plehegarhttps://www.w3.org/wiki/index.php?title=TPAC/2020/GroupMeetings&diff=111864TPAC/2020/GroupMeetings2020-07-30T17:13:00Z<p>Plehegar: /* WG/IG/BG Group Meetings details */</p>
<hr />
<div>== Introduction ==<br />
<br />
This page will help with organizing individual and joint group meetings during the Fall 2020 TPAC event.<br/><br />
Those who are eligible to attend the group and joint meetings are:<br />
<br />
* a participant in a W3C Working, Interest, Business or Community Group scheduled to meet for TPAC<br />
* a W3C Member Advisory Committee Representative<br />
* a participant on the Advisory Board or the TAG<br />
* an employee of a W3C member organization<br />
* an invited Guest<br />
* a W3C Evangelist<br />
* W3C staff or W3C Office chapter<br />
<br />
'''Observer and Guest Attendance:''' Eligible participants may request to attend as an Observer via the registration form. <br /><br />
'''Community Group Participants:''' Any participant of a CG scheduled to meet will be able to attend other group meetings if one of the above criteria is fulfilled.<br />
<br />
'''Group chairs, please read the details below and fill in the appropriate table(s) by Thursday 13 August. <br />'''<br />
There are three different tables for the following meetings:<br />
* Working Group [WG], Interest Group [IG], Business Group [BG] Meetings<br />
* Community Group [CG] Meetings<br />
* Joint Group Meetings<br />
<br />
== WG/IG/BG Group Meetings details ==<br />
<br />
This year, the groups will organize their distributed meetings and decide whether they want to appear on the global meeting schedule W3C will publish. While the schedule will be public, the specific teleconference details should remain Member-only.<br/><br />
The groups appearing on the schedule will agree on the following principles: <br/><br />
* create interaction with more of the community<br />
* allow observers so that members of our community have the opportunity to see the work of the W3C groups. <br />
<br />
The group meetings will not overlap the TPAC breakout week (26 to 30 October)<br />
<br />
{| class="wikitable"<br />
|-<br />
! '''Meeting status code - Choose one (see [[#fn-status|below]])''' !! '''Chair name''' !! '''Group name''' !! '''Date and times in [https://www.timeanddate.com/worldclock/converter.html?iso=20201001T140000&p1=tz_gmt&p2=43&p3=33&p4=248&p5=195&p6=224 UTC]''' !! '''With which groups there should be no overlap''' !! '''Link to agenda''' || '''Link to Meeting coordinates (service, code, password)'''<br />
|-<br />
| CONFIRMED<br>TENTATIVE<br>ON HOLD || || || || || || [https://lists.w3.org/Archives/Member/ Member-only archive]<br />
|-<br />
| TENTATIVE || chris.needham@bbc.co.uk pal@sandflow.com Tatsuya.Igarashi@sony.com || Media & Entertainment IG || October 19 @ 1300-1500 and October 21 @ 0500-0700 || TTWG WICG, CSS WG, Media WG, WoT IG/WG || ||<br />
|-<br />
| TENTATIVE || njansma@akamai.com yoavweiss@google.com || Web Performance WG || October 19 to 22 (over 4 days) @ 1600-1900 || || ||<br />
|-<br />
|}<br />
<br />
== CG Group Meetings details ==<br />
<br />
Community Groups will be able to meet during the Fall 2020 TPAC event. The groups will organize their distributed meetings and decide whether they want to appear on the global meeting schedule we will publish<br/> <br />
Registered participants in W3C Community Groups may participate in their CG meeting. See the above participation rules for the attendance of any other meetings.<br />
<br />
The group meetings will not overlap the TPAC breakout week (26 to 30 October)<br />
<br />
{| class="wikitable"<br />
|-<br />
! '''Meeting status code - Choose one (see [[#fn-status|below]])''' !! '''Chair name''' !! '''Group name''' !! '''Date and times in [https://www.timeanddate.com/worldclock/converter.html?iso=20201001T140000&p1=tz_gmt&p2=43&p3=33&p4=248&p5=195&p6=224 UTC]''' !! '''With which groups there should be no overlap''' !! '''Link to agenda''' !! '''Link to Meeting coordinates (service, code, password)'''<br />
|-<br />
| CONFIRMED<br>TENTATIVE<br>ON HOLD || || || || || || [https://lists.w3.org/Archives/ archive]<br />
|-<br />
|}<br />
<br />
== Joint Group meetings - Week of 12-16 October ==<br />
The joint meetings could be organized in a single week during the week of the 12-16 October.<br/><br />
As for the group meetings, observers will be allowed.<br/><br />
<br />
Group Chairs, <br />
please coordinate with the groups you would like to meet with and fill in the following table before '''Thursday 13 August'''. <br />
<br />
{| class="wikitable"<br />
|-<br />
! '''Meeting status code - Choose one (see [[#fn-status|below]])''' !! '''Chair names''' !! '''Group names''' !! '''Date and times in [https://www.timeanddate.com/worldclock/converter.html?iso=20201001T140000&p1=tz_gmt&p2=43&p3=33&p4=248&p5=195&p6=224 UTC]''' !! '''With which other groups there should be no overlap''' !! '''Link to agenda''' !! '''Link to Meeting coordinates (service, code, password)'''<br />
|-<br />
| CONFIRMED<br>TENTATIVE<br>ON HOLD || || || || || || [https://lists.w3.org/Archives/Member/ Member-only archive]<br />
|-<br />
|}<br />
<br />
<div id="fn-status"><br />
'''Meeting status codes''':<br />
Please choose one code below:<br />
<br />
* CONFIRMED - The meeting is totally confirmed<br />
* TENTATIVE - Set of dates chosen but the meeting is not 100% confirmed<br />
* ON HOLD - Possible dates and times; we are still narrowing down<br />
</div><br />
<br />
== Contacts ==<br />
If you need any assistance with planning your meeting, the [mailto:w3t-tpregister@w3.org Events Team] is here to help you.</div>Plehegarhttps://www.w3.org/wiki/index.php?title=TPAC/2020/GroupMeetings&diff=111863TPAC/2020/GroupMeetings2020-07-30T17:10:42Z<p>Plehegar: WebPerf https://docs.google.com/document/d/1fHD8Eqyt6vInbZu3vkIVhPVrRPtGpNmaQgzKppVW4xY/edit</p>
<hr />
<div>== Introduction ==<br />
<br />
This page will help with organizing individual and joint group meetings during the Fall 2020 TPAC event.<br/><br />
Those who are eligible to attend the group and joint meetings are:<br />
<br />
* a participant in a W3C Working, Interest, Business or Community Group scheduled to meet for TPAC<br />
* a W3C Member Advisory Committee Representative<br />
* a participant on the Advisory Board or the TAG<br />
* an employee of a W3C member organization<br />
* an invited Guest<br />
* a W3C Evangelist<br />
* W3C staff or W3C Office chapter<br />
<br />
'''Observer and Guest Attendance:''' Eligible participants may request to attend as an Observer via the registration form. <br /><br />
'''Community Group Participants:''' Any participant of a CG scheduled to meet will be able to attend other group meetings if one of the above criteria is fulfilled.<br />
<br />
'''Group chairs, please read the details below and fill in the appropriate table(s) by Thursday 13 August. <br />'''<br />
There are three different tables for the following meetings:<br />
* Working Group [WG], Interest Group [IG], Business Group [BG] Meetings<br />
* Community Group [CG] Meetings<br />
* Joint Group Meetings<br />
<br />
== WG/IG/BG Group Meetings details ==<br />
<br />
This year, the groups will organize their distributed meetings and decide whether they want to appear on the global meeting schedule W3C will publish. While the schedule will be public, the specific teleconference details should remain Member-only.<br/><br />
The groups appearing on the schedule will agree on the following principles: <br/><br />
* create interaction with more of the community<br />
* allow observers so that members of our community have the opportunity to see the work of the W3C groups. <br />
<br />
The group meetings will not overlap the TPAC breakout week (26 to 30 October)<br />
<br />
{| class="wikitable"<br />
|-<br />
! '''Meeting status code - Choose one (see [[#fn-status|below]])''' !! '''Chair name''' !! '''Group name''' !! '''Date and times in [https://www.timeanddate.com/worldclock/converter.html?iso=20201001T140000&p1=tz_gmt&p2=43&p3=33&p4=248&p5=195&p6=224 UTC]''' !! '''With which groups there should be no overlap''' !! '''Link to agenda''' || '''Link to Meeting coordinates (service, code, password)'''<br />
|-<br />
| CONFIRMED<br>TENTATIVE<br>ON HOLD || || || || || || [https://lists.w3.org/Archives/Member/ Member-only archive]<br />
|-<br />
| TENTATIVE || chris.needham@bbc.co.uk pal@sandflow.com Tatsuya.Igarashi@sony.com || Media & Entertainment IG || October 19 @ 1300-1500 and October 21 @ 0500-0700 || TTWG WICG, CSS WG, Media WG, WoT IG/WG || ||<br />
|-<br />
| TENTATIVE || njansma@akamai.com yoavweiss@google.com || Web Performance WG || October 19 to 23 @ 1600-1900 || || ||<br />
|-<br />
|}<br />
<br />
== CG Group Meetings details ==<br />
<br />
Community Groups will be able to meet during the Fall 2020 TPAC event. The groups will organize their distributed meetings and decide whether they want to appear on the global meeting schedule we will publish<br/> <br />
Registered participants in W3C Community Groups may participate in their CG meeting. See the above participation rules for the attendance of any other meetings.<br />
<br />
The group meetings will not overlap the TPAC breakout week (26 to 30 October)<br />
<br />
{| class="wikitable"<br />
|-<br />
! '''Meeting status code - Choose one (see [[#fn-status|below]])''' !! '''Chair name''' !! '''Group name''' !! '''Date and times in [https://www.timeanddate.com/worldclock/converter.html?iso=20201001T140000&p1=tz_gmt&p2=43&p3=33&p4=248&p5=195&p6=224 UTC]''' !! '''With which groups there should be no overlap''' !! '''Link to agenda''' !! '''Link to Meeting coordinates (service, code, password)'''<br />
|-<br />
| CONFIRMED<br>TENTATIVE<br>ON HOLD || || || || || || [https://lists.w3.org/Archives/ archive]<br />
|-<br />
|}<br />
<br />
== Joint Group meetings - Week of 12-16 October ==<br />
The joint meetings could be organized in a single week during the week of the 12-16 October.<br/><br />
As for the group meetings, observers will be allowed.<br/><br />
<br />
Group Chairs, <br />
please coordinate with the groups you would like to meet with and fill in the following table before '''Thursday 13 August'''. <br />
<br />
{| class="wikitable"<br />
|-<br />
! '''Meeting status code - Choose one (see [[#fn-status|below]])''' !! '''Chair names''' !! '''Group names''' !! '''Date and times in [https://www.timeanddate.com/worldclock/converter.html?iso=20201001T140000&p1=tz_gmt&p2=43&p3=33&p4=248&p5=195&p6=224 UTC]''' !! '''With which other groups there should be no overlap''' !! '''Link to agenda''' !! '''Link to Meeting coordinates (service, code, password)'''<br />
|-<br />
| CONFIRMED<br>TENTATIVE<br>ON HOLD || || || || || || [https://lists.w3.org/Archives/Member/ Member-only archive]<br />
|-<br />
|}<br />
<br />
<div id="fn-status"><br />
'''Meeting status codes''':<br />
Please choose one code below:<br />
<br />
* CONFIRMED - The meeting is totally confirmed<br />
* TENTATIVE - Set of dates chosen but the meeting is not 100% confirmed<br />
* ON HOLD - Possible dates and times; we are still narrowing down<br />
</div><br />
<br />
== Contacts ==<br />
If you need any assistance with planning your meeting, the [mailto:w3t-tpregister@w3.org Events Team] is here to help you.</div>Plehegarhttps://www.w3.org/wiki/index.php?title=PointerEvents/Meetings&diff=110986PointerEvents/Meetings2020-01-15T16:15:20Z<p>Plehegar: Refreshed</p>
<hr />
<div>The Pointer Events group has two types of meetings and this document includes general information about the meetings:<br />
<br />
# Distributed meetings, aka teleconferences and voice conferences<br />
# Face-to-face (f2f) meetings <br />
<br />
SeeAlso:<br />
<br />
* [http://www.w3.org/wiki/PointerEvents/WGCode The WG's ''Code''] - describes how the group ''actually'' operates including links to various resources<br />
* [https://github.com/w3c/pointerevents GitHub repository] - GitHub is used for all bugs, issues, and as a tracker for spec-related actions<br />
* [http://lists.w3.org/Archives/Public/public-pointer-events/ public-pointer-events] - archive of the group's Public mail list<br />
<br />
==Agendas==<br />
<br />
Draft agendas for '''''distributed meetings''''' are sent to the group's [http://lists.w3.org/Archives/Public/public-pointer-events/ public-pointer-events] mail list at least 24 hours before the meeting starts.<br />
<br />
'''''F2f meetings''''' are announced at least eight weeks before the start of the meeting. Draft agendas for ''f2f meetings'' are sent to the group's [http://lists.w3.org/Archives/Public/public-pointer-events/ public-pointer-events] mail list at least two weeks before the meeting begins.<br />
<br />
==IRC and Meeting Resources ==<br />
IRC will be used for every meeting to record minutes. The group's IRC channel is '''#pointerevents''' (irc://irc.w3.org/).<br />
<br />
If you do do not have an IRC client, or have trouble connecting to IRC from behind a firewall, W3C offers a browser-based [http://irc.w3.org/ IRC Web interface] (note: you must have a Member or Invited Expert account to use this).<br />
<br />
Some resources regarding meeting ''bots'', minute taking and the teleconference bridge:<br />
<br />
* [http://www.w3.org/2002/ws/addr/minutes.html Tips for Taking Minutes (thanks to Mark Nottingham)]<br />
* [http://www.w3.org/2002/03/RRSAgent RRSAgent IRC Bot Description]<br />
<br />
==Starting a meeting==<br />
<br />
The Chair or Team contact will ensure all of the relevant meeting bots are invited to the meeting before the meeting starts. <br />
<br />
To start a meeting, please invite Zakim to the IRC channel if it's not already there, then type:<br />
<br />
* <code>zakim, start meeting</code><br />
<br />
==Meeting ''Scribes''==<br />
<br />
Each meeting will have one or more ''Scribes'' that are responsible for recording the meeting's ''minutes'' directly in the group's IRC channel. The group will use the [http://www.w3.org/2002/03/RRSAgent RRSAgent] IRC bot to facilitate taking minutes. <br />
<br />
Among the general expectations of the '''Chair''' or ''Scribe'' are:<br />
<br />
* Record meeting boilerplate via the following keywords:<br />
** <code>'''ScribeNick''': scribe's_IRC_Nick</code><br />
*** Example: <code>ScribeNick: ArtB</code><br />
** <code>'''Scribe''': Firstname_LastName</code><br />
*** Example: <code>Scribe: Art_Barstow</code><br />
** <code>'''Agenda''': URI_of_the_draft_agenda</code><br />
*** Example: <code>Agenda: http://lists.w3.org/Archives/Public/public-pointer-events/2012OctDec/0048.html</code><br />
** <code>'''Chair''': Firstname_Lastname</code><br />
*** Example: <code>Chair: Patrick H. Lauke</code><br />
<br />
<br />
* Use the '''Present''' macro to record '''all''' meeting participants. The general syntax to add one person is ''Present+ Firstname_Lastname'' and a comma-separated list is used to add additional attendees. For a list of the group's participants, see [http://www.w3.org/2000/09/dbwg/details?group=59096&public=1 Public group list]. Examples: <br />
**<code>Present+ Art_Barstow</code><br />
**<code>Present+ Art_Barstow, Doug_Schepers</code><br />
<br />
<br />
* Use the '''Regrets''' macro to record the names of those members that sent advanced regrets. Examples:<br />
** <code>Regrets: Art_Barstow</code><br />
** <code>Regrets: Art_Barstow, Doug_Schepers</code><br />
** <code>Regrets+ Doug_Schepers</code><br />
<br />
<br />
* Note the start of a new discussion '''Topic''' via the "Topic: Title of the topic ..." macro. Example:<br />
** <code>Topic: Issue 123: Event X's Y attribute is underspecified</code><br />
<br />
* Record '''Resolutions''' via the "RESOLUTION: Description of the resolution ..." macro. Example:<br />
** <code>RESOLUTION: Event X's Y attribute will be a DOMString</code><br />
<br />
The general expectations regarding the scribing of the actual discussion are:<br />
<br />
* '''Scribe''': try to capture the general flow of the discussion, citing the person that speaks and use "'''...'''" at the start of a line to capture the continuation of a person's input. The name assigned to a person can be their first name e.g. ''Art'' or their initials e.g. ''AB'' or their IRC nick e.g. ''ArtB''. If you use initials and two or more participants have the same initials, create some type of unique id for each participant. Examples:<br />
**<code>AB: One line captures my comment</code><br />
**<code>Art: One line captures this comment</code><br />
**<code>ArtB: the 1st thing I want to say is ...</code><br />
**<code>... 2nd thing is ...</code><br />
**<code>... 3rd thing is ...</code><br />
<br />
* '''All''': use the "''s/text that was recorded/text that should have been recorded/''" macro (possibly with "g" appended to the end to signify the change should be made to the entire minutes) to update the meeting minutes. Examples:<br />
**<code>s/change attribute to unsigned long/change attribute to long/</code><br />
**<code>s/Issue 1234/Issue 1235/g</code><br />
<br />
* '''All''': every person that attends the meeting is responsible for the accuracy of the minutes. This means that if the Scribe did not accurately capture an attendees' input, or missed an important input, the attendee is responsible for correcting the meeting record, preferably by making the correction directly in the ongoing meeting's IRC channel.<br />
<br />
=== Ending the meeting and Announcing Minutes ===<br />
<br />
The Chair or Team contact will send the Draft meeting minutes to the group's Public mail list.<br />
<br />
To end a meeting, type:<br />
<br />
* <code>zakim, end meeting</code><br />
<br />
The minutes announcement sent to the mail list should include both the URL of the minutes as well as a copy-and-paste of the minutes. See [http://www.w3.org/2014/12/09-pointerevents-minutes.html example].<br />
<br />
==Face-to-Face Meetings==<br />
<br />
Although the group may have up to three face-to-face meetings per year, currently, no f2f meetings are scheduled.<br />
<br />
==Minutes==<br />
<br />
All meeting minutes are Public unless, on an exceptional basis, there is consensus for the minutes to be Member confidential. Links to all of the meeting minutes are consolidated in the [http://www.w3.org/wiki/PointerEvents/Minutes Minutes Wiki]. <br />
<br />
The general expectation is a meeting's Chair will send the minutes to the group's mail list within 24 hours of the end of the meeting.</div>Plehegarhttps://www.w3.org/wiki/index.php?title=PointerEvents/Meetings&diff=110985PointerEvents/Meetings2020-01-15T15:39:54Z<p>Plehegar: </p>
<hr />
<div>The Pointer Events group has two types of meetings and this document includes general information about the meetings:<br />
<br />
# Distributed meetings, aka teleconferences and voice conferences<br />
# Face-to-face (f2f) meetings <br />
<br />
SeeAlso:<br />
<br />
* [http://www.w3.org/wiki/PointerEvents/WGCode The WG's ''Code''] - describes how the group ''actually'' operates including links to various resources<br />
* [https://github.com/w3c/pointerevents GitHub repository] - GitHub is used for all bugs, issues, and as a tracker for spec-related actions<br />
* [http://lists.w3.org/Archives/Public/public-pointer-events/ public-pointer-events] - archive of the group's Public mail list<br />
<br />
==Agendas==<br />
<br />
Draft agendas for '''''distributed meetings''''' are sent to the group's [http://lists.w3.org/Archives/Public/public-pointer-events/ public-pointer-events] mail list at least 24 hours before the meeting starts.<br />
<br />
'''''F2f meetings''''' are announced at least eight weeks before the start of the meeting. Draft agendas for ''f2f meetings'' are sent to the group's [http://lists.w3.org/Archives/Public/public-pointer-events/ public-pointer-events] mail list at least two weeks before the meeting begins.<br />
<br />
==IRC and Meeting Resources ==<br />
IRC will be used for every meeting to record minutes. The group's IRC channel is '''#pointerevents''' (irc://irc.w3.org/).<br />
<br />
If you do do not have an IRC client, or have trouble connecting to IRC from behind a firewall, W3C offers a browser-based [http://irc.w3.org/ IRC Web interface] (note: you must have a Member or Invited Expert account to use this).<br />
<br />
Some resources regarding meeting ''bots'', minute taking and the teleconference bridge:<br />
<br />
* [http://www.w3.org/2002/ws/addr/minutes.html Tips for Taking Minutes (thanks to Mark Nottingham)]<br />
* [http://www.w3.org/2002/03/RRSAgent RRSAgent IRC Bot Description]<br />
<br />
==Meeting ''Scribes''==<br />
<br />
Each meeting will have one or more ''Scribes'' that are responsible for recording the meeting's ''minutes'' directly in the group's IRC channel. The group will use the [http://www.w3.org/2002/03/RRSAgent RRSAgent] IRC bot to facilitate taking minutes. <br />
<br />
When someone joins the meeting via the phone bridge, the Zakim bot will announce the participant by their phone number or some other identifier. To associate a person's name with a phone number, use the following, assuming Zakim reports someone is using phone number ''+1.519.880.aaaa'' and that someone is Rick Byers:<br />
<br />
*<code>zakim, aaaa is Rick_Byers</code> (Note: only the last four digits/letters of the phone number is used)<br />
<br />
If Zakim reports a person has joined with an identifier such as ''+[IPCaller]'' or ''+[Microsoft]'', those ids can be mapped to names via the following, assuming the former is actually Olli Pettay and the later is Jacob Rossi:<br />
<br />
*<code>zakim, [IPCaller] is Olli_Pettay</code><br />
*<code>zakim, [Microsoft] is Jacob_Rossi</code><br />
<br />
<br />
Among the general expectations of the '''Chair''' or ''Scribe'' are:<br />
<br />
* Record meeting boilerplate via the following keywords:<br />
** <code>'''ScribeNick''': scribe's_IRC_Nick</code><br />
*** Example: <code>ScribeNick: ArtB</code><br />
** <code>'''Scribe''': Firstname_LastName</code><br />
*** Example: <code>Scribe: Art_Barstow</code><br />
** <code>'''Agenda''': URI_of_the_draft_agenda</code><br />
*** Example: <code>Agenda: http://lists.w3.org/Archives/Public/public-pointer-events/2012OctDec/0048.html</code><br />
** <code>'''Date''': Day Month Year</code><br />
*** Example: <code>Date: 27 November 2012</code><br />
** <code>'''Chair''': Firstname_Lastname</code><br />
*** Example: <code>Chair: Art_Barstow</code><br />
** <code>'''Meeting''': Pointer Events WG Voice Conference</code><br />
<br />
<br />
* Use the '''Present''' macro to record '''all''' meeting participants. The general syntax to add one person is ''Present+ Firstname_Lastname'' and a comma-separated list is used to add additional attendees. For a list of the group's participants, see [http://www.w3.org/2000/09/dbwg/details?group=59096&public=1 Public group list]. Examples: <br />
**<code>Present+ Art_Barstow</code><br />
**<code>Present+ Art_Barstow, Doug_Schepers</code><br />
<br />
<br />
* Use the '''Regrets''' macro to record the names of those members that sent advanced regrets. Examples:<br />
** <code>Regrets: Art_Barstow</code><br />
** <code>Regrets: Art_Barstow, Doug_Schepers</code><br />
** <code>Regrets+ Doug_Schepers</code><br />
<br />
<br />
* Note the start of a new discussion '''Topic''' via the "Topic: Title of the topic ..." macro. Example:<br />
** <code>Topic: Issue 123: Event X's Y attribute is underspecified</code><br />
<br />
<br />
* Create new '''Actions''' via the "ACTION: last_name Title of the action ..." macro (see [http://www.w3.org/2000/09/dbwg/details?group=59096&public=1 group participation list] for a list of ''last_names''). Example:<br />
**<code>ACTION: barstow Start a CfC for ...</code><br />
<br />
<br />
* Record '''Resolutions''' via the "RESOLUTION: Description of the resolution ..." macro. Example:<br />
** <code>RESOLUTION: Event X's Y attribute will be a DOMString</code><br />
<br />
<br />
The general expectations regarding the scribing of the actual discussion are:<br />
<br />
* '''Scribe''': try to capture the general flow of the discussion, citing the person that speaks and use "'''...'''" at the start of a line to capture the continuation of a person's input. The name assigned to a person can be their first name e.g. ''Art'' or their initials e.g. ''AB'' or their IRC nick e.g. ''ArtB''. If you use initials and two or more participants have the same initials, create some type of unique id for each participant. Examples:<br />
**<code>AB: One line captures my comment</code><br />
**<code>Art: One line captures this comment</code><br />
**<code>ArtB: the 1st thing I want to say is ...</code><br />
**<code>... 2nd thing is ...</code><br />
**<code>... 3rd thing is ...</code><br />
<br />
* '''All''': use the "''s/text that was recorded/text that should have been recorded/''" macro (possibly with "g" appended to the end to signify the change should be made to the entire minutes) to update the meeting minutes. Examples:<br />
**<code>s/change attribute to unsigned long/change attribute to long/</code><br />
**<code>s/Issue 1234/Issue 1235/g</code><br />
<br />
* '''All''': every person that attends the meeting is responsible for the accuracy of the minutes. This means that if the Scribe did not accurately capture an attendees' input, or missed an important input, the attendee is responsible for correcting the meeting record, preferably by making the correction directly in the ongoing meeting's IRC channel.<br />
<br />
=== Generating and Announcing Minutes ===<br />
<br />
The Chair or Team contact will ensure all of the relevant meeting bots are invited to the meeting before the meeting starts and they will send the Draft meeting minutes to the group's Public mail list. <br />
<br />
To generate the minutes, the Scribe must issue the following command:<br />
<br />
* <code>RRSAgent, make log Public</code><br />
* <code>RRSAgent, make minutes</code><br />
<br />
The minutes announcement sent to the mail list should include both the URL of the minutes as well as a copy-and-paste of the minutes. See [http://www.w3.org/2014/12/09-pointerevents-minutes.html example].<br />
<br />
==Face-to-Face Meetings==<br />
<br />
Although the group may have up to three face-to-face meetings per year, currently, no f2f meetings are scheduled.<br />
<br />
==Minutes==<br />
<br />
All meeting minutes are Public unless, on an exceptional basis, there is consensus for the minutes to be Member confidential. Links to all of the meeting minutes are consolidated in the [http://www.w3.org/wiki/PointerEvents/Minutes Minutes Wiki]. <br />
<br />
The general expectation is a meeting's Chair will send the minutes to the group's mail list within 24 hours of the end of the meeting.</div>Plehegarhttps://www.w3.org/wiki/index.php?title=PointerEvents/Meetings&diff=110984PointerEvents/Meetings2020-01-15T15:37:35Z<p>Plehegar: </p>
<hr />
<div>The Pointer Events group has two types of meetings and this document includes general information about the meetings:<br />
<br />
# Distributed meetings, aka teleconferences and voice conferences<br />
# Face-to-face (f2f) meetings <br />
<br />
SeeAlso:<br />
<br />
* [http://www.w3.org/wiki/PointerEvents/WGCode The WG's ''Code''] - describes how the group ''actually'' operates including links to various resources<br />
* [https://github.com/w3c/pointerevents GitHub repository] - GitHub is used for all bugs, issues, and as a tracker for spec-related actions<br />
* [http://lists.w3.org/Archives/Public/public-pointer-events/ public-pointer-events] - archive of the group's Public mail list<br />
<br />
==Agendas==<br />
<br />
Draft agendas for '''''distributed meetings''''' are sent to the group's [http://lists.w3.org/Archives/Public/public-pointer-events/ public-pointer-events] mail list at least 24 hours before the meeting starts.<br />
<br />
'''''F2f meetings''''' are announced at least eight weeks before the start of the meeting. Draft agendas for ''f2f meetings'' are sent to the group's [http://lists.w3.org/Archives/Public/public-pointer-events/ public-pointer-events] mail list at least two weeks before the meeting begins.<br />
<br />
==IRC and Meeting Resources ==<br />
IRC will be used for every meeting to record minutes. The group's IRC channel is '''#pointerevents''' (irc://irc.w3.org/).<br />
<br />
If you do do not have an IRC client, or have trouble connecting to IRC from behind a firewall, W3C offers a browser-based [http://cgi.w3.org/member-bin/irc/irc.cgi IRC Web interface] (note: you must have a Member or Invited Expert account to use this).<br />
<br />
Some resources regarding meeting ''bots'', minute taking and the teleconference bridge:<br />
<br />
* [http://www.w3.org/2002/ws/addr/minutes.html Tips for Taking Minutes (thanks to Mark Nottingham)]<br />
* [http://www.w3.org/2002/03/RRSAgent RRSAgent IRC Bot Description]<br />
<br />
==Meeting ''Scribes''==<br />
<br />
Each meeting will have one or more ''Scribes'' that are responsible for recording the meeting's ''minutes'' directly in the group's IRC channel. The group will use the [http://www.w3.org/2002/03/RRSAgent RRSAgent] IRC bot to facilitate taking minutes. <br />
<br />
When someone joins the meeting via the phone bridge, the Zakim bot will announce the participant by their phone number or some other identifier. To associate a person's name with a phone number, use the following, assuming Zakim reports someone is using phone number ''+1.519.880.aaaa'' and that someone is Rick Byers:<br />
<br />
*<code>zakim, aaaa is Rick_Byers</code> (Note: only the last four digits/letters of the phone number is used)<br />
<br />
If Zakim reports a person has joined with an identifier such as ''+[IPCaller]'' or ''+[Microsoft]'', those ids can be mapped to names via the following, assuming the former is actually Olli Pettay and the later is Jacob Rossi:<br />
<br />
*<code>zakim, [IPCaller] is Olli_Pettay</code><br />
*<code>zakim, [Microsoft] is Jacob_Rossi</code><br />
<br />
<br />
Among the general expectations of the '''Chair''' or ''Scribe'' are:<br />
<br />
* Record meeting boilerplate via the following keywords:<br />
** <code>'''ScribeNick''': scribe's_IRC_Nick</code><br />
*** Example: <code>ScribeNick: ArtB</code><br />
** <code>'''Scribe''': Firstname_LastName</code><br />
*** Example: <code>Scribe: Art_Barstow</code><br />
** <code>'''Agenda''': URI_of_the_draft_agenda</code><br />
*** Example: <code>Agenda: http://lists.w3.org/Archives/Public/public-pointer-events/2012OctDec/0048.html</code><br />
** <code>'''Date''': Day Month Year</code><br />
*** Example: <code>Date: 27 November 2012</code><br />
** <code>'''Chair''': Firstname_Lastname</code><br />
*** Example: <code>Chair: Art_Barstow</code><br />
** <code>'''Meeting''': Pointer Events WG Voice Conference</code><br />
<br />
<br />
* Use the '''Present''' macro to record '''all''' meeting participants. The general syntax to add one person is ''Present+ Firstname_Lastname'' and a comma-separated list is used to add additional attendees. For a list of the group's participants, see [http://www.w3.org/2000/09/dbwg/details?group=59096&public=1 Public group list]. Examples: <br />
**<code>Present+ Art_Barstow</code><br />
**<code>Present+ Art_Barstow, Doug_Schepers</code><br />
<br />
<br />
* Use the '''Regrets''' macro to record the names of those members that sent advanced regrets. Examples:<br />
** <code>Regrets: Art_Barstow</code><br />
** <code>Regrets: Art_Barstow, Doug_Schepers</code><br />
** <code>Regrets+ Doug_Schepers</code><br />
<br />
<br />
* Note the start of a new discussion '''Topic''' via the "Topic: Title of the topic ..." macro. Example:<br />
** <code>Topic: Bug 12345: Event X's Y attribute is underspecified</code><br />
<br />
<br />
* Create new '''Actions''' via the "ACTION: last_name Title of the action ..." macro (see [http://www.w3.org/2000/09/dbwg/details?group=59096&public=1 group participation list] for a list of ''last_names''). Example:<br />
**<code>ACTION: barstow Start a CfC for ...</code><br />
<br />
<br />
* Record '''Resolutions''' via the "RESOLUTION: Description of the resolution ..." macro. Example:<br />
** <code>RESOLUTION: Event X's Y attribute will be a DOMString</code><br />
<br />
<br />
The general expectations regarding the scribing of the actual discussion are:<br />
<br />
* '''Scribe''': try to capture the general flow of the discussion, citing the person that speaks and use "'''...'''" at the start of a line to capture the continuation of a person's input. The name assigned to a person can be their first name e.g. ''Art'' or their initials e.g. ''AB'' or their IRC nick e.g. ''ArtB''. If you use initials and two or more participants have the same initials, create some type of unique id for each participant. Examples:<br />
**<code>AB: One line captures my comment</code><br />
**<code>Art: One line captures this comment</code><br />
**<code>ArtB: the 1st thing I want to say is ...</code><br />
**<code>... 2nd thing is ...</code><br />
**<code>... 3rd thing is ...</code><br />
<br />
* '''All''': use the "''s/text that was recorded/text that should have been recorded/''" macro (possibly with "g" appended to the end to signify the change should be made to the entire minutes) to update the meeting minutes. Examples:<br />
**<code>s/change attribute to unsigned long/change attribute to long/</code><br />
**<code>s/Bug 1234/Bug 1235/g</code><br />
<br />
* '''All''': every person that attends the meeting is responsible for the accuracy of the minutes. This means that if the Scribe did not accurately capture an attendees' input, or missed an important input, the attendee is responsible for correcting the meeting record, preferably by making the correction directly in the ongoing meeting's IRC channel.<br />
<br />
=== Generating and Announcing Minutes ===<br />
<br />
The Chair or Team contact will ensure all of the relevant meeting bots are invited to the meeting before the meeting starts and they will send the Draft meeting minutes to the group's Public mail list. <br />
<br />
To generate the minutes, the Scribe must issue the following command:<br />
<br />
* <code>RRSAgent, make log Public</code><br />
* <code>RRSAgent, make minutes</code><br />
<br />
The minutes announcement sent to the mail list should include both the URL of the minutes as well as a copy-and-paste of the minutes. See [http://www.w3.org/2014/12/09-pointerevents-minutes.html example].<br />
<br />
==Face-to-Face Meetings==<br />
<br />
Although the group may have up to three face-to-face meetings per year, currently, no f2f meetings are scheduled.<br />
<br />
==Minutes==<br />
<br />
All meeting minutes are Public unless, on an exceptional basis, there is consensus for the minutes to be Member confidential. Links to all of the meeting minutes are consolidated in the [http://www.w3.org/wiki/PointerEvents/Minutes Minutes Wiki]. <br />
<br />
The general expectation is a meeting's Chair will send the minutes to the group's mail list within 24 hours of the end of the meeting.</div>Plehegarhttps://www.w3.org/wiki/index.php?title=PointerEvents/WGCode&diff=110983PointerEvents/WGCode2020-01-15T15:35:27Z<p>Plehegar: </p>
<hr />
<div>The purpose of this document - aka The WG Code - is to describe some of the Pointer Events WG's ''actual working processes'' including: Call for Consensus, Decision Process, Meeting Regrets, etc.<br />
<br />
'''Note the [https://www.w3.org/2018/12/pointerevents-charter.html group's Charter] formally defines many aspects of the group's working processes. In all cases, the Charter and/or the [http://www.w3.org/Consortium/Process/ W3C Process Document] overrides the information in this wiki. Nevertheless, this wiki contains additional information about how the group ''really'' works and as such, this information may be particularly useful to new members of the WG as well as ''outsiders'' interested in this group's work.'''<br />
<br />
This document is a ''Living Document'' and as such will change. Members of the WG are encouraged to edit (e.g. to embellish, correct, update etc.) the information in this document.<br />
<br />
<br />
== Consensus and Call for Consensus (CfC) ==<br />
Consensus is a very important part of the W3C process and is [https://www.w3.org/Consortium/Process#Consensus formally codified in the Process Document] as follows:<br />
<br />
::Consensus is a core value of the W3C. To promote consensus, the W3C process requires Chairs to ensure that groups consider all legitimate views and objections, and endeavor to resolve them, whether these views and objections are expressed by the active participants of the group or by others (e.g., another W3C group, a group in another organization, or the general public).<br />
<br />
Since most of the group's technical work is done asynchronously (e.g. via the mail list), the group may use a ''Call for Consensus'' (aka CfC) mechanism (typically e-mail) to formally gather input on a specific question such as ''Is spec X ready to publish as a Last Call Work ing Draft?''. '''When a CfC is issued, an explicit response from group members is preferred and encouraged, and note that the lack of a response will always be considered as agreement with the proposal.'''<br />
<br />
Most CfC's are done on the public-pointer-events mail list and the comment period is typically one week. However, in some rare cases, for example when Member confidentially is an issue, the group's Member-only mail list may be used.<br />
<br />
== Participation and ''Regrets'' Policy ==<br />
The group's charter formally defines the [https://www.w3.org/2018/12/pointerevents-charter.html#participation Participation] expecations including the requirements for Editors. In addition to this process:<br />
<br />
* If an Editor or other active contributor is not able to attend a group meeting and a relevant discussion and/or decision is expected, ''those active participants are expected to send regrets before the meeting''. (The regrets may be sent to the either of the group's mail lists, the group Chair or the group Staff Contact.)<br />
<br />
== Decision Process ==<br />
<br />
The charter formally defines the group's [https://www.w3.org/2018/12/pointerevents-charter.html#decisions Decision Poliy]. In addition to this policy:<br />
<br />
* The group may make decisions during meetings<br />
* Asynchronous Call for Consensus (CfC) will be used to determine consensus on a question, issue, etc.<br />
* If an active participant does not attend a meeting and that participant sent advanced ''regrets'', the group should not make a final decision until such participants have provided input on the decision<br />
<br />
== Editing Policy ==<br />
<br />
'''Editors in this group have wide freedom to update (add, change, delete) text in ''Editor's Drafts'' (ED) without explicit consensus from the group. This method is referred to as ''Edit First and Review Later'' and is contrary to other groups that follow a ''Review First and Edit Later'' editing model.'''<br />
<br />
Does this does mean group members' input is not taken into account? '''No.''' Editors are expected to consider all inputs and to reflect that input in the ED.<br />
<br />
'''Note: before the group formally publishes a specification as a ''Technical Report'' (i.e. a copy of the spec is placed in the [http://www.w3.org/TR/ Technical Reports repository]), group members will be asked if there is consensus to publish the specification, possibly by using a CfC.<br />
<br />
Editor Resources:<br />
<br />
* Old WebApps' [http://www.w3.org/wiki/Webapps/SpecEditing SpecEditing] wiki for information about spec editing, including Editor roles and responsibilities.<br />
* [https://w3c.github.io/workflow.html Workflow for editors and other contributors]</div>Plehegarhttps://www.w3.org/wiki/index.php?title=PointerEvents&diff=110982PointerEvents2020-01-15T15:31:45Z<p>Plehegar: Refreshed</p>
<hr />
<div>Wiki for the [http://www.w3.org/2012/pointerevents/ Pointer Events Working Group] and the [http://www.w3.org/TR/pointerevents/ Pointer Events standard].<br />
<br />
Resources:<br />
<br />
* [http://www.w3.org/2012/pointerevents/ Group homepage]<br />
* [https://www.w3.org/PM/Groups/chairboard.html?gid=59096 Group dashboard] - the group's dashboard, including publication status, etc.<br />
* [http://www.w3.org/wiki/PointerEvents/ Group's wiki]<br />
* [http://www.w3.org/wiki/PointerEvents/WGCode Group's ''Work Mode'']<br />
* [https://www.w3.org/wiki/PointerEvents/Meetings Meetings]<br />
* [http://www.w3.org/wiki/PointerEvents/Minutes Meeting minutes archive]<br />
* [https://github.com/w3c/pointerevents GitHub repository (bugs, issues, action tracker)]<br />
* [http://lists.w3.org/Archives/Public/public-pointer-events/ Mail list archive]<br />
<br />
Historical:<br />
<br />
* [https://www.w3.org/Bugs/Public/buglist.cgi?component=Pointer%20Events%20specification&list_id=33665&product=PointerEventsWG&resolution=--- OLD Bugzilla bug database] and [http://lists.w3.org/Archives/Public/public-pointer-events-bugzilla/ mail list archive for all bug activity]<br />
* [http://www.w3.org/wiki/PointerEvents/UseCasesAndRequirements Use Cases and Requirements for v1]<br />
* [https://www.w3.org/wiki/PointerEvents/UseCasesAndRequirements#Requirements:_Pointer_Events_v.Next_Specification Use Cases and Requirements for v2]</div>Plehegarhttps://www.w3.org/wiki/index.php?title=PointerEvents/PubStatus&diff=110981PointerEvents/PubStatus2020-01-15T15:30:03Z<p>Plehegar: </p>
<hr />
<div><p style='border: 5px solid red; padding: 1ex;text-align: center'><br />
'''Deprecated''': see the [https://www.w3.org/PM/Groups/chairboard.html?gid=59096 Group dashboard] instead.<br />
</p><br />
<br />
This document used to contain data regarding the ''Publication Status'' of specifications being developed by the [http://www.w3.org/2012/pointerevents/ Pointer Events WG].</div>Plehegarhttps://www.w3.org/wiki/index.php?title=PointerEvents/PubStatus&diff=110980PointerEvents/PubStatus2020-01-15T15:28:25Z<p>Plehegar: Deprecated</p>
<hr />
<div><p style='border: 5px solid red; padding: 1ex;text-align: center'><br />
'''Deprecated''': see the [https://www.w3.org/PM/Groups/chairboard.html?gid=59096 Group dashboard] instead.<br />
</p><br />
<br />
This document contains current data regarding the ''Publication Status'' of specifications being developed by the [http://www.w3.org/2012/pointerevents/ Pointer Events WG].<br />
<br />
Please see the section ''[http://www.w3.org/wiki/PointerEvents/PubStatus#Table_Key Table Key]'' for information regarding interpreting the data in the tables.<br />
<br />
<br />
== Specifications ==<br />
{| style="background-color:#ffffcc;" border="1" cellpadding="10" cellspacing="0"<br />
!+ colspan="6"|Specifications<br />
|-<br />
!Spec, Active Editor(s)<br />
!Last TR Publication<br />
!Type <br />
!Remarks<br />
!Testing<br />
!Plans<br />
|-<br />
|[https://www.w3.org/TR/pointerevents/ Pointer Events], Jacob Rossi, Matt Brubeck<br />
|[http://w3.org/TR/pointerevents/ 2015-Feb-24]<br />
|REC<br />
|[https://www.w3.org/Bugs/Public/buglist.cgi?product=PointerEventsWG&component=Pointer%20Events%20specification&resolution=---&list_id=2680 Bug database]<br />
|[https://github.com/w3c/web-platform-tests/tree/master/pointerevents Test suite];<br />
Test Facilitator: Matt Brubeck;<br />
|Process errata if/when needed.<br />
|-<br />
|[https://w3c.github.io/pointerevents/ Pointer Events - Level 2], Jacob Rossi, Matt Brubeck, Rick Byers, Patrick H. Lauke<br />
|[https://www.w3.org/TR/pointerevents2/ 2016-Jul-19]<br />
|ED<br />
|[https://github.com/w3c/pointerevents GitHub repository]<br />
|<br />
|<br />
|}<br />
<br />
== Table Key ==<br />
<br />
The tables above use the following abbreviations and conventions:<br />
<br />
* The link in the ''Name of Spec' column is the document's ''Editor's Draft''<br />
* The ''Last Publication'' column contains the date of the most recent formal publication as a W3C ''[http://www.w3.org/TR/ Technical Report]'' <br />
* ED = Editor's Draft<br />
* FPWD = [http://www.w3.org/2005/10/Process-20051014/tr.html#first-wd First Public Working Draft]<br />
* WD = [http://www.w3.org/2005/10/Process-20051014/tr.html#q73 Working Draft]<br />
* LC, LCWD = [http://www.w3.org/2005/10/Process-20051014/tr.html#last-call Last Call] (Working Draft)<br />
* CR = [http://www.w3.org/2005/10/Process-20051014/tr.html#cfi Candidate Recommendation]<br />
* PR = [http://www.w3.org/2005/10/Process-20051014/tr.html#cfr Proposed Recommendation]<br />
* REC = [http://www.w3.org/2005/10/Process-20051014/tr.html#rec-publication Recommendation]<br />
<br />
* No Formal Pub = the document has not yet been formally published by the W3C as a ''[http://www.w3.org/TR/ Technical Report]''.</div>Plehegarhttps://www.w3.org/wiki/index.php?title=PointerEvents/&diff=110979PointerEvents/2020-01-15T15:24:57Z<p>Plehegar: Updated</p>
<hr />
<div>This is the top-level wiki of the W3C's [http://www.w3.org/2012/pointerevents/ Pointer Events Working Group], chartered to "''provide methods to enable simple device independent input from pointing devices such as mouse, pen, and multi-touch screen''".<br />
<br />
Feedback on the group's work and the deliverables is welcome, via the WG's [https://github.com/w3c/pointerevents/ GitHub repository] and [http://lists.w3.org/Archives/Public/public-pointer-events/ public-pointer-events] mail list.<br />
<br />
SeeAlso:<br />
<br />
* [http://www.w3.org/2012/pointerevents/ Group homepage]<br />
* [http://www.w3.org/wiki/PointerEvents/PubStatus Publication Status] - the group's specification list including publication status <br />
* [http://www.w3.org/wiki/PointerEvents/WGCode The WG's ''Code''] - describes how the group ''actually'' operates including links to various resources<br />
* [https://github.com/w3c/pointerevents/ GitHub Repository] - used for all specifications, tests, and to track bugs, issues and spec-related actions<br />
* [http://lists.w3.org/Archives/Public/public-pointer-events/ public-pointer-events] - archive of the group's Public mail list<br />
* [http://www.w3.org/wiki/PointerEvents/UseCasesAndRequirements Use Cases and Requirements for v1 and v2] - scenarios to be addressed today, and in potential future versions.<br />
<br />
<br />
==Charter==<br />
<br />
See [http://www.w3.org/2012/pointerevents/ Group homepage].<br />
<br />
==Meetings==<br />
The group has topic-specific distributed teleconferences [http://www.w3.org/wiki/PointerEvents/Meetings Meetings] and some face-to-face (f2f) meetings. All of the group's meeting [http://www.w3.org/wiki/PointerEvents/Minutes Minutes] are Publicly available and draft meeting agendas are submitted to the group's [http://lists.w3.org/Archives/Public/public-pointer-events/ public-pointer-events] mail list.<br />
<br />
==Specifications==<br />
All of the group's documents are on GitHub ([https://github.com/w3c/pointerevents https://github.com/w3c/pointerevents]).<br />
<br />
See the [https://www.w3.org/PM/Groups/chairboard.html?gid=59096 Group dashboard] for the latest publication status regarding all of the group's specifications.<br />
<br />
==Testing==<br />
The group's [https://github.com/web-platform-tests/wpt/tree/master/pointerevents tests] are part of the W3C's [https://github.com/web-platform-tests/wpt/ web-platform-tests] repository on GitHub. The tests can be run directly in a user agent via the <code>[http://wpt.fyi/web-platform-tests/master/pointerevents/ pointerevents]</code> HTTP mirror.<br />
<br />
The group's testing process is defined in the [http://www.w3.org/wiki/PointerEvents/Testing Testing wiki] (this group follows the general testing process used by the Web Applications group).<br />
<br />
==Tracking Bugs, Issues and Actions==<br />
<br />
* Bug and Issue tracking - [https://github.com/w3c/pointerevents GitHub] is used to track Bugs and Issues. Both Group members and non group members may submit bugs, issues and suggestions to the GitHub repository or to the group's <code>public-pointer-events</code> mailing list ([http://lists.w3.org/Archives/Public/public-pointer-events archive].<br />
<br />
==Group Membership==<br />
A list of W3C Members organizations formally participating in this group is provided in [http://www.w3.org/2004/01/pp-impl/59096/status ''Member List''] and [http://www.w3.org/2000/09/dbwg/details?group=59096&public=1 ''Participant List''] identifies the individuals in the group.<br />
<br />
==Coordination with Other Working Groups==<br />
The group's specifications are relevant to some other W3C Working Groups as documented in the charter. <br />
<br />
==Liaisons With External Groups==<br />
Currently, the group has no formal liaisons with organizations or groups outside of the W3C.</div>Plehegarhttps://www.w3.org/wiki/index.php?title=TPAC/2019/SessionIdeas&diff=110078TPAC/2019/SessionIdeas2019-09-04T20:21:19Z<p>Plehegar: /* Introduction to W3C */</p>
<hr />
<div>We encourage attendees to start brainstorming [[TPAC/2019]] Wednesday 18 September 2019 '''Technical Plenary Day''' Breakout sessions in advance of the meeting and until '''Tuesday 17 September 5 pm local time'''. <br />
<br />
See the [[TPAC/2019/FAQ | TPAC 2019 FAQ]] for more information. <br />
<br />
== How to use this page ==<br />
<br />
Please use this page to:<br />
<br />
* Propose sessions you wish you lead<br />
* Propose sessions you wish others to lead (it's a good idea to let them know ahead of time)<br />
* Indicate whether you plan to attend a session (helps with scheduling)<br />
* '''Please place new proposal at the bottom of this document'''<br />
<br />
== How to propose a session ==<br />
<br />
Please provide:<br />
<ul class="show_items"><br />
* session name (as a === subhead === )<br />
* session proposer (yourself, if so sign using 4 tildas; optional: name a desired session leader) and an email address<br />
* one sentence session summary<br />
* type of session: (e.g.: open discussion, talk, panel, etc.)<br />
* goals of session<br />
* additional speakers/panelists (to help reduce conflicts when one person is needed in more than one place)<br />
* any timing constraint you already know (e.g. you expect to invite someone in a different time zone)<br />
* if you can guess, whether you'll need a {big | medium | small} room (we can't guarantee you'll get it, however)<br />
* add an "Interested" bullet for people to sign up for sessions<br />
</ul><br />
<br />
== From an idea to a breakout ==<br />
<br />
<span style="color:#ff0000">'''The goal is to have a near-final breakout sessions schedule by the night before the plenary day (i.e. on Tuesday September 17 night), with only a few changes needed on the plenary day itself during the finalization phase at 09:45-10:30.</span><br />
<br />
This ensures a more inclusive process in how the breakout sessions are defined and scheduled (thus avoiding any mad scramble). An HTML and mobile-friendly filled-out session grid for the dayâs breakout sessions will be generated by the Team. [[TPAC/2019/FAQ#How_does_the_agenda_get_built.3F|Read more in our FAQ]].<br />
<br />
== Proposed sessions ==<br />
<br />
=== EXAMPLE session with session name ===<br />
* Proposer: <nowiki>~~~~</nowiki> (Instruction: remove <nowiki><nowiki> and </nowiki></nowiki> around the tildas. Explanation: The 4 tildas will sign YOUR name and include a timestamp of your proposal.)<br />
* Email address of proposer: <br />
* Summary (one-sentence or so): <br />
* Type of session (e.g.: open discussion, talk, panel, etc.): <br />
* Goals:<br />
* [optional] shortname (used for minting an IRC channel for the breakout)<br />
* [optional] Additional speakers/panelists:<br />
* [optional] Timing constraint: (e.g. you expect to invite someone in a different time zone)<br />
* [optional] Estimated room capacity: {big | medium | small} room<br />
<br />
=== ReSpec - so many new features! ===<br />
* Proposer: Marcos CĂĄceres<br />
* Email address of proposer: mcaceres@mozilla.com <br />
* Summary (one-sentence or so): Covering all the exciting advancements we've made in the last year, including automatic cross references, smart citations, MDN integration, and more! <br />
* Type of session: talk and open discussion <br />
* Goals: Introduce Editors to new features. <br />
* shortname: #pub<br />
* Additional speakers/panelists: Sid Vishnoi, Kagami Sascha Rosylight <br />
* [optional] Estimated room capacity: medium room<br />
<br />
=== Japan Language Requirements Task Force: Evolving the JLReq document ===<br />
* Proposer: [[User:Nmccully|Nathaniel McCully]] ([[User talk:Nmccully|talk]]) 16:29, 2 August 2019 (UTC)<br />
* Email address: nmccully@adobe.com<br />
* Summary: Explanation of the JLReq v2 effort currently underway, and a glimpse into the roadmap of a v3, that seeks to serve the needs of developers of layout engines for modern, dynamic media that support high-quality Japanese layout<br />
* Type of session: talk<br />
* Goals: To inform that this is happening, and get more people interested in the issues of high-end Japanese typography and layout in the context of responsive modern digital media.<br />
<br />
=== Results from MDN Developer Survey ===<br />
* Proposer: [[User:Dom|Dominique HazaĂŤl-Massieux]] ([[User talk:Dom|talk]]) 06:52, 5 August 2019 (UTC)<br />
* Email address: dom@w3.org<br />
* Summary: Meet the MDN Product Advisory Board and discuss how the results of the [https://hacks.mozilla.org/2019/07/mdn-web-developer-designer-survey/ MDN Developer Survey] can impact W3C's agenda<br />
* Type of session: short talk & discussion<br />
* Goals: Bring input to the MDN Product Advisory Board to see how MDN documentation can evolve to better meet the need from the W3C community; learn about the MDN Developer Survey and discuss what conclusions to draw from its results in terms of the W3C standardization agenda<br />
* Additional speakers/panelists: Kadir Topal, Dan Appelquist, Jory Burson, Travis Leithead, Joe Medley<br />
* shortname: mdn<br />
* Estimated room capacity: medium room<br />
<br />
=== Mini App Standardization ===<br />
* Proposer: [[User:laq|Angel Li]] 10:14, 14 August 2019 (UTC)<br />
* Email address: angelli.laq@alibaba-inc.com<br />
* Summary: Meet the major Mini App players, introduction of Mini App white paper drafted by W3C Chinese IG, discuss the way forward for Mini App Standardization in W3C<br />
* Type of session: short talk & discussion<br />
* Goals: help the global web community to better understand Mini App and the value of its standardization, find proper way to move forward in W3C<br />
* shortname: MiniApp<br />
* Estimated room capacity: medium room<br />
* Interested: [[User:Chris|Chris Lilley]] ([[User talk:Chris|talk]]) 13:54, 27 August 2019 (UTC)<br />
<br />
=== Web Packaging ===<br />
(Including Signed Exchanges and Bundles.)<br />
* Proposer: [[User:Jyasskin|Jeffrey Yasskin]] ([[User talk:Jyasskin|talk]]) 18:41, 14 August 2019 (UTC)<br />
* Email address of proposer: jyasskin@google.com<br />
* Summary (one-sentence or so): Discuss W3C feelings about the [Web Packaging proposal](https://github.com/WICG/webpackage).<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Short talk & discussion<br />
* Goals: Ensure everyone knows the state of the IETF discussion and the Chromium implementation; recruit collaborators; discover concerns and needed changes; get advice about what route through the W3C/WHATWG processes to follow.<br />
* [optional] shortname: wpack<br />
* [optional] Additional speakers/panelists: [[User:Kyasuda2|Kinuko Yasuda]]<br />
* [optional] Timing constraint: TBD<br />
* [optional] Estimated room capacity: medium room<br />
<br />
=== A target privacy threat model for the Web ===<br />
* Proposer: [[User:Jyasskin|Jeffrey Yasskin]] ([[User talk:Jyasskin|talk]]) 19:04, 14 August 2019 (UTC) (However, I'd love to have someone else lead this.)<br />
* Email address of proposer: jyasskin@google.com<br />
* Summary (one-sentence or so): Proposals for new features often encounter resistance from folks who want the Web Platform to defend its users' privacy better than it does today. This often surprises the authors of those proposals, who were designing against the Web's current, implicit, and weak privacy threat model. Making our privacy goals explicit could avoid those surprises and reduce the load on privacy reviewers.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Open discussion<br />
* Goals: Figure out whether there's interest in developing a target privacy threat model for the Web.<br />
* shortname: privthreatmodel<br />
* Additional speakers/panelists: [Your name here]<br />
* Timing constraint: <br />
: morning session would be preferable for East Coast remote attendees -- [[User:Npdoty|Nick Doty]] ([[User talk:Npdoty|talk]])<br />
* Estimated room capacity: large room --- with polycom to support remote attendees<br />
<br />
=== Next Generation TextTrackCue ===<br />
* Proposers: [[User:Ecarlson2|Eric Carlson]] ([[User talk:Ecarlson2|talk]]) 20:18, 15 August 2019 (UTC), [[User:Eoconnor|Theresa O'Connor]], [[User:PLemieux|Pierre-Anthony Lemieux]]<br />
* Email address of proposers: eric.carlson@apple.com,hober@apple.com,pal@sandflow.com<br />
* Summary: TextTrackCue enhancements for programmatic subtitle and caption presentation. We've been making progress since FOMS this past spring. Please see our FOMS slides for the basic idea: https://www.icloud.com/keynote/0GJUbJwWfA2i77M2JysKjj45w#Generic_Text_Cue_-_FOMS_2019<br />
* Type of session: talk and open discussion<br />
* Goals: Engage with browser engineers and media experts & gauge interest in pursuing this as new web API<br />
* shortname: textcueapi<br />
* Estimated room capacity: medium room (~20 people)<br />
<br />
=== JS Built-In Modules ===<br />
* Proposer: [[User:dcrousso|Devin Rousso]] ([[User talk:dcrousso|talk]]) 22:05, 15 August 2019 (UTC)<br />
* Email address of proposer: dcrousso@apple.com<br />
* Summary (one-sentence or so): introduction to the concept of JS Built-In Modules, as well as an overview of the currently proposed governance model<br />
* Type of session: talk<br />
* Goals: disseminate knowledge of JS Built-In modules to other hosts built on top of JavaScript (e.g. web browsers), and introduce the proposed governance model to potential stakeholders of additional JS Built-In Module namespaces (e.g. web:)<br />
* Additional speakers: Michael Saboff <msaboff@apple.com> (call-in TC39 proposal champion)<br />
* Timing constraint: friendly towards PST<br />
* Estimated room capacity: medium room<br />
<br />
=== WebTransport status and next steps ===<br />
* Proposer: Peter Thatcher<br />
* Email address of proposer: pthatcher@google.com<br />
* Summary (one-sentence or so): Discuss [https://github.com/WICG/web-transport WebTransport API] and next steps for a WG or CG<br />
* Type of session: short talk (maybe demo too) & discussion<br />
* Goals: Ensure everyone is up to date on the latest API, implementation status, and interaction with the IETF ([https://mailarchive.ietf.org/arch/browse/webtransport/ link to mailing list]; [https://tools.ietf.org/wg/dispatch/minutes link to DISPATCH minutes]); determine when and how we should create a WG or CG; discuss advanced API topics such as how best to use WHATWG streams, how to handle congestion control, and stream prioritization<br />
* Shortname: webtransport<br />
* Estimated room capacity: medium room<br />
<br />
=== Web stories ===<br />
* Proposer: [[User:Coralie|Coralie Mercier]] ([[User talk:Coralie|talk]]) 15:45, 20 August 2019 (UTC)<br />
* Email address of proposer: coralie@w3.org<br />
* Summary: Feedback and brainstorming for (re)introducing the Web Consortium to the public. The W3C Comm team wants to get background stories from our Members and community about how they were drawn to the Web (before the Web, or their first involvement with the Web). There is a path for how everyone in our community has come to the Web, what they see happening now and what they see in the future.<br />
* Type of session: open discussion<br />
* Goals: We want to gather stories in order to tell a compelling story to the public. W3C Comm team may use this as part of an upcoming crowdfunding campaign.<br />
* shortname: webstories<br />
* Estimated room capacity: medium room<br />
* Interested:<br />
** ...<br />
<br />
=== WebGPU ===<br />
* Proposer: Myles C. Maxfield<br />
* Email address of proposer: mmaxfield@apple.com<br />
* Summary (one-sentence or so): Update on the progress of WebGPU, and group discussion about future directions and what to focus on<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Talk and open discussion<br />
* Goals: Help people understand the direction that WebGPU is going, and get feedback from the broader community<br />
* [optional] shortname (used for minting an IRC channel for the breakout): webgpu<br />
* [optional] Additional speakers/panelists: Dean Jackson, anyone else in the CG<br />
* [optional] Estimated room capacity: medium room?<br />
<br />
=== DataCue and "Time marches on" in HTML ===<br />
* Proposers: [[User:chrisn|Chris Needham]] ([[User talk:chrisn|talk]]) 11:45, 22 August 2019 (UTC)<br />
* Email address of proposers: chris.needham@bbc.co.uk<br />
* Summary: The DataCue API for media-synchronised metadata and interactivity events is part of HTML5, but not implemented across all browsers, and existing implementations vary. There are also issues with the ''time marches on'' algorithm in HTML for triggering timed interactivity events<br />
* Type of session: talk and open discussion<br />
* Goals: To advance the DataCue API design between media experts and browser developers, and discuss how to improve synchronisation of media and associated content on the web<br />
* Shortname: #datacue<br />
* Timing constraint: Please avoid overlap with the Next Generation TextTrackCue breakout, as it's largely the same participants<br />
* Estimated room capacity: medium room<br />
<br />
=== Portals (status and next steps) ===<br />
* Proposer: [[User:Jbroman|Jeremy Roman]] ([[User talk:Jbroman|talk]]) 18:44, 22 August 2019 (UTC)<br />
* Email address of proposer: jbroman@google.com<br />
* Summary: Discuss Portals and next steps for a WG or CG. Portals allow for seamless navigation between different documents, same and cross origin, embedded or not. See hands-on article and WICG repository.<br />
* Type of session: short talk (possibly a few demos) followed by discussion<br />
* Goals: Ensure everyone is up to date on the latest proposed API, implementation status, use cases and interest from developers; determine what are the next steps, and concerns if any; discuss advanced API topics or use cases.<br />
* Shortname: portals<br />
* Estimated room capacity: medium room<br />
<br />
=== Ad Measurement and Privacy ===<br />
* Proposer: [[User:johnwilander|John Wilander]]<br />
* Email address of proposer: wilander@apple.com<br />
* Summary: We will discuss Apple's proposed and implemented [https://wicg.github.io/ad-click-attribution/index.html Private Click Measurement] and Google's proposed [https://github.com/csharrison/conversion-measurement-api Click Through Conversion Measurement].<br />
* Type of session: Open discussion <br />
* Goals: Discuss the open issue of fraud detection and what is required to ship this feature.<br />
* Estimated room capacity: Medium room<br />
<br />
=== Input for workers/worklets ===<br />
* Proposer: [[User:Nzolghadr|Navid Zolghadr]] ([[User talk:Nzolghadr|talk]]) 14:16, 26 August 2019 (UTC)<br />
* Email address of proposer: nzolghadr@chromium.org, majidvp@chromium.org<br />
* Summary: Towards exposing [https://wicg.github.io/input-for-workers input events to Workers and Worklets].<br />
* Type of session: Open discussion<br />
* Goals: Discuss use cases and implications, brainstorm the API<br />
* shortname: workerinput<br />
* Additional speakers/panelists: Majid Valipour<br />
* Estimated room capacity: medium<br />
<br />
=== Privacy Budget ===<br />
* Proposer [[User:Blassey|Brad Lassey]]<br />
* Email address of the proposer: lassey@google.com<br />
* Summary: Chrome proposed a [https://github.com/bslassey/privacy-budget "privacy budget"] to limit the ability for websites to fingerprint users. We's like to have a discussion around this proposal and its implications.<br />
* Type of session: Open discussion<br />
* Goals: Determine interest level from implementers, discuss concerns.<br />
* Shortname: privacybudget<br />
* Estimated room capacity: medium<br />
* Interested:<br />
<br />
=== Trust Tokens ===<br />
* Proposer: [[User:blassey|Brad Lassey]]<br />
* Email address of the proposer: lassey@google.com<br />
* Summary: Cloudflare proposed the concept of the [https://privacypass.github.io/ Privacy Pass protocol] to avoid repeatedly showing captchas to Tor users and Chrome expanded on the idea to propose a more general purpose [https://github.com/dvorak42/trust-token-api Trust Token API] for conveying user trust between parties in order to prevent fraud.<br />
* Type of session: Open discussion<br />
* Goals: Determine interest level from implementers, discuss concerns.<br />
* Shortname: trusttokens<br />
* Additional speakers/panelists: [[User:Kleber|Michael Kleber]]<br />
* Estimated room capacity: medium<br />
* Interested:<br />
<br />
=== OpenJS Foundation Collaboration ===<br />
* Proposer: [[User:Jburson|Jordana Burson]] ([[User talk:Jburson|talk]]) 14:28, 28 August 2019 (UTC)<br />
* Email address of proposer: jory@bocoup.com<br />
* Summary (one-sentence or so): Members of the OpenJS Foundation cross project council would like to propose a 'BoF' conversation about how to build and strengthen healthy collaborations between foundation projects and W3C groups.<br />
* Type of session: open discussion<br />
* Goals:<br />
* [optional] shortname (used for minting an IRC channel for the breakout)<br />
* [optional] Additional speakers/panelists: Myles Borins, Christian Bromann, Brian Kardell<br />
* [optional] Timing constraint: (e.g. you expect to invite someone in a different time zone): none<br />
* [optional] Estimated room capacity: {big | medium | small} room: small<br />
<br />
=== Supporting privacy-focused ads selection ===<br />
* Proposer: [[User:Kleber|Michael Kleber]] ([[User talk:Kleber|talk]]) 00:40, 29 August 2019 (UTC)<br />
* Email address of the proposer: kleber@google.com<br />
* Summary: Discussion of various ideas for how browsers could support ad selection use cases which today rely on users having a consistent cross-site identity. Chrome has explainers out for [https://github.com/jkarlin/floc "Federated Learning of Cohorts" (FLoC)] and [https://github.com/michaelkleber/pigin "Private Interest Groups, Including Noise (PIGIN)"].<br />
* Type of session: Open discussion<br />
* Goals: Determine interest level from implementers, discuss concerns.<br />
* Shortname: adselection<br />
* Estimated room capacity: medium<br />
* Interested:<br />
<br />
=== XR Accessibility ===<br />
* Proposer: [[User:Joconnor|Joshue O Connor]] ([[User talk:Joconnor|talk]]) 14:11, 29 August 2019 (UTC)Joshue O Connor<br />
* Email address: joconnor@w3.org<br />
* Summary: Explore how to grow a broader accessibility community in the areas of XR (Virtual and Augmented Reality).<br />
* Type of session: Talk and Open Discussion <br />
* Goals: Figure out how to bring together the accessibility community to build capability, collaboration and community engagement in developing standards that address the challenges of making Virtual and Augmented Reality accessible. <br />
* Shortname: xra11y<br />
* Additional speakers/panelists: TBD<br />
* Estimated room capacity: medium room<br />
<br />
=== Standardizing user activation behavior ===<br />
* Proposer: [[User:Mustaq|Mustaq Ahmed]] ([[User talk:Mustaq|talk]]) 14:15, 29 August 2019 (UTC)<br />
* Email address of proposer: mustaq@google.com<br />
* Summary: We are proposing to replace the user activation model implied by the current HTML spec with a simple-to-implement model because the current model doesn't reflect the reality (https://github.com/whatwg/html/issues/1903).<br />
* Type of session: Open discussion<br />
* Goals: Trying to reach consensus on our proposed change to the spec (https://github.com/whatwg/html/pull/3851).<br />
* shortname: user-activation<br />
* Additional speakers/panelists: Domenic Denicola<br />
* Estimated room capacity: medium<br />
<br />
=== WebCodecs ===<br />
* Proposer: [[User:Pthatcher|Peter Thatcher]] ([[User talk:Pthatcher|talk]]) 01:04, 30 August 2019 (UTC) <br />
* Email address of proposer: pthatcher@google.com<br />
* Summary: Discuss WebCodecs (https://discourse.wicg.io/t/webcodecs-proposal/3662)<br />
* Type of session: short talk (maybe demo too) & discussion<br />
* Goals: Get input from potential users of the API to see what use cases we need to make sure are well supported, as well as from experts of codecs. <br />
* Shortname: webcodecs<br />
* Estimated room capacity: small room<br />
<br />
=== Bullet Chatting ===<br />
* Proposer: [[User:Song Xu|Song Xu]] ([[User talk:Song Xu|talk]]) <br />
* Email address of proposer: xusong@migu.cn<br />
* Summary: Introduce what is the Bullet Chatting , and introduce the Bullet Chatting specification drafted by W3C Chinese Interest Group. Discuss the way forward for Bullet Chatting standardization in W3C.<br />
* Type of session: talk & discussion<br />
* Goals: Help the global web community to better understand Bullet Chatting and the value of its standardization, and looking for teams interested in Bullet Chatting standardization, hoping to get some feedback and support, and get advice about what the W3C workflow. <br />
* Shortname: bulletchat<br />
* Estimated room capacity: small room<br />
<br />
=== Efficient audio/video processing ===<br />
* Proposer: François Daoust / Dominique HazaÍl-Massieux / 02 September 2019<br />
* Email address of proposer: fd@w3.org, dom@w3.org<br />
* Summary: W3C groups (e.g. WebRTC WG, Machine Learning for the Web CG, Audio WG, Media WG, Immersive Web WG) discuss, develop and/or dream about ways to process audio/video streams efficiently. Use cases include barcode reading, face/gesture tracking, emotion analysis, funny hats, background removal or blurring, augmented reality, video overlays, voice effects, or custom codecs. Would it be useful and possible to develop a common mechanism that different APIs could leverage to hook together with streams of media while avoiding useless memory copies? What could such a mechanism look like?<br />
* Type of session: open discussion<br />
* Goals: Look at use cases and at how they can be implemented today, assess possible performance gains if they were implemented with a more efficient mechanism, refine scope for possible work on the topic, and gauge interest among parties.<br />
* Additional speakers/panelists: Rijubrata Bhaumik, Paul Adenot, Peter Thatcher, Joshue O Connor<br />
* Shortname: mediaprocessing<br />
* Estimated room capacity: medium<br />
<br />
=== HTML 3D Element ===<br />
* Proposer: [[User:zyu5|Zhiqiang Yu]] <br />
* Email address: yuzhiqiang5@huawei.com<br />
* Summary: A proposal on HTML 3D element, to bring rich 3D & AR experience to Web with a single line of code. Use cases include on-line shopping, creative advertisement,education, etc. A few demos will be shown as well.<br />
* Type of session: short talk & discussion<br />
* Goals: promote the HTML 3D tag and looking forward to a wider collaboration w/ the community, as well as standardization in W3C.<br />
* shortname: HTML 3D<br />
* Estimated room capacity: medium room<br />
<br />
=== Native GLTF ===<br />
* Proposer: [[User:sushraja| Sushanth Rajasankar]]<br />
* Email address: sushraja@microsoft.com<br />
* Summary: Discuss a proposal for a scene element https://github.com/immersive-web/proposals/issues/52. That allows for native 3d content presentation. Demo Prototype. (Perhaps this can be a part of the previous session "HTML 3D Element").<br />
* Type of session: short talk & discussion<br />
* Goals: Gauge developer interest in adding native support for gltf in the browser and engage with the community.<br />
* ShortName: Native GLTF<br />
* Estimated room capacity: medium room.<br />
<br />
=== Voice assistants - opportunities for standardization? ===<br />
* Proposer: [[User:Philarcher|Phil Archer, GS1]] ([[User talk:Philarcher|talk]]) 09:28, 3 September 2019 (UTC)<br />
* Email address of proposer: phil.archer@gs1.org<br />
* Summary (one-sentence or so): Voice assistants present exciting new methods to interact with the Web but how can/should we develop standards that benefit all stake holders from start ups to tech giants? <br />
* Type of session: Discussion<br />
* Goals: To identify parties most interested in the generic area of voice interaction and to narrow that down to a set of more specific areas of interest. E-commerce? Fact checking? Media streaming? APIs for Skills, More ...<br />
* [optional] shortname: voice<br />
* [optional] Additional speakers/panelists: LĂŠonie Watson, Mark Hakkinen<br />
* [optional] Estimated room capacity: small room<br />
<br />
=== Github tools and Bots to assist Chairing ===<br />
* Proposer: [[User:Adaroseedwards|Ada Rose Cannon]] ([[User talk:Adaroseedwards|talk]]) 10:19, 3 September 2019 (UTC)<br />
* Email address of proposer: ada@ada.is <br />
* Summary: I'm a lazy chair and have created bots and scripts to help me chair, this is to show some of the tools I use to help leverage Github's APIs to help chair. I would also be interested in other tools people use to automate some of their teams.<br />
* Type of session: Presentation + Discussion<br />
* Goals: Share tools used.<br />
* [optional] shortname: groupautomation<br />
* [optional] Estimated room capacity: small room<br />
<br />
=== WebAuthn network transport discussion ===<br />
* Proposer(s): James Barclay, [[User:Nmooney|Nick Mooney]] ([[User talk:Nmooney|talk]]) 17:02, 3 September 2019 (UTC)<br />
* Emails: {jbarclay,nmooney}@duosecurity.com<br />
* Summary: Discuss the development of a new network-based transport as an addition to the WebAuthn specification.<br />
* Type: talk, open discussion<br />
* Goals: motivate the need for a network-based WebAuthn transport, discuss how this might look as part of the specification, discuss phishing resistance and proximity<br />
* Shortname: #webauthnnetwork<br />
* Estimated room capacity: medium<br />
<br />
=== Q&A about DIDs (Decentralized Identifiers) ===<br />
* Proposer: [[User:Drummondreed|Drummond Reed]] ([[User talk:Drummondreed|talk]]) 17:53, 3 September 2019 (UTC)<br />
* Email address of proposer: drummond.reed@evernym.com<br />
* Summary (one-sentence or so): DIDs are a new form of cryptographically-verifiable identifier, and TPAC will host the first meeting of the (still not final) W3C DID WG. This is a chance to learn more about DIDs.<br />
* Type of session: open discussion<br />
* Goals: The primary goal is to answer questions about DIDs and help W3C members understand the market interest in this new type of identifier.<br />
* Shortname: #did<br />
* Additional speakers/panelists: Manu Sporny, Dan Burnett, Christopher Allen<br />
* Estimated room capacity: medium room<br />
<br />
=== UndoManager API ===<br />
* Proposer: [[User:Whsieh|Wenson Hsieh]] ([[User talk:Whsieh|talk]]) 20:28, 3 September 2019 (UTC)<br />
* Email address of proposer: wenson_hsieh@apple.com<br />
* Summary (one-sentence or so): The UndoManager API allows web applications to modify the platform undo stack, and scope undo stacks to elements.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): talk, open discussion<br />
* Goals: Introduce a proposal for the UndoManager API, which allows web applications to modify and inspect the platformâs undo stack. This has implications for all types of web apps, with particular relevance to editing and productivity apps. We hope to establish context for the UndoManager API, demo a prototype of the API, and gain feedback for our proposal.<br />
* Shortname: undomanager<br />
* Additional speakers/panelists: Megan Gardner<br />
* Estimated room capacity: small room<br />
<br />
=== Linked Data Security ===<br />
* Proposer: [[User:Msporny|Manu Sporny]] ([[User talk:Msporny|talk]]) 22:11, 3 September 2019 (UTC)<br />
* Email address of proposer: msporny@digitalbazaar.com<br />
* Summary (one-sentence or so): Should we standardize: RDF Dataset Canonicalization, Linked Data Proofs, Linked Data Signatures, RSA2019Signature, Ed25519Signature, and if so, on what timeline?<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): open discussion<br />
* Goals: Determine if certain Linked Data Security technologies are ready for standardization.<br />
* [optional] ldsec<br />
* [optional] Additional speakers/panelists: Ivan Herman, Gregg Kellogg, Benjamin Young, Robert Sanderson<br />
* [optional] Timing constraint: Don't overlap with DID session<br />
* [optional] Estimated room capacity: small<br />
<br />
=== What is the Future of W3C ===<br />
* Proposer: [[Tantek]] (Mozilla) ([[User:Tantekelik|Tantek Ăelik]] ([[User talk:Tantekelik|talk]]) 22:58, 3 September 2019 (UTC))<br />
* Email address of proposer: tantek@cs.stanford.edu<br />
* Summary: How should W3C evolve to better serve the web community? The AB and AC are discussing changes to its structure, but they need to hear from stakeholders about the mission and the structure designed to achieve it.<br />
* Type of session: open discussion<br />
* shortname: #future<br />
* Timing constraint: prefer Pacific Time Zone friendly time if possible for remote participation<br />
* Estimated room capacity: medium<br />
* Additional speakers/panelists: Michael Champion (Microsoft, possibly remote), Chris Wilson (Google)<br />
* Goals: A discussion to understand the community's level of consensus on fundamental questions:<br />
** Mission â W3Câs traditional mission statement is âlead the web to its full potentialâ. Does the community believe W3Câs basic value proposition need updating, perhaps to focus on some combination of documenting how the web actually works, certifying which products comply with the consensus standards, and focusing on the most pressing challenges to the original vision?<br />
** Leadership â The founding Director is no longer involved with W3Câs day to day operations, but the âDirectorâ has a key role in the process and governance. Would the community be more comfortable with finding another neutral person with considerable expertise who can commit the time to being Director, or delegating tasks such as adjudicating formal objections to some sort of elected council?<br />
** Staffing â What role or roles should the Team prioritize and focus on? Mechanics of consensus building, or technical guidance on solutions?<br />
* Interested:<br />
** [[User:Coralie|Coralie Mercier]] ([[User talk:Coralie|talk]]) 17:31, 4 September 2019 (UTC)<br />
** ...<br />
<br />
=== Web of Things PlugFest ===<br />
* Proposer: [[User:Ashimura|Kazuyuki Ashimura]] ([[User talk:Ashimura|talk]]) 17:21, 4 September 2019 (UTC)<br />
* Email address of proposer: ashimura@w3.org<br />
* Summary: The WoT-IG/WG would like to have its PlugFest demo at 13:30-14:30 to (1) present what kind of demos are included and (2) show actual demos which include various scenarios and combinations of devices/applications for IoT purposes.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Presentaton and Demo<br />
* Goals: Show what is done by the WoT WG/IG based on the WoT standards to all the TPAC attendees and encourage people to collaborate with the group (and join the group :). This time we'd like to show several different combinations of devices/applications and scenarios based on the WoT specifications. Please see also the [https://github.com/endouhhc/wot/blob/master/plugfest/2019-tpac-fukuoka/README.md PlugFest preparation page].<br />
* shortname: wot-pf<br />
* Timing constraint: 13:30-14:30<br />
* Estimated room capacity: big room<br />
<br />
=== Introduction to W3C ===<br />
* Proposer: [[User:Plehegar|Philippe Le HĂŠgaret]] ([[User talk:Plehegar|talk]]) 20:12, 4 September 2019 (UTC)<br />
* Email address of proposer: plh@w3.org<br />
* Summary: If you're a new Group participant in the W3C, this session will guide you through the W3C labyrinth and allow you to contribute to the Web<br />
* Type of session: talk, tutorial, open discussion<br />
* Goals: Make sure attendees are up-to-speed on how to participate in their Groups, get familiar with various documentations and tools used by W3C, including GitHub.<br />
* shortname: #w3c-intro<br />
* Timing constraint: none<br />
* Estimated room capacity: small room</div>Plehegarhttps://www.w3.org/wiki/index.php?title=TPAC/2019/SessionIdeas&diff=110077TPAC/2019/SessionIdeas2019-09-04T20:20:40Z<p>Plehegar: /* Introduction to W3C */</p>
<hr />
<div>We encourage attendees to start brainstorming [[TPAC/2019]] Wednesday 18 September 2019 '''Technical Plenary Day''' Breakout sessions in advance of the meeting and until '''Tuesday 17 September 5 pm local time'''. <br />
<br />
See the [[TPAC/2019/FAQ | TPAC 2019 FAQ]] for more information. <br />
<br />
== How to use this page ==<br />
<br />
Please use this page to:<br />
<br />
* Propose sessions you wish you lead<br />
* Propose sessions you wish others to lead (it's a good idea to let them know ahead of time)<br />
* Indicate whether you plan to attend a session (helps with scheduling)<br />
* '''Please place new proposal at the bottom of this document'''<br />
<br />
== How to propose a session ==<br />
<br />
Please provide:<br />
<ul class="show_items"><br />
* session name (as a === subhead === )<br />
* session proposer (yourself, if so sign using 4 tildas; optional: name a desired session leader) and an email address<br />
* one sentence session summary<br />
* type of session: (e.g.: open discussion, talk, panel, etc.)<br />
* goals of session<br />
* additional speakers/panelists (to help reduce conflicts when one person is needed in more than one place)<br />
* any timing constraint you already know (e.g. you expect to invite someone in a different time zone)<br />
* if you can guess, whether you'll need a {big | medium | small} room (we can't guarantee you'll get it, however)<br />
* add an "Interested" bullet for people to sign up for sessions<br />
</ul><br />
<br />
== From an idea to a breakout ==<br />
<br />
<span style="color:#ff0000">'''The goal is to have a near-final breakout sessions schedule by the night before the plenary day (i.e. on Tuesday September 17 night), with only a few changes needed on the plenary day itself during the finalization phase at 09:45-10:30.</span><br />
<br />
This ensures a more inclusive process in how the breakout sessions are defined and scheduled (thus avoiding any mad scramble). An HTML and mobile-friendly filled-out session grid for the dayâs breakout sessions will be generated by the Team. [[TPAC/2019/FAQ#How_does_the_agenda_get_built.3F|Read more in our FAQ]].<br />
<br />
== Proposed sessions ==<br />
<br />
=== EXAMPLE session with session name ===<br />
* Proposer: <nowiki>~~~~</nowiki> (Instruction: remove <nowiki><nowiki> and </nowiki></nowiki> around the tildas. Explanation: The 4 tildas will sign YOUR name and include a timestamp of your proposal.)<br />
* Email address of proposer: <br />
* Summary (one-sentence or so): <br />
* Type of session (e.g.: open discussion, talk, panel, etc.): <br />
* Goals:<br />
* [optional] shortname (used for minting an IRC channel for the breakout)<br />
* [optional] Additional speakers/panelists:<br />
* [optional] Timing constraint: (e.g. you expect to invite someone in a different time zone)<br />
* [optional] Estimated room capacity: {big | medium | small} room<br />
<br />
=== ReSpec - so many new features! ===<br />
* Proposer: Marcos CĂĄceres<br />
* Email address of proposer: mcaceres@mozilla.com <br />
* Summary (one-sentence or so): Covering all the exciting advancements we've made in the last year, including automatic cross references, smart citations, MDN integration, and more! <br />
* Type of session: talk and open discussion <br />
* Goals: Introduce Editors to new features. <br />
* shortname: #pub<br />
* Additional speakers/panelists: Sid Vishnoi, Kagami Sascha Rosylight <br />
* [optional] Estimated room capacity: medium room<br />
<br />
=== Japan Language Requirements Task Force: Evolving the JLReq document ===<br />
* Proposer: [[User:Nmccully|Nathaniel McCully]] ([[User talk:Nmccully|talk]]) 16:29, 2 August 2019 (UTC)<br />
* Email address: nmccully@adobe.com<br />
* Summary: Explanation of the JLReq v2 effort currently underway, and a glimpse into the roadmap of a v3, that seeks to serve the needs of developers of layout engines for modern, dynamic media that support high-quality Japanese layout<br />
* Type of session: talk<br />
* Goals: To inform that this is happening, and get more people interested in the issues of high-end Japanese typography and layout in the context of responsive modern digital media.<br />
<br />
=== Results from MDN Developer Survey ===<br />
* Proposer: [[User:Dom|Dominique HazaĂŤl-Massieux]] ([[User talk:Dom|talk]]) 06:52, 5 August 2019 (UTC)<br />
* Email address: dom@w3.org<br />
* Summary: Meet the MDN Product Advisory Board and discuss how the results of the [https://hacks.mozilla.org/2019/07/mdn-web-developer-designer-survey/ MDN Developer Survey] can impact W3C's agenda<br />
* Type of session: short talk & discussion<br />
* Goals: Bring input to the MDN Product Advisory Board to see how MDN documentation can evolve to better meet the need from the W3C community; learn about the MDN Developer Survey and discuss what conclusions to draw from its results in terms of the W3C standardization agenda<br />
* Additional speakers/panelists: Kadir Topal, Dan Appelquist, Jory Burson, Travis Leithead, Joe Medley<br />
* shortname: mdn<br />
* Estimated room capacity: medium room<br />
<br />
=== Mini App Standardization ===<br />
* Proposer: [[User:laq|Angel Li]] 10:14, 14 August 2019 (UTC)<br />
* Email address: angelli.laq@alibaba-inc.com<br />
* Summary: Meet the major Mini App players, introduction of Mini App white paper drafted by W3C Chinese IG, discuss the way forward for Mini App Standardization in W3C<br />
* Type of session: short talk & discussion<br />
* Goals: help the global web community to better understand Mini App and the value of its standardization, find proper way to move forward in W3C<br />
* shortname: MiniApp<br />
* Estimated room capacity: medium room<br />
* Interested: [[User:Chris|Chris Lilley]] ([[User talk:Chris|talk]]) 13:54, 27 August 2019 (UTC)<br />
<br />
=== Web Packaging ===<br />
(Including Signed Exchanges and Bundles.)<br />
* Proposer: [[User:Jyasskin|Jeffrey Yasskin]] ([[User talk:Jyasskin|talk]]) 18:41, 14 August 2019 (UTC)<br />
* Email address of proposer: jyasskin@google.com<br />
* Summary (one-sentence or so): Discuss W3C feelings about the [Web Packaging proposal](https://github.com/WICG/webpackage).<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Short talk & discussion<br />
* Goals: Ensure everyone knows the state of the IETF discussion and the Chromium implementation; recruit collaborators; discover concerns and needed changes; get advice about what route through the W3C/WHATWG processes to follow.<br />
* [optional] shortname: wpack<br />
* [optional] Additional speakers/panelists: [[User:Kyasuda2|Kinuko Yasuda]]<br />
* [optional] Timing constraint: TBD<br />
* [optional] Estimated room capacity: medium room<br />
<br />
=== A target privacy threat model for the Web ===<br />
* Proposer: [[User:Jyasskin|Jeffrey Yasskin]] ([[User talk:Jyasskin|talk]]) 19:04, 14 August 2019 (UTC) (However, I'd love to have someone else lead this.)<br />
* Email address of proposer: jyasskin@google.com<br />
* Summary (one-sentence or so): Proposals for new features often encounter resistance from folks who want the Web Platform to defend its users' privacy better than it does today. This often surprises the authors of those proposals, who were designing against the Web's current, implicit, and weak privacy threat model. Making our privacy goals explicit could avoid those surprises and reduce the load on privacy reviewers.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Open discussion<br />
* Goals: Figure out whether there's interest in developing a target privacy threat model for the Web.<br />
* shortname: privthreatmodel<br />
* Additional speakers/panelists: [Your name here]<br />
* Timing constraint: <br />
: morning session would be preferable for East Coast remote attendees -- [[User:Npdoty|Nick Doty]] ([[User talk:Npdoty|talk]])<br />
* Estimated room capacity: large room --- with polycom to support remote attendees<br />
<br />
=== Next Generation TextTrackCue ===<br />
* Proposers: [[User:Ecarlson2|Eric Carlson]] ([[User talk:Ecarlson2|talk]]) 20:18, 15 August 2019 (UTC), [[User:Eoconnor|Theresa O'Connor]], [[User:PLemieux|Pierre-Anthony Lemieux]]<br />
* Email address of proposers: eric.carlson@apple.com,hober@apple.com,pal@sandflow.com<br />
* Summary: TextTrackCue enhancements for programmatic subtitle and caption presentation. We've been making progress since FOMS this past spring. Please see our FOMS slides for the basic idea: https://www.icloud.com/keynote/0GJUbJwWfA2i77M2JysKjj45w#Generic_Text_Cue_-_FOMS_2019<br />
* Type of session: talk and open discussion<br />
* Goals: Engage with browser engineers and media experts & gauge interest in pursuing this as new web API<br />
* shortname: textcueapi<br />
* Estimated room capacity: medium room (~20 people)<br />
<br />
=== JS Built-In Modules ===<br />
* Proposer: [[User:dcrousso|Devin Rousso]] ([[User talk:dcrousso|talk]]) 22:05, 15 August 2019 (UTC)<br />
* Email address of proposer: dcrousso@apple.com<br />
* Summary (one-sentence or so): introduction to the concept of JS Built-In Modules, as well as an overview of the currently proposed governance model<br />
* Type of session: talk<br />
* Goals: disseminate knowledge of JS Built-In modules to other hosts built on top of JavaScript (e.g. web browsers), and introduce the proposed governance model to potential stakeholders of additional JS Built-In Module namespaces (e.g. web:)<br />
* Additional speakers: Michael Saboff <msaboff@apple.com> (call-in TC39 proposal champion)<br />
* Timing constraint: friendly towards PST<br />
* Estimated room capacity: medium room<br />
<br />
=== WebTransport status and next steps ===<br />
* Proposer: Peter Thatcher<br />
* Email address of proposer: pthatcher@google.com<br />
* Summary (one-sentence or so): Discuss [https://github.com/WICG/web-transport WebTransport API] and next steps for a WG or CG<br />
* Type of session: short talk (maybe demo too) & discussion<br />
* Goals: Ensure everyone is up to date on the latest API, implementation status, and interaction with the IETF ([https://mailarchive.ietf.org/arch/browse/webtransport/ link to mailing list]; [https://tools.ietf.org/wg/dispatch/minutes link to DISPATCH minutes]); determine when and how we should create a WG or CG; discuss advanced API topics such as how best to use WHATWG streams, how to handle congestion control, and stream prioritization<br />
* Shortname: webtransport<br />
* Estimated room capacity: medium room<br />
<br />
=== Web stories ===<br />
* Proposer: [[User:Coralie|Coralie Mercier]] ([[User talk:Coralie|talk]]) 15:45, 20 August 2019 (UTC)<br />
* Email address of proposer: coralie@w3.org<br />
* Summary: Feedback and brainstorming for (re)introducing the Web Consortium to the public. The W3C Comm team wants to get background stories from our Members and community about how they were drawn to the Web (before the Web, or their first involvement with the Web). There is a path for how everyone in our community has come to the Web, what they see happening now and what they see in the future.<br />
* Type of session: open discussion<br />
* Goals: We want to gather stories in order to tell a compelling story to the public. W3C Comm team may use this as part of an upcoming crowdfunding campaign.<br />
* shortname: webstories<br />
* Estimated room capacity: medium room<br />
* Interested:<br />
** ...<br />
<br />
=== WebGPU ===<br />
* Proposer: Myles C. Maxfield<br />
* Email address of proposer: mmaxfield@apple.com<br />
* Summary (one-sentence or so): Update on the progress of WebGPU, and group discussion about future directions and what to focus on<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Talk and open discussion<br />
* Goals: Help people understand the direction that WebGPU is going, and get feedback from the broader community<br />
* [optional] shortname (used for minting an IRC channel for the breakout): webgpu<br />
* [optional] Additional speakers/panelists: Dean Jackson, anyone else in the CG<br />
* [optional] Estimated room capacity: medium room?<br />
<br />
=== DataCue and "Time marches on" in HTML ===<br />
* Proposers: [[User:chrisn|Chris Needham]] ([[User talk:chrisn|talk]]) 11:45, 22 August 2019 (UTC)<br />
* Email address of proposers: chris.needham@bbc.co.uk<br />
* Summary: The DataCue API for media-synchronised metadata and interactivity events is part of HTML5, but not implemented across all browsers, and existing implementations vary. There are also issues with the ''time marches on'' algorithm in HTML for triggering timed interactivity events<br />
* Type of session: talk and open discussion<br />
* Goals: To advance the DataCue API design between media experts and browser developers, and discuss how to improve synchronisation of media and associated content on the web<br />
* Shortname: #datacue<br />
* Timing constraint: Please avoid overlap with the Next Generation TextTrackCue breakout, as it's largely the same participants<br />
* Estimated room capacity: medium room<br />
<br />
=== Portals (status and next steps) ===<br />
* Proposer: [[User:Jbroman|Jeremy Roman]] ([[User talk:Jbroman|talk]]) 18:44, 22 August 2019 (UTC)<br />
* Email address of proposer: jbroman@google.com<br />
* Summary: Discuss Portals and next steps for a WG or CG. Portals allow for seamless navigation between different documents, same and cross origin, embedded or not. See hands-on article and WICG repository.<br />
* Type of session: short talk (possibly a few demos) followed by discussion<br />
* Goals: Ensure everyone is up to date on the latest proposed API, implementation status, use cases and interest from developers; determine what are the next steps, and concerns if any; discuss advanced API topics or use cases.<br />
* Shortname: portals<br />
* Estimated room capacity: medium room<br />
<br />
=== Ad Measurement and Privacy ===<br />
* Proposer: [[User:johnwilander|John Wilander]]<br />
* Email address of proposer: wilander@apple.com<br />
* Summary: We will discuss Apple's proposed and implemented [https://wicg.github.io/ad-click-attribution/index.html Private Click Measurement] and Google's proposed [https://github.com/csharrison/conversion-measurement-api Click Through Conversion Measurement].<br />
* Type of session: Open discussion <br />
* Goals: Discuss the open issue of fraud detection and what is required to ship this feature.<br />
* Estimated room capacity: Medium room<br />
<br />
=== Input for workers/worklets ===<br />
* Proposer: [[User:Nzolghadr|Navid Zolghadr]] ([[User talk:Nzolghadr|talk]]) 14:16, 26 August 2019 (UTC)<br />
* Email address of proposer: nzolghadr@chromium.org, majidvp@chromium.org<br />
* Summary: Towards exposing [https://wicg.github.io/input-for-workers input events to Workers and Worklets].<br />
* Type of session: Open discussion<br />
* Goals: Discuss use cases and implications, brainstorm the API<br />
* shortname: workerinput<br />
* Additional speakers/panelists: Majid Valipour<br />
* Estimated room capacity: medium<br />
<br />
=== Privacy Budget ===<br />
* Proposer [[User:Blassey|Brad Lassey]]<br />
* Email address of the proposer: lassey@google.com<br />
* Summary: Chrome proposed a [https://github.com/bslassey/privacy-budget "privacy budget"] to limit the ability for websites to fingerprint users. We's like to have a discussion around this proposal and its implications.<br />
* Type of session: Open discussion<br />
* Goals: Determine interest level from implementers, discuss concerns.<br />
* Shortname: privacybudget<br />
* Estimated room capacity: medium<br />
* Interested:<br />
<br />
=== Trust Tokens ===<br />
* Proposer: [[User:blassey|Brad Lassey]]<br />
* Email address of the proposer: lassey@google.com<br />
* Summary: Cloudflare proposed the concept of the [https://privacypass.github.io/ Privacy Pass protocol] to avoid repeatedly showing captchas to Tor users and Chrome expanded on the idea to propose a more general purpose [https://github.com/dvorak42/trust-token-api Trust Token API] for conveying user trust between parties in order to prevent fraud.<br />
* Type of session: Open discussion<br />
* Goals: Determine interest level from implementers, discuss concerns.<br />
* Shortname: trusttokens<br />
* Additional speakers/panelists: [[User:Kleber|Michael Kleber]]<br />
* Estimated room capacity: medium<br />
* Interested:<br />
<br />
=== OpenJS Foundation Collaboration ===<br />
* Proposer: [[User:Jburson|Jordana Burson]] ([[User talk:Jburson|talk]]) 14:28, 28 August 2019 (UTC)<br />
* Email address of proposer: jory@bocoup.com<br />
* Summary (one-sentence or so): Members of the OpenJS Foundation cross project council would like to propose a 'BoF' conversation about how to build and strengthen healthy collaborations between foundation projects and W3C groups.<br />
* Type of session: open discussion<br />
* Goals:<br />
* [optional] shortname (used for minting an IRC channel for the breakout)<br />
* [optional] Additional speakers/panelists: Myles Borins, Christian Bromann, Brian Kardell<br />
* [optional] Timing constraint: (e.g. you expect to invite someone in a different time zone): none<br />
* [optional] Estimated room capacity: {big | medium | small} room: small<br />
<br />
=== Supporting privacy-focused ads selection ===<br />
* Proposer: [[User:Kleber|Michael Kleber]] ([[User talk:Kleber|talk]]) 00:40, 29 August 2019 (UTC)<br />
* Email address of the proposer: kleber@google.com<br />
* Summary: Discussion of various ideas for how browsers could support ad selection use cases which today rely on users having a consistent cross-site identity. Chrome has explainers out for [https://github.com/jkarlin/floc "Federated Learning of Cohorts" (FLoC)] and [https://github.com/michaelkleber/pigin "Private Interest Groups, Including Noise (PIGIN)"].<br />
* Type of session: Open discussion<br />
* Goals: Determine interest level from implementers, discuss concerns.<br />
* Shortname: adselection<br />
* Estimated room capacity: medium<br />
* Interested:<br />
<br />
=== XR Accessibility ===<br />
* Proposer: [[User:Joconnor|Joshue O Connor]] ([[User talk:Joconnor|talk]]) 14:11, 29 August 2019 (UTC)Joshue O Connor<br />
* Email address: joconnor@w3.org<br />
* Summary: Explore how to grow a broader accessibility community in the areas of XR (Virtual and Augmented Reality).<br />
* Type of session: Talk and Open Discussion <br />
* Goals: Figure out how to bring together the accessibility community to build capability, collaboration and community engagement in developing standards that address the challenges of making Virtual and Augmented Reality accessible. <br />
* Shortname: xra11y<br />
* Additional speakers/panelists: TBD<br />
* Estimated room capacity: medium room<br />
<br />
=== Standardizing user activation behavior ===<br />
* Proposer: [[User:Mustaq|Mustaq Ahmed]] ([[User talk:Mustaq|talk]]) 14:15, 29 August 2019 (UTC)<br />
* Email address of proposer: mustaq@google.com<br />
* Summary: We are proposing to replace the user activation model implied by the current HTML spec with a simple-to-implement model because the current model doesn't reflect the reality (https://github.com/whatwg/html/issues/1903).<br />
* Type of session: Open discussion<br />
* Goals: Trying to reach consensus on our proposed change to the spec (https://github.com/whatwg/html/pull/3851).<br />
* shortname: user-activation<br />
* Additional speakers/panelists: Domenic Denicola<br />
* Estimated room capacity: medium<br />
<br />
=== WebCodecs ===<br />
* Proposer: [[User:Pthatcher|Peter Thatcher]] ([[User talk:Pthatcher|talk]]) 01:04, 30 August 2019 (UTC) <br />
* Email address of proposer: pthatcher@google.com<br />
* Summary: Discuss WebCodecs (https://discourse.wicg.io/t/webcodecs-proposal/3662)<br />
* Type of session: short talk (maybe demo too) & discussion<br />
* Goals: Get input from potential users of the API to see what use cases we need to make sure are well supported, as well as from experts of codecs. <br />
* Shortname: webcodecs<br />
* Estimated room capacity: small room<br />
<br />
=== Bullet Chatting ===<br />
* Proposer: [[User:Song Xu|Song Xu]] ([[User talk:Song Xu|talk]]) <br />
* Email address of proposer: xusong@migu.cn<br />
* Summary: Introduce what is the Bullet Chatting , and introduce the Bullet Chatting specification drafted by W3C Chinese Interest Group. Discuss the way forward for Bullet Chatting standardization in W3C.<br />
* Type of session: talk & discussion<br />
* Goals: Help the global web community to better understand Bullet Chatting and the value of its standardization, and looking for teams interested in Bullet Chatting standardization, hoping to get some feedback and support, and get advice about what the W3C workflow. <br />
* Shortname: bulletchat<br />
* Estimated room capacity: small room<br />
<br />
=== Efficient audio/video processing ===<br />
* Proposer: François Daoust / Dominique HazaÍl-Massieux / 02 September 2019<br />
* Email address of proposer: fd@w3.org, dom@w3.org<br />
* Summary: W3C groups (e.g. WebRTC WG, Machine Learning for the Web CG, Audio WG, Media WG, Immersive Web WG) discuss, develop and/or dream about ways to process audio/video streams efficiently. Use cases include barcode reading, face/gesture tracking, emotion analysis, funny hats, background removal or blurring, augmented reality, video overlays, voice effects, or custom codecs. Would it be useful and possible to develop a common mechanism that different APIs could leverage to hook together with streams of media while avoiding useless memory copies? What could such a mechanism look like?<br />
* Type of session: open discussion<br />
* Goals: Look at use cases and at how they can be implemented today, assess possible performance gains if they were implemented with a more efficient mechanism, refine scope for possible work on the topic, and gauge interest among parties.<br />
* Additional speakers/panelists: Rijubrata Bhaumik, Paul Adenot, Peter Thatcher, Joshue O Connor<br />
* Shortname: mediaprocessing<br />
* Estimated room capacity: medium<br />
<br />
=== HTML 3D Element ===<br />
* Proposer: [[User:zyu5|Zhiqiang Yu]] <br />
* Email address: yuzhiqiang5@huawei.com<br />
* Summary: A proposal on HTML 3D element, to bring rich 3D & AR experience to Web with a single line of code. Use cases include on-line shopping, creative advertisement,education, etc. A few demos will be shown as well.<br />
* Type of session: short talk & discussion<br />
* Goals: promote the HTML 3D tag and looking forward to a wider collaboration w/ the community, as well as standardization in W3C.<br />
* shortname: HTML 3D<br />
* Estimated room capacity: medium room<br />
<br />
=== Native GLTF ===<br />
* Proposer: [[User:sushraja| Sushanth Rajasankar]]<br />
* Email address: sushraja@microsoft.com<br />
* Summary: Discuss a proposal for a scene element https://github.com/immersive-web/proposals/issues/52. That allows for native 3d content presentation. Demo Prototype. (Perhaps this can be a part of the previous session "HTML 3D Element").<br />
* Type of session: short talk & discussion<br />
* Goals: Gauge developer interest in adding native support for gltf in the browser and engage with the community.<br />
* ShortName: Native GLTF<br />
* Estimated room capacity: medium room.<br />
<br />
=== Voice assistants - opportunities for standardization? ===<br />
* Proposer: [[User:Philarcher|Phil Archer, GS1]] ([[User talk:Philarcher|talk]]) 09:28, 3 September 2019 (UTC)<br />
* Email address of proposer: phil.archer@gs1.org<br />
* Summary (one-sentence or so): Voice assistants present exciting new methods to interact with the Web but how can/should we develop standards that benefit all stake holders from start ups to tech giants? <br />
* Type of session: Discussion<br />
* Goals: To identify parties most interested in the generic area of voice interaction and to narrow that down to a set of more specific areas of interest. E-commerce? Fact checking? Media streaming? APIs for Skills, More ...<br />
* [optional] shortname: voice<br />
* [optional] Additional speakers/panelists: LĂŠonie Watson, Mark Hakkinen<br />
* [optional] Estimated room capacity: small room<br />
<br />
=== Github tools and Bots to assist Chairing ===<br />
* Proposer: [[User:Adaroseedwards|Ada Rose Cannon]] ([[User talk:Adaroseedwards|talk]]) 10:19, 3 September 2019 (UTC)<br />
* Email address of proposer: ada@ada.is <br />
* Summary: I'm a lazy chair and have created bots and scripts to help me chair, this is to show some of the tools I use to help leverage Github's APIs to help chair. I would also be interested in other tools people use to automate some of their teams.<br />
* Type of session: Presentation + Discussion<br />
* Goals: Share tools used.<br />
* [optional] shortname: groupautomation<br />
* [optional] Estimated room capacity: small room<br />
<br />
=== WebAuthn network transport discussion ===<br />
* Proposer(s): James Barclay, [[User:Nmooney|Nick Mooney]] ([[User talk:Nmooney|talk]]) 17:02, 3 September 2019 (UTC)<br />
* Emails: {jbarclay,nmooney}@duosecurity.com<br />
* Summary: Discuss the development of a new network-based transport as an addition to the WebAuthn specification.<br />
* Type: talk, open discussion<br />
* Goals: motivate the need for a network-based WebAuthn transport, discuss how this might look as part of the specification, discuss phishing resistance and proximity<br />
* Shortname: #webauthnnetwork<br />
* Estimated room capacity: medium<br />
<br />
=== Q&A about DIDs (Decentralized Identifiers) ===<br />
* Proposer: [[User:Drummondreed|Drummond Reed]] ([[User talk:Drummondreed|talk]]) 17:53, 3 September 2019 (UTC)<br />
* Email address of proposer: drummond.reed@evernym.com<br />
* Summary (one-sentence or so): DIDs are a new form of cryptographically-verifiable identifier, and TPAC will host the first meeting of the (still not final) W3C DID WG. This is a chance to learn more about DIDs.<br />
* Type of session: open discussion<br />
* Goals: The primary goal is to answer questions about DIDs and help W3C members understand the market interest in this new type of identifier.<br />
* Shortname: #did<br />
* Additional speakers/panelists: Manu Sporny, Dan Burnett, Christopher Allen<br />
* Estimated room capacity: medium room<br />
<br />
=== UndoManager API ===<br />
* Proposer: [[User:Whsieh|Wenson Hsieh]] ([[User talk:Whsieh|talk]]) 20:28, 3 September 2019 (UTC)<br />
* Email address of proposer: wenson_hsieh@apple.com<br />
* Summary (one-sentence or so): The UndoManager API allows web applications to modify the platform undo stack, and scope undo stacks to elements.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): talk, open discussion<br />
* Goals: Introduce a proposal for the UndoManager API, which allows web applications to modify and inspect the platformâs undo stack. This has implications for all types of web apps, with particular relevance to editing and productivity apps. We hope to establish context for the UndoManager API, demo a prototype of the API, and gain feedback for our proposal.<br />
* Shortname: undomanager<br />
* Additional speakers/panelists: Megan Gardner<br />
* Estimated room capacity: small room<br />
<br />
=== Linked Data Security ===<br />
* Proposer: [[User:Msporny|Manu Sporny]] ([[User talk:Msporny|talk]]) 22:11, 3 September 2019 (UTC)<br />
* Email address of proposer: msporny@digitalbazaar.com<br />
* Summary (one-sentence or so): Should we standardize: RDF Dataset Canonicalization, Linked Data Proofs, Linked Data Signatures, RSA2019Signature, Ed25519Signature, and if so, on what timeline?<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): open discussion<br />
* Goals: Determine if certain Linked Data Security technologies are ready for standardization.<br />
* [optional] ldsec<br />
* [optional] Additional speakers/panelists: Ivan Herman, Gregg Kellogg, Benjamin Young, Robert Sanderson<br />
* [optional] Timing constraint: Don't overlap with DID session<br />
* [optional] Estimated room capacity: small<br />
<br />
=== What is the Future of W3C ===<br />
* Proposer: [[Tantek]] (Mozilla) ([[User:Tantekelik|Tantek Ăelik]] ([[User talk:Tantekelik|talk]]) 22:58, 3 September 2019 (UTC))<br />
* Email address of proposer: tantek@cs.stanford.edu<br />
* Summary: How should W3C evolve to better serve the web community? The AB and AC are discussing changes to its structure, but they need to hear from stakeholders about the mission and the structure designed to achieve it.<br />
* Type of session: open discussion<br />
* shortname: #future<br />
* Timing constraint: prefer Pacific Time Zone friendly time if possible for remote participation<br />
* Estimated room capacity: medium<br />
* Additional speakers/panelists: Michael Champion (Microsoft, possibly remote), Chris Wilson (Google)<br />
* Goals: A discussion to understand the community's level of consensus on fundamental questions:<br />
** Mission â W3Câs traditional mission statement is âlead the web to its full potentialâ. Does the community believe W3Câs basic value proposition need updating, perhaps to focus on some combination of documenting how the web actually works, certifying which products comply with the consensus standards, and focusing on the most pressing challenges to the original vision?<br />
** Leadership â The founding Director is no longer involved with W3Câs day to day operations, but the âDirectorâ has a key role in the process and governance. Would the community be more comfortable with finding another neutral person with considerable expertise who can commit the time to being Director, or delegating tasks such as adjudicating formal objections to some sort of elected council?<br />
** Staffing â What role or roles should the Team prioritize and focus on? Mechanics of consensus building, or technical guidance on solutions?<br />
* Interested:<br />
** [[User:Coralie|Coralie Mercier]] ([[User talk:Coralie|talk]]) 17:31, 4 September 2019 (UTC)<br />
** ...<br />
<br />
=== Web of Things PlugFest ===<br />
* Proposer: [[User:Ashimura|Kazuyuki Ashimura]] ([[User talk:Ashimura|talk]]) 17:21, 4 September 2019 (UTC)<br />
* Email address of proposer: ashimura@w3.org<br />
* Summary: The WoT-IG/WG would like to have its PlugFest demo at 13:30-14:30 to (1) present what kind of demos are included and (2) show actual demos which include various scenarios and combinations of devices/applications for IoT purposes.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Presentaton and Demo<br />
* Goals: Show what is done by the WoT WG/IG based on the WoT standards to all the TPAC attendees and encourage people to collaborate with the group (and join the group :). This time we'd like to show several different combinations of devices/applications and scenarios based on the WoT specifications. Please see also the [https://github.com/endouhhc/wot/blob/master/plugfest/2019-tpac-fukuoka/README.md PlugFest preparation page].<br />
* shortname: wot-pf<br />
* Timing constraint: 13:30-14:30<br />
* Estimated room capacity: big room<br />
<br />
=== Introduction to W3C ===<br />
* Proposer: [[User:Plehegar|Philippe Le HĂŠgaret]] ([[User talk:Plehegar|talk]]) 20:12, 4 September 2019 (UTC)<br />
* Email address of proposer: plh@w3.org<br />
* Summary (one-sentence or so): If you're a new Group participant in the W3C, this session will guide you through the W3C labyrinth and allow you to contribute to the Web<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): talk, tutorial, open discussion<br />
* Goals: Make sure attendees are up-to-speed on how to participate in their Groups, get familiar with various documentations and tools used by W3C, including GitHub.<br />
* #w3c-intro<br />
* Timing constraint: none<br />
* Estimated room capacity: small room</div>Plehegarhttps://www.w3.org/wiki/index.php?title=TPAC/2019/SessionIdeas&diff=110076TPAC/2019/SessionIdeas2019-09-04T20:20:02Z<p>Plehegar: /* Introduction to W3C */ goals</p>
<hr />
<div>We encourage attendees to start brainstorming [[TPAC/2019]] Wednesday 18 September 2019 '''Technical Plenary Day''' Breakout sessions in advance of the meeting and until '''Tuesday 17 September 5 pm local time'''. <br />
<br />
See the [[TPAC/2019/FAQ | TPAC 2019 FAQ]] for more information. <br />
<br />
== How to use this page ==<br />
<br />
Please use this page to:<br />
<br />
* Propose sessions you wish you lead<br />
* Propose sessions you wish others to lead (it's a good idea to let them know ahead of time)<br />
* Indicate whether you plan to attend a session (helps with scheduling)<br />
* '''Please place new proposal at the bottom of this document'''<br />
<br />
== How to propose a session ==<br />
<br />
Please provide:<br />
<ul class="show_items"><br />
* session name (as a === subhead === )<br />
* session proposer (yourself, if so sign using 4 tildas; optional: name a desired session leader) and an email address<br />
* one sentence session summary<br />
* type of session: (e.g.: open discussion, talk, panel, etc.)<br />
* goals of session<br />
* additional speakers/panelists (to help reduce conflicts when one person is needed in more than one place)<br />
* any timing constraint you already know (e.g. you expect to invite someone in a different time zone)<br />
* if you can guess, whether you'll need a {big | medium | small} room (we can't guarantee you'll get it, however)<br />
* add an "Interested" bullet for people to sign up for sessions<br />
</ul><br />
<br />
== From an idea to a breakout ==<br />
<br />
<span style="color:#ff0000">'''The goal is to have a near-final breakout sessions schedule by the night before the plenary day (i.e. on Tuesday September 17 night), with only a few changes needed on the plenary day itself during the finalization phase at 09:45-10:30.</span><br />
<br />
This ensures a more inclusive process in how the breakout sessions are defined and scheduled (thus avoiding any mad scramble). An HTML and mobile-friendly filled-out session grid for the dayâs breakout sessions will be generated by the Team. [[TPAC/2019/FAQ#How_does_the_agenda_get_built.3F|Read more in our FAQ]].<br />
<br />
== Proposed sessions ==<br />
<br />
=== EXAMPLE session with session name ===<br />
* Proposer: <nowiki>~~~~</nowiki> (Instruction: remove <nowiki><nowiki> and </nowiki></nowiki> around the tildas. Explanation: The 4 tildas will sign YOUR name and include a timestamp of your proposal.)<br />
* Email address of proposer: <br />
* Summary (one-sentence or so): <br />
* Type of session (e.g.: open discussion, talk, panel, etc.): <br />
* Goals:<br />
* [optional] shortname (used for minting an IRC channel for the breakout)<br />
* [optional] Additional speakers/panelists:<br />
* [optional] Timing constraint: (e.g. you expect to invite someone in a different time zone)<br />
* [optional] Estimated room capacity: {big | medium | small} room<br />
<br />
=== ReSpec - so many new features! ===<br />
* Proposer: Marcos CĂĄceres<br />
* Email address of proposer: mcaceres@mozilla.com <br />
* Summary (one-sentence or so): Covering all the exciting advancements we've made in the last year, including automatic cross references, smart citations, MDN integration, and more! <br />
* Type of session: talk and open discussion <br />
* Goals: Introduce Editors to new features. <br />
* shortname: #pub<br />
* Additional speakers/panelists: Sid Vishnoi, Kagami Sascha Rosylight <br />
* [optional] Estimated room capacity: medium room<br />
<br />
=== Japan Language Requirements Task Force: Evolving the JLReq document ===<br />
* Proposer: [[User:Nmccully|Nathaniel McCully]] ([[User talk:Nmccully|talk]]) 16:29, 2 August 2019 (UTC)<br />
* Email address: nmccully@adobe.com<br />
* Summary: Explanation of the JLReq v2 effort currently underway, and a glimpse into the roadmap of a v3, that seeks to serve the needs of developers of layout engines for modern, dynamic media that support high-quality Japanese layout<br />
* Type of session: talk<br />
* Goals: To inform that this is happening, and get more people interested in the issues of high-end Japanese typography and layout in the context of responsive modern digital media.<br />
<br />
=== Results from MDN Developer Survey ===<br />
* Proposer: [[User:Dom|Dominique HazaĂŤl-Massieux]] ([[User talk:Dom|talk]]) 06:52, 5 August 2019 (UTC)<br />
* Email address: dom@w3.org<br />
* Summary: Meet the MDN Product Advisory Board and discuss how the results of the [https://hacks.mozilla.org/2019/07/mdn-web-developer-designer-survey/ MDN Developer Survey] can impact W3C's agenda<br />
* Type of session: short talk & discussion<br />
* Goals: Bring input to the MDN Product Advisory Board to see how MDN documentation can evolve to better meet the need from the W3C community; learn about the MDN Developer Survey and discuss what conclusions to draw from its results in terms of the W3C standardization agenda<br />
* Additional speakers/panelists: Kadir Topal, Dan Appelquist, Jory Burson, Travis Leithead, Joe Medley<br />
* shortname: mdn<br />
* Estimated room capacity: medium room<br />
<br />
=== Mini App Standardization ===<br />
* Proposer: [[User:laq|Angel Li]] 10:14, 14 August 2019 (UTC)<br />
* Email address: angelli.laq@alibaba-inc.com<br />
* Summary: Meet the major Mini App players, introduction of Mini App white paper drafted by W3C Chinese IG, discuss the way forward for Mini App Standardization in W3C<br />
* Type of session: short talk & discussion<br />
* Goals: help the global web community to better understand Mini App and the value of its standardization, find proper way to move forward in W3C<br />
* shortname: MiniApp<br />
* Estimated room capacity: medium room<br />
* Interested: [[User:Chris|Chris Lilley]] ([[User talk:Chris|talk]]) 13:54, 27 August 2019 (UTC)<br />
<br />
=== Web Packaging ===<br />
(Including Signed Exchanges and Bundles.)<br />
* Proposer: [[User:Jyasskin|Jeffrey Yasskin]] ([[User talk:Jyasskin|talk]]) 18:41, 14 August 2019 (UTC)<br />
* Email address of proposer: jyasskin@google.com<br />
* Summary (one-sentence or so): Discuss W3C feelings about the [Web Packaging proposal](https://github.com/WICG/webpackage).<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Short talk & discussion<br />
* Goals: Ensure everyone knows the state of the IETF discussion and the Chromium implementation; recruit collaborators; discover concerns and needed changes; get advice about what route through the W3C/WHATWG processes to follow.<br />
* [optional] shortname: wpack<br />
* [optional] Additional speakers/panelists: [[User:Kyasuda2|Kinuko Yasuda]]<br />
* [optional] Timing constraint: TBD<br />
* [optional] Estimated room capacity: medium room<br />
<br />
=== A target privacy threat model for the Web ===<br />
* Proposer: [[User:Jyasskin|Jeffrey Yasskin]] ([[User talk:Jyasskin|talk]]) 19:04, 14 August 2019 (UTC) (However, I'd love to have someone else lead this.)<br />
* Email address of proposer: jyasskin@google.com<br />
* Summary (one-sentence or so): Proposals for new features often encounter resistance from folks who want the Web Platform to defend its users' privacy better than it does today. This often surprises the authors of those proposals, who were designing against the Web's current, implicit, and weak privacy threat model. Making our privacy goals explicit could avoid those surprises and reduce the load on privacy reviewers.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Open discussion<br />
* Goals: Figure out whether there's interest in developing a target privacy threat model for the Web.<br />
* shortname: privthreatmodel<br />
* Additional speakers/panelists: [Your name here]<br />
* Timing constraint: <br />
: morning session would be preferable for East Coast remote attendees -- [[User:Npdoty|Nick Doty]] ([[User talk:Npdoty|talk]])<br />
* Estimated room capacity: large room --- with polycom to support remote attendees<br />
<br />
=== Next Generation TextTrackCue ===<br />
* Proposers: [[User:Ecarlson2|Eric Carlson]] ([[User talk:Ecarlson2|talk]]) 20:18, 15 August 2019 (UTC), [[User:Eoconnor|Theresa O'Connor]], [[User:PLemieux|Pierre-Anthony Lemieux]]<br />
* Email address of proposers: eric.carlson@apple.com,hober@apple.com,pal@sandflow.com<br />
* Summary: TextTrackCue enhancements for programmatic subtitle and caption presentation. We've been making progress since FOMS this past spring. Please see our FOMS slides for the basic idea: https://www.icloud.com/keynote/0GJUbJwWfA2i77M2JysKjj45w#Generic_Text_Cue_-_FOMS_2019<br />
* Type of session: talk and open discussion<br />
* Goals: Engage with browser engineers and media experts & gauge interest in pursuing this as new web API<br />
* shortname: textcueapi<br />
* Estimated room capacity: medium room (~20 people)<br />
<br />
=== JS Built-In Modules ===<br />
* Proposer: [[User:dcrousso|Devin Rousso]] ([[User talk:dcrousso|talk]]) 22:05, 15 August 2019 (UTC)<br />
* Email address of proposer: dcrousso@apple.com<br />
* Summary (one-sentence or so): introduction to the concept of JS Built-In Modules, as well as an overview of the currently proposed governance model<br />
* Type of session: talk<br />
* Goals: disseminate knowledge of JS Built-In modules to other hosts built on top of JavaScript (e.g. web browsers), and introduce the proposed governance model to potential stakeholders of additional JS Built-In Module namespaces (e.g. web:)<br />
* Additional speakers: Michael Saboff <msaboff@apple.com> (call-in TC39 proposal champion)<br />
* Timing constraint: friendly towards PST<br />
* Estimated room capacity: medium room<br />
<br />
=== WebTransport status and next steps ===<br />
* Proposer: Peter Thatcher<br />
* Email address of proposer: pthatcher@google.com<br />
* Summary (one-sentence or so): Discuss [https://github.com/WICG/web-transport WebTransport API] and next steps for a WG or CG<br />
* Type of session: short talk (maybe demo too) & discussion<br />
* Goals: Ensure everyone is up to date on the latest API, implementation status, and interaction with the IETF ([https://mailarchive.ietf.org/arch/browse/webtransport/ link to mailing list]; [https://tools.ietf.org/wg/dispatch/minutes link to DISPATCH minutes]); determine when and how we should create a WG or CG; discuss advanced API topics such as how best to use WHATWG streams, how to handle congestion control, and stream prioritization<br />
* Shortname: webtransport<br />
* Estimated room capacity: medium room<br />
<br />
=== Web stories ===<br />
* Proposer: [[User:Coralie|Coralie Mercier]] ([[User talk:Coralie|talk]]) 15:45, 20 August 2019 (UTC)<br />
* Email address of proposer: coralie@w3.org<br />
* Summary: Feedback and brainstorming for (re)introducing the Web Consortium to the public. The W3C Comm team wants to get background stories from our Members and community about how they were drawn to the Web (before the Web, or their first involvement with the Web). There is a path for how everyone in our community has come to the Web, what they see happening now and what they see in the future.<br />
* Type of session: open discussion<br />
* Goals: We want to gather stories in order to tell a compelling story to the public. W3C Comm team may use this as part of an upcoming crowdfunding campaign.<br />
* shortname: webstories<br />
* Estimated room capacity: medium room<br />
* Interested:<br />
** ...<br />
<br />
=== WebGPU ===<br />
* Proposer: Myles C. Maxfield<br />
* Email address of proposer: mmaxfield@apple.com<br />
* Summary (one-sentence or so): Update on the progress of WebGPU, and group discussion about future directions and what to focus on<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Talk and open discussion<br />
* Goals: Help people understand the direction that WebGPU is going, and get feedback from the broader community<br />
* [optional] shortname (used for minting an IRC channel for the breakout): webgpu<br />
* [optional] Additional speakers/panelists: Dean Jackson, anyone else in the CG<br />
* [optional] Estimated room capacity: medium room?<br />
<br />
=== DataCue and "Time marches on" in HTML ===<br />
* Proposers: [[User:chrisn|Chris Needham]] ([[User talk:chrisn|talk]]) 11:45, 22 August 2019 (UTC)<br />
* Email address of proposers: chris.needham@bbc.co.uk<br />
* Summary: The DataCue API for media-synchronised metadata and interactivity events is part of HTML5, but not implemented across all browsers, and existing implementations vary. There are also issues with the ''time marches on'' algorithm in HTML for triggering timed interactivity events<br />
* Type of session: talk and open discussion<br />
* Goals: To advance the DataCue API design between media experts and browser developers, and discuss how to improve synchronisation of media and associated content on the web<br />
* Shortname: #datacue<br />
* Timing constraint: Please avoid overlap with the Next Generation TextTrackCue breakout, as it's largely the same participants<br />
* Estimated room capacity: medium room<br />
<br />
=== Portals (status and next steps) ===<br />
* Proposer: [[User:Jbroman|Jeremy Roman]] ([[User talk:Jbroman|talk]]) 18:44, 22 August 2019 (UTC)<br />
* Email address of proposer: jbroman@google.com<br />
* Summary: Discuss Portals and next steps for a WG or CG. Portals allow for seamless navigation between different documents, same and cross origin, embedded or not. See hands-on article and WICG repository.<br />
* Type of session: short talk (possibly a few demos) followed by discussion<br />
* Goals: Ensure everyone is up to date on the latest proposed API, implementation status, use cases and interest from developers; determine what are the next steps, and concerns if any; discuss advanced API topics or use cases.<br />
* Shortname: portals<br />
* Estimated room capacity: medium room<br />
<br />
=== Ad Measurement and Privacy ===<br />
* Proposer: [[User:johnwilander|John Wilander]]<br />
* Email address of proposer: wilander@apple.com<br />
* Summary: We will discuss Apple's proposed and implemented [https://wicg.github.io/ad-click-attribution/index.html Private Click Measurement] and Google's proposed [https://github.com/csharrison/conversion-measurement-api Click Through Conversion Measurement].<br />
* Type of session: Open discussion <br />
* Goals: Discuss the open issue of fraud detection and what is required to ship this feature.<br />
* Estimated room capacity: Medium room<br />
<br />
=== Input for workers/worklets ===<br />
* Proposer: [[User:Nzolghadr|Navid Zolghadr]] ([[User talk:Nzolghadr|talk]]) 14:16, 26 August 2019 (UTC)<br />
* Email address of proposer: nzolghadr@chromium.org, majidvp@chromium.org<br />
* Summary: Towards exposing [https://wicg.github.io/input-for-workers input events to Workers and Worklets].<br />
* Type of session: Open discussion<br />
* Goals: Discuss use cases and implications, brainstorm the API<br />
* shortname: workerinput<br />
* Additional speakers/panelists: Majid Valipour<br />
* Estimated room capacity: medium<br />
<br />
=== Privacy Budget ===<br />
* Proposer [[User:Blassey|Brad Lassey]]<br />
* Email address of the proposer: lassey@google.com<br />
* Summary: Chrome proposed a [https://github.com/bslassey/privacy-budget "privacy budget"] to limit the ability for websites to fingerprint users. We's like to have a discussion around this proposal and its implications.<br />
* Type of session: Open discussion<br />
* Goals: Determine interest level from implementers, discuss concerns.<br />
* Shortname: privacybudget<br />
* Estimated room capacity: medium<br />
* Interested:<br />
<br />
=== Trust Tokens ===<br />
* Proposer: [[User:blassey|Brad Lassey]]<br />
* Email address of the proposer: lassey@google.com<br />
* Summary: Cloudflare proposed the concept of the [https://privacypass.github.io/ Privacy Pass protocol] to avoid repeatedly showing captchas to Tor users and Chrome expanded on the idea to propose a more general purpose [https://github.com/dvorak42/trust-token-api Trust Token API] for conveying user trust between parties in order to prevent fraud.<br />
* Type of session: Open discussion<br />
* Goals: Determine interest level from implementers, discuss concerns.<br />
* Shortname: trusttokens<br />
* Additional speakers/panelists: [[User:Kleber|Michael Kleber]]<br />
* Estimated room capacity: medium<br />
* Interested:<br />
<br />
=== OpenJS Foundation Collaboration ===<br />
* Proposer: [[User:Jburson|Jordana Burson]] ([[User talk:Jburson|talk]]) 14:28, 28 August 2019 (UTC)<br />
* Email address of proposer: jory@bocoup.com<br />
* Summary (one-sentence or so): Members of the OpenJS Foundation cross project council would like to propose a 'BoF' conversation about how to build and strengthen healthy collaborations between foundation projects and W3C groups.<br />
* Type of session: open discussion<br />
* Goals:<br />
* [optional] shortname (used for minting an IRC channel for the breakout)<br />
* [optional] Additional speakers/panelists: Myles Borins, Christian Bromann, Brian Kardell<br />
* [optional] Timing constraint: (e.g. you expect to invite someone in a different time zone): none<br />
* [optional] Estimated room capacity: {big | medium | small} room: small<br />
<br />
=== Supporting privacy-focused ads selection ===<br />
* Proposer: [[User:Kleber|Michael Kleber]] ([[User talk:Kleber|talk]]) 00:40, 29 August 2019 (UTC)<br />
* Email address of the proposer: kleber@google.com<br />
* Summary: Discussion of various ideas for how browsers could support ad selection use cases which today rely on users having a consistent cross-site identity. Chrome has explainers out for [https://github.com/jkarlin/floc "Federated Learning of Cohorts" (FLoC)] and [https://github.com/michaelkleber/pigin "Private Interest Groups, Including Noise (PIGIN)"].<br />
* Type of session: Open discussion<br />
* Goals: Determine interest level from implementers, discuss concerns.<br />
* Shortname: adselection<br />
* Estimated room capacity: medium<br />
* Interested:<br />
<br />
=== XR Accessibility ===<br />
* Proposer: [[User:Joconnor|Joshue O Connor]] ([[User talk:Joconnor|talk]]) 14:11, 29 August 2019 (UTC)Joshue O Connor<br />
* Email address: joconnor@w3.org<br />
* Summary: Explore how to grow a broader accessibility community in the areas of XR (Virtual and Augmented Reality).<br />
* Type of session: Talk and Open Discussion <br />
* Goals: Figure out how to bring together the accessibility community to build capability, collaboration and community engagement in developing standards that address the challenges of making Virtual and Augmented Reality accessible. <br />
* Shortname: xra11y<br />
* Additional speakers/panelists: TBD<br />
* Estimated room capacity: medium room<br />
<br />
=== Standardizing user activation behavior ===<br />
* Proposer: [[User:Mustaq|Mustaq Ahmed]] ([[User talk:Mustaq|talk]]) 14:15, 29 August 2019 (UTC)<br />
* Email address of proposer: mustaq@google.com<br />
* Summary: We are proposing to replace the user activation model implied by the current HTML spec with a simple-to-implement model because the current model doesn't reflect the reality (https://github.com/whatwg/html/issues/1903).<br />
* Type of session: Open discussion<br />
* Goals: Trying to reach consensus on our proposed change to the spec (https://github.com/whatwg/html/pull/3851).<br />
* shortname: user-activation<br />
* Additional speakers/panelists: Domenic Denicola<br />
* Estimated room capacity: medium<br />
<br />
=== WebCodecs ===<br />
* Proposer: [[User:Pthatcher|Peter Thatcher]] ([[User talk:Pthatcher|talk]]) 01:04, 30 August 2019 (UTC) <br />
* Email address of proposer: pthatcher@google.com<br />
* Summary: Discuss WebCodecs (https://discourse.wicg.io/t/webcodecs-proposal/3662)<br />
* Type of session: short talk (maybe demo too) & discussion<br />
* Goals: Get input from potential users of the API to see what use cases we need to make sure are well supported, as well as from experts of codecs. <br />
* Shortname: webcodecs<br />
* Estimated room capacity: small room<br />
<br />
=== Bullet Chatting ===<br />
* Proposer: [[User:Song Xu|Song Xu]] ([[User talk:Song Xu|talk]]) <br />
* Email address of proposer: xusong@migu.cn<br />
* Summary: Introduce what is the Bullet Chatting , and introduce the Bullet Chatting specification drafted by W3C Chinese Interest Group. Discuss the way forward for Bullet Chatting standardization in W3C.<br />
* Type of session: talk & discussion<br />
* Goals: Help the global web community to better understand Bullet Chatting and the value of its standardization, and looking for teams interested in Bullet Chatting standardization, hoping to get some feedback and support, and get advice about what the W3C workflow. <br />
* Shortname: bulletchat<br />
* Estimated room capacity: small room<br />
<br />
=== Efficient audio/video processing ===<br />
* Proposer: François Daoust / Dominique HazaÍl-Massieux / 02 September 2019<br />
* Email address of proposer: fd@w3.org, dom@w3.org<br />
* Summary: W3C groups (e.g. WebRTC WG, Machine Learning for the Web CG, Audio WG, Media WG, Immersive Web WG) discuss, develop and/or dream about ways to process audio/video streams efficiently. Use cases include barcode reading, face/gesture tracking, emotion analysis, funny hats, background removal or blurring, augmented reality, video overlays, voice effects, or custom codecs. Would it be useful and possible to develop a common mechanism that different APIs could leverage to hook together with streams of media while avoiding useless memory copies? What could such a mechanism look like?<br />
* Type of session: open discussion<br />
* Goals: Look at use cases and at how they can be implemented today, assess possible performance gains if they were implemented with a more efficient mechanism, refine scope for possible work on the topic, and gauge interest among parties.<br />
* Additional speakers/panelists: Rijubrata Bhaumik, Paul Adenot, Peter Thatcher, Joshue O Connor<br />
* Shortname: mediaprocessing<br />
* Estimated room capacity: medium<br />
<br />
=== HTML 3D Element ===<br />
* Proposer: [[User:zyu5|Zhiqiang Yu]] <br />
* Email address: yuzhiqiang5@huawei.com<br />
* Summary: A proposal on HTML 3D element, to bring rich 3D & AR experience to Web with a single line of code. Use cases include on-line shopping, creative advertisement,education, etc. A few demos will be shown as well.<br />
* Type of session: short talk & discussion<br />
* Goals: promote the HTML 3D tag and looking forward to a wider collaboration w/ the community, as well as standardization in W3C.<br />
* shortname: HTML 3D<br />
* Estimated room capacity: medium room<br />
<br />
=== Native GLTF ===<br />
* Proposer: [[User:sushraja| Sushanth Rajasankar]]<br />
* Email address: sushraja@microsoft.com<br />
* Summary: Discuss a proposal for a scene element https://github.com/immersive-web/proposals/issues/52. That allows for native 3d content presentation. Demo Prototype. (Perhaps this can be a part of the previous session "HTML 3D Element").<br />
* Type of session: short talk & discussion<br />
* Goals: Gauge developer interest in adding native support for gltf in the browser and engage with the community.<br />
* ShortName: Native GLTF<br />
* Estimated room capacity: medium room.<br />
<br />
=== Voice assistants - opportunities for standardization? ===<br />
* Proposer: [[User:Philarcher|Phil Archer, GS1]] ([[User talk:Philarcher|talk]]) 09:28, 3 September 2019 (UTC)<br />
* Email address of proposer: phil.archer@gs1.org<br />
* Summary (one-sentence or so): Voice assistants present exciting new methods to interact with the Web but how can/should we develop standards that benefit all stake holders from start ups to tech giants? <br />
* Type of session: Discussion<br />
* Goals: To identify parties most interested in the generic area of voice interaction and to narrow that down to a set of more specific areas of interest. E-commerce? Fact checking? Media streaming? APIs for Skills, More ...<br />
* [optional] shortname: voice<br />
* [optional] Additional speakers/panelists: LĂŠonie Watson, Mark Hakkinen<br />
* [optional] Estimated room capacity: small room<br />
<br />
=== Github tools and Bots to assist Chairing ===<br />
* Proposer: [[User:Adaroseedwards|Ada Rose Cannon]] ([[User talk:Adaroseedwards|talk]]) 10:19, 3 September 2019 (UTC)<br />
* Email address of proposer: ada@ada.is <br />
* Summary: I'm a lazy chair and have created bots and scripts to help me chair, this is to show some of the tools I use to help leverage Github's APIs to help chair. I would also be interested in other tools people use to automate some of their teams.<br />
* Type of session: Presentation + Discussion<br />
* Goals: Share tools used.<br />
* [optional] shortname: groupautomation<br />
* [optional] Estimated room capacity: small room<br />
<br />
=== WebAuthn network transport discussion ===<br />
* Proposer(s): James Barclay, [[User:Nmooney|Nick Mooney]] ([[User talk:Nmooney|talk]]) 17:02, 3 September 2019 (UTC)<br />
* Emails: {jbarclay,nmooney}@duosecurity.com<br />
* Summary: Discuss the development of a new network-based transport as an addition to the WebAuthn specification.<br />
* Type: talk, open discussion<br />
* Goals: motivate the need for a network-based WebAuthn transport, discuss how this might look as part of the specification, discuss phishing resistance and proximity<br />
* Shortname: #webauthnnetwork<br />
* Estimated room capacity: medium<br />
<br />
=== Q&A about DIDs (Decentralized Identifiers) ===<br />
* Proposer: [[User:Drummondreed|Drummond Reed]] ([[User talk:Drummondreed|talk]]) 17:53, 3 September 2019 (UTC)<br />
* Email address of proposer: drummond.reed@evernym.com<br />
* Summary (one-sentence or so): DIDs are a new form of cryptographically-verifiable identifier, and TPAC will host the first meeting of the (still not final) W3C DID WG. This is a chance to learn more about DIDs.<br />
* Type of session: open discussion<br />
* Goals: The primary goal is to answer questions about DIDs and help W3C members understand the market interest in this new type of identifier.<br />
* Shortname: #did<br />
* Additional speakers/panelists: Manu Sporny, Dan Burnett, Christopher Allen<br />
* Estimated room capacity: medium room<br />
<br />
=== UndoManager API ===<br />
* Proposer: [[User:Whsieh|Wenson Hsieh]] ([[User talk:Whsieh|talk]]) 20:28, 3 September 2019 (UTC)<br />
* Email address of proposer: wenson_hsieh@apple.com<br />
* Summary (one-sentence or so): The UndoManager API allows web applications to modify the platform undo stack, and scope undo stacks to elements.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): talk, open discussion<br />
* Goals: Introduce a proposal for the UndoManager API, which allows web applications to modify and inspect the platformâs undo stack. This has implications for all types of web apps, with particular relevance to editing and productivity apps. We hope to establish context for the UndoManager API, demo a prototype of the API, and gain feedback for our proposal.<br />
* Shortname: undomanager<br />
* Additional speakers/panelists: Megan Gardner<br />
* Estimated room capacity: small room<br />
<br />
=== Linked Data Security ===<br />
* Proposer: [[User:Msporny|Manu Sporny]] ([[User talk:Msporny|talk]]) 22:11, 3 September 2019 (UTC)<br />
* Email address of proposer: msporny@digitalbazaar.com<br />
* Summary (one-sentence or so): Should we standardize: RDF Dataset Canonicalization, Linked Data Proofs, Linked Data Signatures, RSA2019Signature, Ed25519Signature, and if so, on what timeline?<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): open discussion<br />
* Goals: Determine if certain Linked Data Security technologies are ready for standardization.<br />
* [optional] ldsec<br />
* [optional] Additional speakers/panelists: Ivan Herman, Gregg Kellogg, Benjamin Young, Robert Sanderson<br />
* [optional] Timing constraint: Don't overlap with DID session<br />
* [optional] Estimated room capacity: small<br />
<br />
=== What is the Future of W3C ===<br />
* Proposer: [[Tantek]] (Mozilla) ([[User:Tantekelik|Tantek Ăelik]] ([[User talk:Tantekelik|talk]]) 22:58, 3 September 2019 (UTC))<br />
* Email address of proposer: tantek@cs.stanford.edu<br />
* Summary: How should W3C evolve to better serve the web community? The AB and AC are discussing changes to its structure, but they need to hear from stakeholders about the mission and the structure designed to achieve it.<br />
* Type of session: open discussion<br />
* shortname: #future<br />
* Timing constraint: prefer Pacific Time Zone friendly time if possible for remote participation<br />
* Estimated room capacity: medium<br />
* Additional speakers/panelists: Michael Champion (Microsoft, possibly remote), Chris Wilson (Google)<br />
* Goals: A discussion to understand the community's level of consensus on fundamental questions:<br />
** Mission â W3Câs traditional mission statement is âlead the web to its full potentialâ. Does the community believe W3Câs basic value proposition need updating, perhaps to focus on some combination of documenting how the web actually works, certifying which products comply with the consensus standards, and focusing on the most pressing challenges to the original vision?<br />
** Leadership â The founding Director is no longer involved with W3Câs day to day operations, but the âDirectorâ has a key role in the process and governance. Would the community be more comfortable with finding another neutral person with considerable expertise who can commit the time to being Director, or delegating tasks such as adjudicating formal objections to some sort of elected council?<br />
** Staffing â What role or roles should the Team prioritize and focus on? Mechanics of consensus building, or technical guidance on solutions?<br />
* Interested:<br />
** [[User:Coralie|Coralie Mercier]] ([[User talk:Coralie|talk]]) 17:31, 4 September 2019 (UTC)<br />
** ...<br />
<br />
=== Web of Things PlugFest ===<br />
* Proposer: [[User:Ashimura|Kazuyuki Ashimura]] ([[User talk:Ashimura|talk]]) 17:21, 4 September 2019 (UTC)<br />
* Email address of proposer: ashimura@w3.org<br />
* Summary: The WoT-IG/WG would like to have its PlugFest demo at 13:30-14:30 to (1) present what kind of demos are included and (2) show actual demos which include various scenarios and combinations of devices/applications for IoT purposes.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Presentaton and Demo<br />
* Goals: Show what is done by the WoT WG/IG based on the WoT standards to all the TPAC attendees and encourage people to collaborate with the group (and join the group :). This time we'd like to show several different combinations of devices/applications and scenarios based on the WoT specifications. Please see also the [https://github.com/endouhhc/wot/blob/master/plugfest/2019-tpac-fukuoka/README.md PlugFest preparation page].<br />
* shortname: wot-pf<br />
* Timing constraint: 13:30-14:30<br />
* Estimated room capacity: big room<br />
<br />
=== Introduction to W3C ===<br />
* Proposer: [[User:Plehegar|Philippe Le HĂŠgaret]] ([[User talk:Plehegar|talk]]) 20:12, 4 September 2019 (UTC)<br />
* Email address of proposer: plh@w3.org<br />
* Summary (one-sentence or so): If you're a new Group participant in the W3C, this session will guide you through the W3C labyrinth and allow you to contribute to the Web<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): talk, tutorial, open discussion<br />
* Goals: Make sure attendees are up-to-speed on how to participate in their Groups, get familiar with various documentations and tools used by W3C, including GitHub.<br />
* w3c-intro<br />
* Timing constraint: none<br />
* Estimated room capacity: small room</div>Plehegarhttps://www.w3.org/wiki/index.php?title=TPAC/2019/SessionIdeas&diff=110075TPAC/2019/SessionIdeas2019-09-04T20:12:07Z<p>Plehegar: Added Intro to W3C</p>
<hr />
<div>We encourage attendees to start brainstorming [[TPAC/2019]] Wednesday 18 September 2019 '''Technical Plenary Day''' Breakout sessions in advance of the meeting and until '''Tuesday 17 September 5 pm local time'''. <br />
<br />
See the [[TPAC/2019/FAQ | TPAC 2019 FAQ]] for more information. <br />
<br />
== How to use this page ==<br />
<br />
Please use this page to:<br />
<br />
* Propose sessions you wish you lead<br />
* Propose sessions you wish others to lead (it's a good idea to let them know ahead of time)<br />
* Indicate whether you plan to attend a session (helps with scheduling)<br />
* '''Please place new proposal at the bottom of this document'''<br />
<br />
== How to propose a session ==<br />
<br />
Please provide:<br />
<ul class="show_items"><br />
* session name (as a === subhead === )<br />
* session proposer (yourself, if so sign using 4 tildas; optional: name a desired session leader) and an email address<br />
* one sentence session summary<br />
* type of session: (e.g.: open discussion, talk, panel, etc.)<br />
* goals of session<br />
* additional speakers/panelists (to help reduce conflicts when one person is needed in more than one place)<br />
* any timing constraint you already know (e.g. you expect to invite someone in a different time zone)<br />
* if you can guess, whether you'll need a {big | medium | small} room (we can't guarantee you'll get it, however)<br />
* add an "Interested" bullet for people to sign up for sessions<br />
</ul><br />
<br />
== From an idea to a breakout ==<br />
<br />
<span style="color:#ff0000">'''The goal is to have a near-final breakout sessions schedule by the night before the plenary day (i.e. on Tuesday September 17 night), with only a few changes needed on the plenary day itself during the finalization phase at 09:45-10:30.</span><br />
<br />
This ensures a more inclusive process in how the breakout sessions are defined and scheduled (thus avoiding any mad scramble). An HTML and mobile-friendly filled-out session grid for the dayâs breakout sessions will be generated by the Team. [[TPAC/2019/FAQ#How_does_the_agenda_get_built.3F|Read more in our FAQ]].<br />
<br />
== Proposed sessions ==<br />
<br />
=== EXAMPLE session with session name ===<br />
* Proposer: <nowiki>~~~~</nowiki> (Instruction: remove <nowiki><nowiki> and </nowiki></nowiki> around the tildas. Explanation: The 4 tildas will sign YOUR name and include a timestamp of your proposal.)<br />
* Email address of proposer: <br />
* Summary (one-sentence or so): <br />
* Type of session (e.g.: open discussion, talk, panel, etc.): <br />
* Goals:<br />
* [optional] shortname (used for minting an IRC channel for the breakout)<br />
* [optional] Additional speakers/panelists:<br />
* [optional] Timing constraint: (e.g. you expect to invite someone in a different time zone)<br />
* [optional] Estimated room capacity: {big | medium | small} room<br />
<br />
=== ReSpec - so many new features! ===<br />
* Proposer: Marcos CĂĄceres<br />
* Email address of proposer: mcaceres@mozilla.com <br />
* Summary (one-sentence or so): Covering all the exciting advancements we've made in the last year, including automatic cross references, smart citations, MDN integration, and more! <br />
* Type of session: talk and open discussion <br />
* Goals: Introduce Editors to new features. <br />
* shortname: #pub<br />
* Additional speakers/panelists: Sid Vishnoi, Kagami Sascha Rosylight <br />
* [optional] Estimated room capacity: medium room<br />
<br />
=== Japan Language Requirements Task Force: Evolving the JLReq document ===<br />
* Proposer: [[User:Nmccully|Nathaniel McCully]] ([[User talk:Nmccully|talk]]) 16:29, 2 August 2019 (UTC)<br />
* Email address: nmccully@adobe.com<br />
* Summary: Explanation of the JLReq v2 effort currently underway, and a glimpse into the roadmap of a v3, that seeks to serve the needs of developers of layout engines for modern, dynamic media that support high-quality Japanese layout<br />
* Type of session: talk<br />
* Goals: To inform that this is happening, and get more people interested in the issues of high-end Japanese typography and layout in the context of responsive modern digital media.<br />
<br />
=== Results from MDN Developer Survey ===<br />
* Proposer: [[User:Dom|Dominique HazaĂŤl-Massieux]] ([[User talk:Dom|talk]]) 06:52, 5 August 2019 (UTC)<br />
* Email address: dom@w3.org<br />
* Summary: Meet the MDN Product Advisory Board and discuss how the results of the [https://hacks.mozilla.org/2019/07/mdn-web-developer-designer-survey/ MDN Developer Survey] can impact W3C's agenda<br />
* Type of session: short talk & discussion<br />
* Goals: Bring input to the MDN Product Advisory Board to see how MDN documentation can evolve to better meet the need from the W3C community; learn about the MDN Developer Survey and discuss what conclusions to draw from its results in terms of the W3C standardization agenda<br />
* Additional speakers/panelists: Kadir Topal, Dan Appelquist, Jory Burson, Travis Leithead, Joe Medley<br />
* shortname: mdn<br />
* Estimated room capacity: medium room<br />
<br />
=== Mini App Standardization ===<br />
* Proposer: [[User:laq|Angel Li]] 10:14, 14 August 2019 (UTC)<br />
* Email address: angelli.laq@alibaba-inc.com<br />
* Summary: Meet the major Mini App players, introduction of Mini App white paper drafted by W3C Chinese IG, discuss the way forward for Mini App Standardization in W3C<br />
* Type of session: short talk & discussion<br />
* Goals: help the global web community to better understand Mini App and the value of its standardization, find proper way to move forward in W3C<br />
* shortname: MiniApp<br />
* Estimated room capacity: medium room<br />
* Interested: [[User:Chris|Chris Lilley]] ([[User talk:Chris|talk]]) 13:54, 27 August 2019 (UTC)<br />
<br />
=== Web Packaging ===<br />
(Including Signed Exchanges and Bundles.)<br />
* Proposer: [[User:Jyasskin|Jeffrey Yasskin]] ([[User talk:Jyasskin|talk]]) 18:41, 14 August 2019 (UTC)<br />
* Email address of proposer: jyasskin@google.com<br />
* Summary (one-sentence or so): Discuss W3C feelings about the [Web Packaging proposal](https://github.com/WICG/webpackage).<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Short talk & discussion<br />
* Goals: Ensure everyone knows the state of the IETF discussion and the Chromium implementation; recruit collaborators; discover concerns and needed changes; get advice about what route through the W3C/WHATWG processes to follow.<br />
* [optional] shortname: wpack<br />
* [optional] Additional speakers/panelists: [[User:Kyasuda2|Kinuko Yasuda]]<br />
* [optional] Timing constraint: TBD<br />
* [optional] Estimated room capacity: medium room<br />
<br />
=== A target privacy threat model for the Web ===<br />
* Proposer: [[User:Jyasskin|Jeffrey Yasskin]] ([[User talk:Jyasskin|talk]]) 19:04, 14 August 2019 (UTC) (However, I'd love to have someone else lead this.)<br />
* Email address of proposer: jyasskin@google.com<br />
* Summary (one-sentence or so): Proposals for new features often encounter resistance from folks who want the Web Platform to defend its users' privacy better than it does today. This often surprises the authors of those proposals, who were designing against the Web's current, implicit, and weak privacy threat model. Making our privacy goals explicit could avoid those surprises and reduce the load on privacy reviewers.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Open discussion<br />
* Goals: Figure out whether there's interest in developing a target privacy threat model for the Web.<br />
* shortname: privthreatmodel<br />
* Additional speakers/panelists: [Your name here]<br />
* Timing constraint: <br />
: morning session would be preferable for East Coast remote attendees -- [[User:Npdoty|Nick Doty]] ([[User talk:Npdoty|talk]])<br />
* Estimated room capacity: large room --- with polycom to support remote attendees<br />
<br />
=== Next Generation TextTrackCue ===<br />
* Proposers: [[User:Ecarlson2|Eric Carlson]] ([[User talk:Ecarlson2|talk]]) 20:18, 15 August 2019 (UTC), [[User:Eoconnor|Theresa O'Connor]], [[User:PLemieux|Pierre-Anthony Lemieux]]<br />
* Email address of proposers: eric.carlson@apple.com,hober@apple.com,pal@sandflow.com<br />
* Summary: TextTrackCue enhancements for programmatic subtitle and caption presentation. We've been making progress since FOMS this past spring. Please see our FOMS slides for the basic idea: https://www.icloud.com/keynote/0GJUbJwWfA2i77M2JysKjj45w#Generic_Text_Cue_-_FOMS_2019<br />
* Type of session: talk and open discussion<br />
* Goals: Engage with browser engineers and media experts & gauge interest in pursuing this as new web API<br />
* shortname: textcueapi<br />
* Estimated room capacity: medium room (~20 people)<br />
<br />
=== JS Built-In Modules ===<br />
* Proposer: [[User:dcrousso|Devin Rousso]] ([[User talk:dcrousso|talk]]) 22:05, 15 August 2019 (UTC)<br />
* Email address of proposer: dcrousso@apple.com<br />
* Summary (one-sentence or so): introduction to the concept of JS Built-In Modules, as well as an overview of the currently proposed governance model<br />
* Type of session: talk<br />
* Goals: disseminate knowledge of JS Built-In modules to other hosts built on top of JavaScript (e.g. web browsers), and introduce the proposed governance model to potential stakeholders of additional JS Built-In Module namespaces (e.g. web:)<br />
* Additional speakers: Michael Saboff <msaboff@apple.com> (call-in TC39 proposal champion)<br />
* Timing constraint: friendly towards PST<br />
* Estimated room capacity: medium room<br />
<br />
=== WebTransport status and next steps ===<br />
* Proposer: Peter Thatcher<br />
* Email address of proposer: pthatcher@google.com<br />
* Summary (one-sentence or so): Discuss [https://github.com/WICG/web-transport WebTransport API] and next steps for a WG or CG<br />
* Type of session: short talk (maybe demo too) & discussion<br />
* Goals: Ensure everyone is up to date on the latest API, implementation status, and interaction with the IETF ([https://mailarchive.ietf.org/arch/browse/webtransport/ link to mailing list]; [https://tools.ietf.org/wg/dispatch/minutes link to DISPATCH minutes]); determine when and how we should create a WG or CG; discuss advanced API topics such as how best to use WHATWG streams, how to handle congestion control, and stream prioritization<br />
* Shortname: webtransport<br />
* Estimated room capacity: medium room<br />
<br />
=== Web stories ===<br />
* Proposer: [[User:Coralie|Coralie Mercier]] ([[User talk:Coralie|talk]]) 15:45, 20 August 2019 (UTC)<br />
* Email address of proposer: coralie@w3.org<br />
* Summary: Feedback and brainstorming for (re)introducing the Web Consortium to the public. The W3C Comm team wants to get background stories from our Members and community about how they were drawn to the Web (before the Web, or their first involvement with the Web). There is a path for how everyone in our community has come to the Web, what they see happening now and what they see in the future.<br />
* Type of session: open discussion<br />
* Goals: We want to gather stories in order to tell a compelling story to the public. W3C Comm team may use this as part of an upcoming crowdfunding campaign.<br />
* shortname: webstories<br />
* Estimated room capacity: medium room<br />
* Interested:<br />
** ...<br />
<br />
=== WebGPU ===<br />
* Proposer: Myles C. Maxfield<br />
* Email address of proposer: mmaxfield@apple.com<br />
* Summary (one-sentence or so): Update on the progress of WebGPU, and group discussion about future directions and what to focus on<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Talk and open discussion<br />
* Goals: Help people understand the direction that WebGPU is going, and get feedback from the broader community<br />
* [optional] shortname (used for minting an IRC channel for the breakout): webgpu<br />
* [optional] Additional speakers/panelists: Dean Jackson, anyone else in the CG<br />
* [optional] Estimated room capacity: medium room?<br />
<br />
=== DataCue and "Time marches on" in HTML ===<br />
* Proposers: [[User:chrisn|Chris Needham]] ([[User talk:chrisn|talk]]) 11:45, 22 August 2019 (UTC)<br />
* Email address of proposers: chris.needham@bbc.co.uk<br />
* Summary: The DataCue API for media-synchronised metadata and interactivity events is part of HTML5, but not implemented across all browsers, and existing implementations vary. There are also issues with the ''time marches on'' algorithm in HTML for triggering timed interactivity events<br />
* Type of session: talk and open discussion<br />
* Goals: To advance the DataCue API design between media experts and browser developers, and discuss how to improve synchronisation of media and associated content on the web<br />
* Shortname: #datacue<br />
* Timing constraint: Please avoid overlap with the Next Generation TextTrackCue breakout, as it's largely the same participants<br />
* Estimated room capacity: medium room<br />
<br />
=== Portals (status and next steps) ===<br />
* Proposer: [[User:Jbroman|Jeremy Roman]] ([[User talk:Jbroman|talk]]) 18:44, 22 August 2019 (UTC)<br />
* Email address of proposer: jbroman@google.com<br />
* Summary: Discuss Portals and next steps for a WG or CG. Portals allow for seamless navigation between different documents, same and cross origin, embedded or not. See hands-on article and WICG repository.<br />
* Type of session: short talk (possibly a few demos) followed by discussion<br />
* Goals: Ensure everyone is up to date on the latest proposed API, implementation status, use cases and interest from developers; determine what are the next steps, and concerns if any; discuss advanced API topics or use cases.<br />
* Shortname: portals<br />
* Estimated room capacity: medium room<br />
<br />
=== Ad Measurement and Privacy ===<br />
* Proposer: [[User:johnwilander|John Wilander]]<br />
* Email address of proposer: wilander@apple.com<br />
* Summary: We will discuss Apple's proposed and implemented [https://wicg.github.io/ad-click-attribution/index.html Private Click Measurement] and Google's proposed [https://github.com/csharrison/conversion-measurement-api Click Through Conversion Measurement].<br />
* Type of session: Open discussion <br />
* Goals: Discuss the open issue of fraud detection and what is required to ship this feature.<br />
* Estimated room capacity: Medium room<br />
<br />
=== Input for workers/worklets ===<br />
* Proposer: [[User:Nzolghadr|Navid Zolghadr]] ([[User talk:Nzolghadr|talk]]) 14:16, 26 August 2019 (UTC)<br />
* Email address of proposer: nzolghadr@chromium.org, majidvp@chromium.org<br />
* Summary: Towards exposing [https://wicg.github.io/input-for-workers input events to Workers and Worklets].<br />
* Type of session: Open discussion<br />
* Goals: Discuss use cases and implications, brainstorm the API<br />
* shortname: workerinput<br />
* Additional speakers/panelists: Majid Valipour<br />
* Estimated room capacity: medium<br />
<br />
=== Privacy Budget ===<br />
* Proposer [[User:Blassey|Brad Lassey]]<br />
* Email address of the proposer: lassey@google.com<br />
* Summary: Chrome proposed a [https://github.com/bslassey/privacy-budget "privacy budget"] to limit the ability for websites to fingerprint users. We's like to have a discussion around this proposal and its implications.<br />
* Type of session: Open discussion<br />
* Goals: Determine interest level from implementers, discuss concerns.<br />
* Shortname: privacybudget<br />
* Estimated room capacity: medium<br />
* Interested:<br />
<br />
=== Trust Tokens ===<br />
* Proposer: [[User:blassey|Brad Lassey]]<br />
* Email address of the proposer: lassey@google.com<br />
* Summary: Cloudflare proposed the concept of the [https://privacypass.github.io/ Privacy Pass protocol] to avoid repeatedly showing captchas to Tor users and Chrome expanded on the idea to propose a more general purpose [https://github.com/dvorak42/trust-token-api Trust Token API] for conveying user trust between parties in order to prevent fraud.<br />
* Type of session: Open discussion<br />
* Goals: Determine interest level from implementers, discuss concerns.<br />
* Shortname: trusttokens<br />
* Additional speakers/panelists: [[User:Kleber|Michael Kleber]]<br />
* Estimated room capacity: medium<br />
* Interested:<br />
<br />
=== OpenJS Foundation Collaboration ===<br />
* Proposer: [[User:Jburson|Jordana Burson]] ([[User talk:Jburson|talk]]) 14:28, 28 August 2019 (UTC)<br />
* Email address of proposer: jory@bocoup.com<br />
* Summary (one-sentence or so): Members of the OpenJS Foundation cross project council would like to propose a 'BoF' conversation about how to build and strengthen healthy collaborations between foundation projects and W3C groups.<br />
* Type of session: open discussion<br />
* Goals:<br />
* [optional] shortname (used for minting an IRC channel for the breakout)<br />
* [optional] Additional speakers/panelists: Myles Borins, Christian Bromann, Brian Kardell<br />
* [optional] Timing constraint: (e.g. you expect to invite someone in a different time zone): none<br />
* [optional] Estimated room capacity: {big | medium | small} room: small<br />
<br />
=== Supporting privacy-focused ads selection ===<br />
* Proposer: [[User:Kleber|Michael Kleber]] ([[User talk:Kleber|talk]]) 00:40, 29 August 2019 (UTC)<br />
* Email address of the proposer: kleber@google.com<br />
* Summary: Discussion of various ideas for how browsers could support ad selection use cases which today rely on users having a consistent cross-site identity. Chrome has explainers out for [https://github.com/jkarlin/floc "Federated Learning of Cohorts" (FLoC)] and [https://github.com/michaelkleber/pigin "Private Interest Groups, Including Noise (PIGIN)"].<br />
* Type of session: Open discussion<br />
* Goals: Determine interest level from implementers, discuss concerns.<br />
* Shortname: adselection<br />
* Estimated room capacity: medium<br />
* Interested:<br />
<br />
=== XR Accessibility ===<br />
* Proposer: [[User:Joconnor|Joshue O Connor]] ([[User talk:Joconnor|talk]]) 14:11, 29 August 2019 (UTC)Joshue O Connor<br />
* Email address: joconnor@w3.org<br />
* Summary: Explore how to grow a broader accessibility community in the areas of XR (Virtual and Augmented Reality).<br />
* Type of session: Talk and Open Discussion <br />
* Goals: Figure out how to bring together the accessibility community to build capability, collaboration and community engagement in developing standards that address the challenges of making Virtual and Augmented Reality accessible. <br />
* Shortname: xra11y<br />
* Additional speakers/panelists: TBD<br />
* Estimated room capacity: medium room<br />
<br />
=== Standardizing user activation behavior ===<br />
* Proposer: [[User:Mustaq|Mustaq Ahmed]] ([[User talk:Mustaq|talk]]) 14:15, 29 August 2019 (UTC)<br />
* Email address of proposer: mustaq@google.com<br />
* Summary: We are proposing to replace the user activation model implied by the current HTML spec with a simple-to-implement model because the current model doesn't reflect the reality (https://github.com/whatwg/html/issues/1903).<br />
* Type of session: Open discussion<br />
* Goals: Trying to reach consensus on our proposed change to the spec (https://github.com/whatwg/html/pull/3851).<br />
* shortname: user-activation<br />
* Additional speakers/panelists: Domenic Denicola<br />
* Estimated room capacity: medium<br />
<br />
=== WebCodecs ===<br />
* Proposer: [[User:Pthatcher|Peter Thatcher]] ([[User talk:Pthatcher|talk]]) 01:04, 30 August 2019 (UTC) <br />
* Email address of proposer: pthatcher@google.com<br />
* Summary: Discuss WebCodecs (https://discourse.wicg.io/t/webcodecs-proposal/3662)<br />
* Type of session: short talk (maybe demo too) & discussion<br />
* Goals: Get input from potential users of the API to see what use cases we need to make sure are well supported, as well as from experts of codecs. <br />
* Shortname: webcodecs<br />
* Estimated room capacity: small room<br />
<br />
=== Bullet Chatting ===<br />
* Proposer: [[User:Song Xu|Song Xu]] ([[User talk:Song Xu|talk]]) <br />
* Email address of proposer: xusong@migu.cn<br />
* Summary: Introduce what is the Bullet Chatting , and introduce the Bullet Chatting specification drafted by W3C Chinese Interest Group. Discuss the way forward for Bullet Chatting standardization in W3C.<br />
* Type of session: talk & discussion<br />
* Goals: Help the global web community to better understand Bullet Chatting and the value of its standardization, and looking for teams interested in Bullet Chatting standardization, hoping to get some feedback and support, and get advice about what the W3C workflow. <br />
* Shortname: bulletchat<br />
* Estimated room capacity: small room<br />
<br />
=== Efficient audio/video processing ===<br />
* Proposer: François Daoust / Dominique HazaÍl-Massieux / 02 September 2019<br />
* Email address of proposer: fd@w3.org, dom@w3.org<br />
* Summary: W3C groups (e.g. WebRTC WG, Machine Learning for the Web CG, Audio WG, Media WG, Immersive Web WG) discuss, develop and/or dream about ways to process audio/video streams efficiently. Use cases include barcode reading, face/gesture tracking, emotion analysis, funny hats, background removal or blurring, augmented reality, video overlays, voice effects, or custom codecs. Would it be useful and possible to develop a common mechanism that different APIs could leverage to hook together with streams of media while avoiding useless memory copies? What could such a mechanism look like?<br />
* Type of session: open discussion<br />
* Goals: Look at use cases and at how they can be implemented today, assess possible performance gains if they were implemented with a more efficient mechanism, refine scope for possible work on the topic, and gauge interest among parties.<br />
* Additional speakers/panelists: Rijubrata Bhaumik, Paul Adenot, Peter Thatcher, Joshue O Connor<br />
* Shortname: mediaprocessing<br />
* Estimated room capacity: medium<br />
<br />
=== HTML 3D Element ===<br />
* Proposer: [[User:zyu5|Zhiqiang Yu]] <br />
* Email address: yuzhiqiang5@huawei.com<br />
* Summary: A proposal on HTML 3D element, to bring rich 3D & AR experience to Web with a single line of code. Use cases include on-line shopping, creative advertisement,education, etc. A few demos will be shown as well.<br />
* Type of session: short talk & discussion<br />
* Goals: promote the HTML 3D tag and looking forward to a wider collaboration w/ the community, as well as standardization in W3C.<br />
* shortname: HTML 3D<br />
* Estimated room capacity: medium room<br />
<br />
=== Native GLTF ===<br />
* Proposer: [[User:sushraja| Sushanth Rajasankar]]<br />
* Email address: sushraja@microsoft.com<br />
* Summary: Discuss a proposal for a scene element https://github.com/immersive-web/proposals/issues/52. That allows for native 3d content presentation. Demo Prototype. (Perhaps this can be a part of the previous session "HTML 3D Element").<br />
* Type of session: short talk & discussion<br />
* Goals: Gauge developer interest in adding native support for gltf in the browser and engage with the community.<br />
* ShortName: Native GLTF<br />
* Estimated room capacity: medium room.<br />
<br />
=== Voice assistants - opportunities for standardization? ===<br />
* Proposer: [[User:Philarcher|Phil Archer, GS1]] ([[User talk:Philarcher|talk]]) 09:28, 3 September 2019 (UTC)<br />
* Email address of proposer: phil.archer@gs1.org<br />
* Summary (one-sentence or so): Voice assistants present exciting new methods to interact with the Web but how can/should we develop standards that benefit all stake holders from start ups to tech giants? <br />
* Type of session: Discussion<br />
* Goals: To identify parties most interested in the generic area of voice interaction and to narrow that down to a set of more specific areas of interest. E-commerce? Fact checking? Media streaming? APIs for Skills, More ...<br />
* [optional] shortname: voice<br />
* [optional] Additional speakers/panelists: LĂŠonie Watson, Mark Hakkinen<br />
* [optional] Estimated room capacity: small room<br />
<br />
=== Github tools and Bots to assist Chairing ===<br />
* Proposer: [[User:Adaroseedwards|Ada Rose Cannon]] ([[User talk:Adaroseedwards|talk]]) 10:19, 3 September 2019 (UTC)<br />
* Email address of proposer: ada@ada.is <br />
* Summary: I'm a lazy chair and have created bots and scripts to help me chair, this is to show some of the tools I use to help leverage Github's APIs to help chair. I would also be interested in other tools people use to automate some of their teams.<br />
* Type of session: Presentation + Discussion<br />
* Goals: Share tools used.<br />
* [optional] shortname: groupautomation<br />
* [optional] Estimated room capacity: small room<br />
<br />
=== WebAuthn network transport discussion ===<br />
* Proposer(s): James Barclay, [[User:Nmooney|Nick Mooney]] ([[User talk:Nmooney|talk]]) 17:02, 3 September 2019 (UTC)<br />
* Emails: {jbarclay,nmooney}@duosecurity.com<br />
* Summary: Discuss the development of a new network-based transport as an addition to the WebAuthn specification.<br />
* Type: talk, open discussion<br />
* Goals: motivate the need for a network-based WebAuthn transport, discuss how this might look as part of the specification, discuss phishing resistance and proximity<br />
* Shortname: #webauthnnetwork<br />
* Estimated room capacity: medium<br />
<br />
=== Q&A about DIDs (Decentralized Identifiers) ===<br />
* Proposer: [[User:Drummondreed|Drummond Reed]] ([[User talk:Drummondreed|talk]]) 17:53, 3 September 2019 (UTC)<br />
* Email address of proposer: drummond.reed@evernym.com<br />
* Summary (one-sentence or so): DIDs are a new form of cryptographically-verifiable identifier, and TPAC will host the first meeting of the (still not final) W3C DID WG. This is a chance to learn more about DIDs.<br />
* Type of session: open discussion<br />
* Goals: The primary goal is to answer questions about DIDs and help W3C members understand the market interest in this new type of identifier.<br />
* Shortname: #did<br />
* Additional speakers/panelists: Manu Sporny, Dan Burnett, Christopher Allen<br />
* Estimated room capacity: medium room<br />
<br />
=== UndoManager API ===<br />
* Proposer: [[User:Whsieh|Wenson Hsieh]] ([[User talk:Whsieh|talk]]) 20:28, 3 September 2019 (UTC)<br />
* Email address of proposer: wenson_hsieh@apple.com<br />
* Summary (one-sentence or so): The UndoManager API allows web applications to modify the platform undo stack, and scope undo stacks to elements.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): talk, open discussion<br />
* Goals: Introduce a proposal for the UndoManager API, which allows web applications to modify and inspect the platformâs undo stack. This has implications for all types of web apps, with particular relevance to editing and productivity apps. We hope to establish context for the UndoManager API, demo a prototype of the API, and gain feedback for our proposal.<br />
* Shortname: undomanager<br />
* Additional speakers/panelists: Megan Gardner<br />
* Estimated room capacity: small room<br />
<br />
=== Linked Data Security ===<br />
* Proposer: [[User:Msporny|Manu Sporny]] ([[User talk:Msporny|talk]]) 22:11, 3 September 2019 (UTC)<br />
* Email address of proposer: msporny@digitalbazaar.com<br />
* Summary (one-sentence or so): Should we standardize: RDF Dataset Canonicalization, Linked Data Proofs, Linked Data Signatures, RSA2019Signature, Ed25519Signature, and if so, on what timeline?<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): open discussion<br />
* Goals: Determine if certain Linked Data Security technologies are ready for standardization.<br />
* [optional] ldsec<br />
* [optional] Additional speakers/panelists: Ivan Herman, Gregg Kellogg, Benjamin Young, Robert Sanderson<br />
* [optional] Timing constraint: Don't overlap with DID session<br />
* [optional] Estimated room capacity: small<br />
<br />
=== What is the Future of W3C ===<br />
* Proposer: [[Tantek]] (Mozilla) ([[User:Tantekelik|Tantek Ăelik]] ([[User talk:Tantekelik|talk]]) 22:58, 3 September 2019 (UTC))<br />
* Email address of proposer: tantek@cs.stanford.edu<br />
* Summary: How should W3C evolve to better serve the web community? The AB and AC are discussing changes to its structure, but they need to hear from stakeholders about the mission and the structure designed to achieve it.<br />
* Type of session: open discussion<br />
* shortname: #future<br />
* Timing constraint: prefer Pacific Time Zone friendly time if possible for remote participation<br />
* Estimated room capacity: medium<br />
* Additional speakers/panelists: Michael Champion (Microsoft, possibly remote), Chris Wilson (Google)<br />
* Goals: A discussion to understand the community's level of consensus on fundamental questions:<br />
** Mission â W3Câs traditional mission statement is âlead the web to its full potentialâ. Does the community believe W3Câs basic value proposition need updating, perhaps to focus on some combination of documenting how the web actually works, certifying which products comply with the consensus standards, and focusing on the most pressing challenges to the original vision?<br />
** Leadership â The founding Director is no longer involved with W3Câs day to day operations, but the âDirectorâ has a key role in the process and governance. Would the community be more comfortable with finding another neutral person with considerable expertise who can commit the time to being Director, or delegating tasks such as adjudicating formal objections to some sort of elected council?<br />
** Staffing â What role or roles should the Team prioritize and focus on? Mechanics of consensus building, or technical guidance on solutions?<br />
* Interested:<br />
** [[User:Coralie|Coralie Mercier]] ([[User talk:Coralie|talk]]) 17:31, 4 September 2019 (UTC)<br />
** ...<br />
<br />
=== Web of Things PlugFest ===<br />
* Proposer: [[User:Ashimura|Kazuyuki Ashimura]] ([[User talk:Ashimura|talk]]) 17:21, 4 September 2019 (UTC)<br />
* Email address of proposer: ashimura@w3.org<br />
* Summary: The WoT-IG/WG would like to have its PlugFest demo at 13:30-14:30 to (1) present what kind of demos are included and (2) show actual demos which include various scenarios and combinations of devices/applications for IoT purposes.<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): Presentaton and Demo<br />
* Goals: Show what is done by the WoT WG/IG based on the WoT standards to all the TPAC attendees and encourage people to collaborate with the group (and join the group :). This time we'd like to show several different combinations of devices/applications and scenarios based on the WoT specifications. Please see also the [https://github.com/endouhhc/wot/blob/master/plugfest/2019-tpac-fukuoka/README.md PlugFest preparation page].<br />
* shortname: wot-pf<br />
* Timing constraint: 13:30-14:30<br />
* Estimated room capacity: big room<br />
<br />
=== Introduction to W3C ===<br />
* Proposer: [[User:Plehegar|Philippe Le HĂŠgaret]] ([[User talk:Plehegar|talk]]) 20:12, 4 September 2019 (UTC)<br />
* Email address of proposer: plh@w3.org<br />
* Summary (one-sentence or so): If you're a new Group participant in the W3C, this session will guide you through the W3C labyrinth and allow you to contribute to the Web<br />
* Type of session (e.g.: open discussion, talk, panel, etc.): talk, tutorial, open discussion<br />
* Goals:<br />
* w3c-intro<br />
* Timing constraint: none<br />
* Estimated room capacity: small room</div>Plehegarhttps://www.w3.org/wiki/index.php?title=TPAC/2019/Hackathon&diff=109644TPAC/2019/Hackathon2019-06-25T09:47:34Z<p>Plehegar: /* Participants */</p>
<hr />
<div>On Sunday before TPAC, we are experimenting with a small-scale hackathon for people involved in building tools for the W3C ecosystem, incl:<br />
* spec editing tools<br />
* web platform test and its accompanying data<br />
* implementation status tracking tools<br />
* W3C API and spec status tools<br />
* Other useful data APIs<br />
<br />
== Participants ==<br />
# Dom HM<br />
# Marcos Caceres<br />
# Olivier Yiptong<br />
# François Daoust<br />
# Kagami Rosylight (conditional on funding) <br />
# Sid Vishnoi (conditional on funding)<br />
# Philip Jägenstedt<br />
# Philippe Le Hegaret<br />
# Denis Ah-Kang<br />
# Mike Smith<br />
# Simon Pieters</div>Plehegarhttps://www.w3.org/wiki/index.php?title=DocumentReview&diff=109139DocumentReview2019-05-02T13:50:34Z<p>Plehegar: </p>
<hr />
<div>Getting ''early'' and ''wide'' review of a document is very important yet in practice, it can be challenging. Rather than defining explicit mandatory steps for getting wide and constructive review, this document provides some considerations, guidelines and best practices that groups should follow.<br />
<br />
'''Feedback on this document is welcome, preferably by directly editing this document, by sending email to <code>[mailto:public-openw3c@w3.org public-openw3c@w3.org]</code> ([http://lists.w3.org/Archives/Public/public-openw3c/ archive]), or by tweeting to the [https://twitter.com/@openw3c @openw3c] twitter account.'''<br />
<br />
SeeAlso:<br />
<br />
* [http://www.w3.org/2014/11/getreview/ Tool to Assist with Calls for Specification Review]<br />
* [https://www.w3.org/2019/Process-20190301/ Process Document 2019]<br />
<br />
<br />
== Introduction ==<br />
<br />
Getting early review and feedback is important, especially reviews from those groups that have identified a document as a dependency, and the so-called ''horizontal groups''. It is also important to get review from other stakeholders including Web developers, technology providers and implementers not active in the Working Group, external groups and Standards organisations working on related areas, etc.<br />
<br />
In Process-2019, the focus is on actually getting evidence that wide review has occurred. The considerations, guidelines and Best Practices (BP) in this document should provide reasonable guidance for document review.<br />
<br />
== TL;DR: ==<br />
<br />
When you have published a First Public Working Draft, you should work through available "self-review" materials, and request review of your results, in at least the following areas. "Long enough*" before you request a transition to CR, you should do the same again, identifying substantive specification changes since the first review.<br />
<br />
The meaning of "Long enough*" depends on how many changes there are, and how clearly you have explained them. Pointing to 14 concise points for a small spec means a short time, pointing to 900 diffs from commits and hoping people understand them in a 300 page spec means it will take a '''long''' time to get review. If you have effectively identified issues for review during development, and got feedback on them, the review time will probably be shortened. It also depends how busy the groups are, so planning in advance is useful.<br />
<br />
;Accessibility<br />
:Work through [http://w3c.github.io/apa/fast/checklist.html this questionnaire] then ask [https://www.w3.org/WAI/APA/ APA] for review: [mailto:public-apa@w3.org public-apa@w3.org]<br />
;Architecture<br />
:Ask the [http://www.w3.org/2001/tag/ TAG] for review; see [https://tag.w3.org/workmode/ how to work with the TAG]. If you are developing javascript APIs you may also want to ask [mailto:public-script-coord@w3.org public-script-coord@w3.org], a technical discussion list shared by W3C and ECMA's TC 39.<br />
;Internationalisation<br />
:Work through the [[https://www.w3.org/International/techniques/developing-specs Checklist]], then request [http://www.w3.org/International/ i18n] review by email to [mailto:www-international@w3.org www-international@w3.org] (A public list watched by the Working Group). If for some reason you want a member-confidential review, you can ask on [mailto:member-i18n-core@w3.org member-i18n-core@w3.org] (a member-only list watched by the Working Group).<br />
;Privacy<br />
:Go through [https://www.w3.org/wiki/Privacy/Privacy_Considerations this checklist] and the [https://www.w3.org/TR/security-privacy-questionnaire/ privacy/security checklist], then ask the [http://www.w3.org/Privacy/ Privacy Interest Group for a review: [mailto:public-privacy@w3.org public-privacy@w3.org]<br />
;Security<br />
:Use your results from the [https://www.w3.org/TR/security-privacy-questionnaire/ privacy/security questionnaire] (see privacy), then ask the [http://www.w3.org/Security/wiki/IG Security IG] for review: [mailto:public-web-security@w3.org public-web-security@w3.org]<br />
;Groups listed in your charter<br />
:If there are groups listed in your charter as depending on some specification, you should ask them too.<br />
; General announcement<br />
:Use [mailto:public-review-announce@w3.org public-review-announce@w3.org] for general announcements regarding wide and horizontal reviews<br />
<br />
=== Read on⌠===<br />
You should familiarise yourself with the rest of this document. This section is just a quick reminder for when you are in the middle of doing the work.<br />
<br />
== Considerations and Best Practices ==<br />
<br />
Among the considerations and best practices, regardless of the ''type of review'' (early, thorough wide review, etc.) are:<br />
=== Who to ask for review?===<br />
<br />
* '''Which group(s) should be asked to review a document?''' All group charters should include information about the groups and external liaisons that are interested in particular documents. At a minimum, those groups should be included in all review request for their related document(s). Additionally, it may be appropriate to explicitly seek review from others such as: other Consortium groups; external organizations and SSOs; ''stakeholders'' such as implementers, testing and interop experts, application developers, etc. If a document is explicitly identified as a joint deliverable with another group, it is especially important to make sure that group is included in all review requests.<br />
<br />
* '''Which Horizontal Groups should be asked to request a review?''' This can be a bit tricky because in some cases the set of relevant of ''horizontal groups'' (enumerated below) should be relatively obvious but in other cases it might not be. For example, Working Group Charters often explicitly identify Horizontal Group dependencies, but post-charter development may introduce features that require review by Horizontal Groups not called out in the charter. - SNZ<br />
** '''BP:''' if in doubt, before formally asking a horizontal group to review a document, talk to them informally (f.ex. via e-mail).<br />
<br />
''(comment): I agree that it may not be obvious that a document needs horizontal review, but I tend to take a stronger line: even if you have not identified a ''horizontal group'' dependency, you should always discuss whether a review is necessary or even request a review (saying if you think there are no issues of interest to the given group). --[[User:Aphillip|Addison Phillips]] ([[User talk:Aphillip|talk]])''<br />
<br />
* '''What should be done if it appears a document might be relevant to a [http://www.w3.org/2001/11/StdLiaison.html W3C liaison] but the liaison is not explicitly listed in the group's charter?''' The Chair(s) and Team Contacts should consult with their group, and if there is consensus within the group to contact the liaison, then that external group should be included in all review requests.<br />
** '''BP:''' That group should be included in review requests unless they ask not to be --CMN<br />
<br />
=== When should review be requested? ===<br />
<br />
* '''When is a group ''required'' to seek wide review of a Process-2019 document?''' For a document to enter CR, the group must show the document has had wide review. The requesting group is free to determine the timing for review requests.<br />
<br />
* '''When should reviews by Horizontal Groups be scheduled?''' Horizontal Groups are very often resource limited. This means that they can often only do one review and may have difficulty scheduling that review in a timely way. Secondly, to do a reasonable review, they need a document that is pretty stable, but still flexible enough to allow changes where issues are identified. -SNZ<br />
**'''BP:''' Contact the chair of each relevant Horizontal Group to arrange a suitable time in their schedule to review the document. - SNZ<br />
<br />
* '''What circumstances should trigger a RfC?''' When a new feature is added to a document after its FPWD is published or after the document has already been a target of a wide review, a group should seek wide review of that new feature. <br />
** Other reasons to consider wide review include: some other group expresses keen interest in a document.<br />
<br />
* '''What part of a document should be reviewed and when?''' The general rule of thumb is to get review ''early and often''.<br />
** '''BP:''' Ensure that each section or feature is reviewed when it is considered stable (this enables changes to be made early, which lowers the risk that deployed legacy will impact the possibilities for fixing something).<br />
<br />
=== Making reviews happen ===<br />
* '''Length of the Comment Period.''' The duration for comments (aka ''comment period'') depends on a number of factors including the version of the Process Document being used. As such, consult the Process being used.<br />
** '''BP:''' before a group asks another group to review a document, the requesting group should work with the review group to determine a mutually agreeable review timeline.<br />
<br />
* '''How to initiate a review request.''' Review requests should be sent to the review groups' Public mail list(s).<br />
** '''BP:''' please avoid cross-posting by using Bcc: if necessary.<br />
** '''BP:''' use the RfC template below.<br />
<br />
* '''Announce pre-CR publications on the chairs list.''' The group Chair or W3C staff should announce all pre-CR publications on the [https://lists.w3.org/Archives/Member/chairs/ chairs] list.<br />
<br />
* '''Announce all Requests for Review (f.ex. pre-CR publications) on the <code>[http://lists.w3.org/Archives/Public/public-review-announce/ public-review-announce] e-mail list</code>'''. This announcement may be made by a group Chair, Consortium Staff, Editor or any other designated member of a group.<br />
** '''BP:''' use the RfC template below.<br />
<br />
* '''Use Public e-mail lists for review feedback.''' The requesting group's Public mail list should be used for review feedback.<br />
** '''BP:''' use the requesting group's main Public mail list for comments and do not use (nor create) a list whose sole purpose is for comments.<br />
<br />
* '''How can a group get acknowledgement that some person and/or group actually reviewed a document?''' Naturally, this isn't an issue if the reviewing group and/or individuals in the reviewing group actually provides review comments. However, in some cases, this can be somewhat difficult to determine and achieve (f.ex the reviewing group is small, the overlap in scope is minimal, etc.). <br />
** '''BP:''' when asking for review, explicitly ask the reviewing group to submit all feedback, even if the feedback is something like "I read it and have no comments".<br />
<br />
== Request for Comments (RfC) Template ==<br />
<br />
See the [http://www.w3.org/2014/11/getreview/ tool to assist with calls for specification review].<br />
<br />
=== General Information ===<br />
<br />
A RfC should include the following general information:<br />
<br />
* Name of the group seeking comments.<br />
<br />
* Deadline for comments.<br />
<br />
* <code>Subject:</code> header: include the maturity level, name of the document and document maturity level of the document<br />
** '''BP''': <code>Subject: RfC: FPWD of ''Name of Spec''; deadline MMM DD</code>.<br />
<br />
* Mail list for comments; include the mailto: address plus a link to the Public mail list archive<br />
** '''BP''': avoid cross-posting to multiple lists (and if this must be done, use Bcc:), except for the i18n WG, which needs to track issues on its technical list as well. (i18n WG members cannot subscribe to all the lists of the groups they review specs for.)<br />
<br />
* Alternate instructions for providing commentary ''(if needed)''. Some groups use bugzilla or github as a means of communication and for tracking issues. --[[User:Aphillip|Addison Phillips]] ([[User talk:Aphillip|talk]]) If your main or preferred tracking location is a database, make that clear in the SOD, since moving and tracking comments between mail threads and databases can waste time for both the reviewer and the reviewed group.<br />
<br />
* <code>Reply-to:</code> header: set the <code>Reply-to:</code> header to the mail list where all comments should be sent<br />
<br />
* State that all review be acknowledged, even if a reviewer or group has reviewed the document and has "no comments".<br />
<br />
=== Information for Each Document ===<br />
<br />
For each document that will be reviewed, provide at least:<br />
<br />
* Document title<br />
<br />
* URL<br />
** '''BP''': the contents of the document should be stable (i.e. not changed) during the review period. <br />
** '''BP''': if the contents of the document might change during the review, identify the specific section(s) that might change; or consider postponing the review until after those sections are stable.<br />
<br />
* Maturity level: FPWD, "pre-CR", CR, ...<br />
<br />
* Scope of the review: this can be the entire document, specific sections, specific issues, etc.<br />
** '''BP''': Identify the specific sections of the document that are newly stabilized, as well as those already considered stable. This allows reviewers who follow "at a distance" to focus on what's new, and allows new reviewers to focus on things that are ready for review, instead of providing a lot of comments on sections that are likely to shift.<br />
** '''BP''': Specifications should include information about stability and known implementation on a "section by section" basis.<br />
<br />
* If a review was previously requested, include the URL of a diff, using the previous version of the document as the diff's reference/base.<br />
** '''BP''': use [http://services.w3.org/htmldiff W3C HTML Diff service]<br />
** '''BP''': also provide a human-authored summary of the changes.<br />
<br />
=== Example Request for Comments ===<br />
<br />
Here are some example RfCs:<br />
<br />
* [http://lists.w3.org/Archives/Public/public-html/2014Sep/0099.html TTML Text and Imaging ... preCR]<br />
* [http://lists.w3.org/Archives/Public/public-review-announce/2014Nov/0002.html Pointer Events LCWD]<br />
<br />
== Horizontal Groups ==<br />
<br />
The consortium's so-called ''Horizontal Groups'' are groups that include review and coordination functions in their charter. Typically, these groups consist of individuals that can provide advice and guidance (to other groups) regarding their domain expertise.<br />
<br />
Groups with a horizontal review function, including their mail list are (alphabetical order):<br />
<br />
* [https://www.w3.org/WAI/APA/ Accessible Platform Architectures Working Group]; [https://lists.w3.org/Archives/Public/public-apa/ public-apa]; [https://www.w3.org/WAI/APA/wiki/Spec_Review APA Spec Review tracking]<br />
* [http://www.w3.org/International/ Internationalization Working Group]; [http://lists.w3.org/Archives/Public/www-international/ www-international] Reviews by Internationalization generally also involve the [http://www.w3.org/International/ig Interest Group], but are arranged through the WG.<br />
* [http://www.w3.org/Privacy/ Privacy Interest Group]; [http://lists.w3.org/Archives/Public/public-privacy/ public-privacy]<br />
* [http://www.w3.org/2001/tag/ Technical Architecture Group (TAG)]; [http://lists.w3.org/Archives/Public/www-tag/ www-tag]<br />
* [http://www.w3.org/2008/webapps/ Web API Consistency and Web IDL Conformance]; [http://lists.w3.org/Archives/Public/public-script-coord/ public-script-coord]; (this is a Web Platform WG list that liaises with ECMA's TC-39)<br />
* [http://www.w3.org/WAI/IG/ Web Accessibility Interest Group]; [http://lists.w3.org/Archives/Public/w3c-wai-ig/ w3c-wai-ig]<br />
* [http://www.w3.org/Security/wiki/IG Web Security Interest Group]; [http://lists.w3.org/Archives/Public/public-web-security/ public-web-security]<br />
<br />
=== Review Resources ===<br />
<br />
* Internationalization:<br />
** [https://www.w3.org/International/review-request I18n Request a review]<br />
** [http://w3c.github.io/i18n-activity/reviews/shortchecklist Short i18n review checklist]<br />
** [https://www.w3.org/International/techniques/developing-specs Expanding collapsing detailed checklist], generated from [https://w3c.github.io/bp-i18n-specdev/ ''Internationalization Best Practices for Spec Developers'']<br />
* Security/Privacy:<br />
** [https://www.w3.org/TR/security-privacy-questionnaire/ ''Self-Review Questionnaire: Security and Privacy''; Mike West]<br />
** [http://www.rfc-editor.org/rfc/rfc3552.txt Guidelines for Writing RFC Text on Security Considerations (RFC3552)]<br />
** [https://w3c.github.io/fingerprinting-guidance/ Mitigating Browser Fingerprinting in Web Specifications]<br />
** [http://gregnorc.github.io/ping-privacy-questions/ Ping-privacy-questions]<br />
** [https://yrlesru.github.io/SPA/ ''Specification Privacy Assessment (SPA) (Creating Privacy Considerations for W3C Technical Specifications)''; Frank Dawson]<br />
* Technical Architecture:<br />
** [https://www.w3.org/2001/tag/doc/webcomponents-design-guidelines/ Guidelines for creating web platform compatible components]<br />
** [https://www.w3.org/2001/tag/doc/promises-guide Writing Promise-Using Specifications]<br />
** [https://w3ctag.github.io/design-principles/ Client-side API Design Principles]<br />
** [https://www.w3.org/2001/tag/doc/capability-urls/ Good Practices for Capability URLs]<br />
** [https://github.com/w3ctag/spec-reviews TAG Repository for reviews]<br />
* Web Accessibility:<br />
** [http://w3c.github.io/apa/fast/checklist.html Framework for Accessibility in the Specification of Technologies Checklist; APA WG]<br />
** [https://www.w3.org/TR/media-accessibility-reqs/ Media Accessibility User Requirements; PFWG]<br />
<br />
== FAQ ==<br />
<br />
* '''Q: When is the best time to seek ''early'' review?'''<br />
** A: For a number factors (including document maturity, implementation status, etc.), there is no ''best time'' that applies to ''all'' documents. However, for most documents, after a ''First Public Working Draft'' is published is generally a good time to seek review of a specification.<br />
<br />
* '''Q: Is some type of ''security'' and/or ''privacy'' review mandatory before a ''First Public Working Draft'' is published?'''<br />
** A: Strictly speaking, the answer is No. However, getting early review for documents with features that might have security and/or privacy implications is '''strongly encouraged'''. See the [https://www.w3.org/wiki/DocumentReview#Horizontal_Groups Horizontal Groups] section below for information about security and privacy groups that can provide review and related review resources. <br />
<br />
* '''Q: Does a group need to prove its documents have had wide review before proceeding to CR?'''<br />
** A: The answer is yes, since Process-2019.<br />
<br />
* '''Q: How does a group prove its documents have had wide review before proceeding to CR?'''<br />
** A: See [http://lists.w3.org/Archives/Public/public-w3process/2014Oct/0133.html How to work with (experiment with) Wide Review] -SNZ<br />
** A: Keep a Disposition of Comments (DoC) Document that shows review comments and acknowledgements that have been received. It is the distribution of the reviewers that shows the review has been wide.-SNZ<br />
** A: Ask the W3C Team if your proposed approach is likely to meet the requirements. -SNZ<br />
<br />
* '''Q: Is there such a thing as too many reviews?'''<br />
** A: Not really<br />
<br />
* '''Q: Is it possible to make too many requests for review?'''<br />
** A: unfortunately, yes there is. Multiple requests for reviews can quickly result in a situation of diminishing returns. To help address this, subsequent review requests should clearly identify the exact differences between the last review and current review.<br />
** A: This is also the reason that the Process clearly suggests there should be (TR) Working Drafts published when there are "significant changes that would benefit from review beyond the Working Group", rather than every day or only twice in the life of a specâŚ<br />
** A: TR Working Drafts are also useful for reviews since they provide a dated snapshot which can be recovered when the review comments are being discussed. Trying to discuss review comments against a document which has changed out of all recognition can be a frustrating and inefficient experience.<br />
<br />
== Issues ==<br />
<br />
* <strike>'''Is ''pre-CR'' the ''best'' term to describe a Process-2014 snapshot that precedes CR or is there a better term?'''<br />
** Proposals: 2014-LC, 2014-Snapshot, pre-CR snapshot, 2014-Review Doc, pre-CR Review Doc, ...<br />
** Proposal: Don't do this in order to demonstrate "wide review". A "Last call" for a document that has already been reviewed in development is appropriate. Waiting until you think the document is finished to ask for review is a bad idea.</strike> ''This issue has become moot with the passing of time.''<br />
<br />
* <strike>'''How can a group or individual be automatically notified when a document has been published at one of the transitions that could/should initiate the start of an early or wide review?''' For Process-2005 documents, the transitions of interest are: FPWD, pre-CR, and CR.</strike> ''This Issue was resolved via the creation of the <code>[http://lists.w3.org/Archives/Public/public-review-announce public-review-announce]</code> e-mail list.''<br />
<br />
* '''For all processes''' Working Drafts should be relevant for review - and should identify which parts are new or newly stabilized or changed, to facilitate '''timely''' review.<br />
** Potential solution: when a document is published on /TR, announce its publication on a Public mail list. See a related [http://lists.w3.org/Archives/Public/public-w3process/2014Oct/0102.html Call for Consensus] to create such a list, deadline for comments is October 15].<br />
<br />
== Terminology and Abbreviations ==<br />
<br />
* '''pre-CR''' - This is a version of a Working Draft that is created to get wide review.<br />
** note that this is a bad way to get review. In general, features should be reviewed as they are developed. Waiting for a "Last Call" for most review means that when reviews suggest changes it is far harder to make them, due to a commonly observed and logical reluctance to break deployed systems or content. [[User:Charles|Charles McCathie Nevile]] ([[User talk:Charles|talk]]) 11:18, 13 October 2014 (UTC)<br />
<br />
* '''requesting group''' - a group that is requesting a review <br />
<br />
Abbreviations:<br />
<br />
* BP = Best Practices<br />
* CR = Candidate Recommendation<br />
* RfC = Request for Comments (aka Review Request)<br />
* [http://www.w3.org/TR/ TR] = Technical Report, i.e. a formal W3C publication.<br />
* WD = Working Draft<br />
<br />
== Enhancement Requests ==<br />
<br />
* See the [https://www.w3.org/wiki/Dashboard#Document_Review_Dashboard Document Review Dashboard] document for information about creating a dashboard type service to facilitate document reviews.</div>Plehegarhttps://www.w3.org/wiki/index.php?title=DocumentReview&diff=109138DocumentReview2019-05-02T13:47:29Z<p>Plehegar: /* TL;DR: */</p>
<hr />
<div>Getting ''early'' and ''wide'' review of a document is very important yet in practice, it can be challenging. Rather than defining explicit mandatory steps for getting wide and constructive review, this document provides some considerations, guidelines and best practices that groups should follow.<br />
<br />
'''Feedback on this document is welcome, preferably by directly editing this document, by sending email to <code>[mailto:public-openw3c@w3.org public-openw3c@w3.org]</code> ([http://lists.w3.org/Archives/Public/public-openw3c/ archive]), or by tweeting to the [https://twitter.com/@openw3c @openw3c] twitter account.'''<br />
<br />
SeeAlso:<br />
<br />
* [http://www.w3.org/2014/11/getreview/ Tool to Assist with Calls for Specification Review]<br />
* [https://www.w3.org/2019/Process-20190301/ Process Document 2019]<br />
<br />
<br />
== Introduction ==<br />
<br />
Getting early review and feedback is important, especially reviews from those groups that have identified a document as a dependency, and the so-called ''horizontal groups''. It is also important to get review from other stakeholders including Web developers, technology providers and implementers not active in the Working Group, external groups and Standards organisations working on related areas, etc.<br />
<br />
In Process-2019, the focus is on actually getting evidence that wide review has occurred. The considerations, guidelines and Best Practices (BP) in this document should provide reasonable guidance for document review.<br />
<br />
== TL;DR: ==<br />
<br />
When you have published a First Public Working Draft, you should work through available "self-review" materials, and request review of your results, in at least the following areas. "Long enough*" before you request a transition to CR, you should do the same again, identifying substantive specification changes since the first review.<br />
<br />
The meaning of "Long enough*" depends on how many changes there are, and how clearly you have explained them. Pointing to 14 concise points for a small spec means a short time, pointing to 900 diffs from commits and hoping people understand them in a 300 page spec means it will take a '''long''' time to get review. If you have effectively identified issues for review during development, and got feedback on them, the review time will probably be shortened. It also depends how busy the groups are, so planning in advance is useful.<br />
<br />
;Accessibility<br />
:Work through [http://w3c.github.io/apa/fast/checklist.html this questionnaire] then ask [https://www.w3.org/WAI/APA/ APA] for review: [mailto:public-apa@w3.org public-apa@w3.org]<br />
;Architecture<br />
:Ask the [http://www.w3.org/2001/tag/ TAG] for review; see [https://tag.w3.org/workmode/ how to work with the TAG]. If you are developing javascript APIs you may also want to ask [mailto:public-script-coord@w3.org public-script-coord@w3.org], a technical discussion list shared by W3C and ECMA's TC 39.<br />
;Internationalisation<br />
:Work through the [[https://www.w3.org/International/techniques/developing-specs Checklist]], then request [http://www.w3.org/International/ i18n] review by email to [mailto:www-international@w3.org www-international@w3.org] (A public list watched by the Working Group). If for some reason you want a member-confidential review, you can ask on [mailto:member-i18n-core@w3.org member-i18n-core@w3.org] (a member-only list watched by the Working Group).<br />
;Privacy<br />
:Go through [https://www.w3.org/wiki/Privacy/Privacy_Considerations this checklist] and the [https://www.w3.org/TR/security-privacy-questionnaire/ privacy/security checklist], then ask the [http://www.w3.org/Privacy/ Privacy Interest Group for a review: [mailto:public-privacy@w3.org public-privacy@w3.org]<br />
;Security<br />
:Use your results from the [https://www.w3.org/TR/security-privacy-questionnaire/ privacy/security questionnaire] (see privacy), then ask the [http://www.w3.org/Security/wiki/IG Security IG] for review: [mailto:public-web-security@w3.org public-web-security@w3.org]<br />
;Groups listed in your charter<br />
:If there are groups listed in your charter as depending on some specification, you should ask them too.<br />
; General announcement<br />
:Use [mailto:public-review-announce@w3.org public-review-announce@w3.org] for general announcements regarding wide and horizontal reviews<br />
<br />
=== Read on⌠===<br />
You should familiarise yourself with the rest of this document. This section is just a quick reminder for when you are in the middle of doing the work.<br />
<br />
== Considerations and Best Practices ==<br />
<br />
Among the considerations and best practices, regardless of the ''type of review'' (early, thorough wide review, etc.) are:<br />
=== Who to ask for review?===<br />
<br />
* '''Which group(s) should be asked to review a document?''' All group charters should include information about the groups and external liaisons that are interested in particular documents. At a minimum, those groups should be included in all review request for their related document(s). Additionally, it may be appropriate to explicitly seek review from others such as: other Consortium groups; external organizations and SSOs; ''stakeholders'' such as implementers, testing and interop experts, application developers, etc. If a document is explicitly identified as a joint deliverable with another group, it is especially important to make sure that group is included in all review requests.<br />
<br />
* '''Which Horizontal Groups should be asked to request a review?''' This can be a bit tricky because in some cases the set of relevant of ''horizontal groups'' (enumerated below) should be relatively obvious but in other cases it might not be. For example, Working Group Charters often explicitly identify Horizontal Group dependencies, but post-charter development may introduce features that require review by Horizontal Groups not called out in the charter. - SNZ<br />
** '''BP:''' if in doubt, before formally asking a horizontal group to review a document, talk to them informally (f.ex. via e-mail).<br />
<br />
''(comment): I agree that it may not be obvious that a document needs horizontal review, but I tend to take a stronger line: even if you have not identified a ''horizontal group'' dependency, you should always discuss whether a review is necessary or even request a review (saying if you think there are no issues of interest to the given group). --[[User:Aphillip|Addison Phillips]] ([[User talk:Aphillip|talk]])''<br />
<br />
* '''What should be done if it appears a document might be relevant to a [http://www.w3.org/2001/11/StdLiaison.html W3C liaison] but the liaison is not explicitly listed in the group's charter?''' The Chair(s) and Team Contacts should consult with their group, and if there is consensus within the group to contact the liaison, then that external group should be included in all review requests.<br />
** '''BP:''' That group should be included in review requests unless they ask not to be --CMN<br />
<br />
=== When should review be requested? ===<br />
<br />
* '''When is a group ''required'' to seek wide review of a Process-2019 document?''' For a document to enter CR, the group must show the document has had wide review. The requesting group is free to determine the timing for review requests.<br />
<br />
* '''When should reviews by Horizontal Groups be scheduled?''' Horizontal Groups are very often resource limited. This means that they can often only do one review and may have difficulty scheduling that review in a timely way. Secondly, to do a reasonable review, they need a document that is pretty stable, but still flexible enough to allow changes where issues are identified. -SNZ<br />
**'''BP:''' Contact the chair of each relevant Horizontal Group to arrange a suitable time in their schedule to review the document. - SNZ<br />
<br />
* '''What circumstances should trigger a RfC?''' When a new feature is added to a document after its FPWD is published or after the document has already been a target of a wide review, a group should seek wide review of that new feature. <br />
** Other reasons to consider wide review include: some other group expresses keen interest in a document.<br />
<br />
* '''What part of a document should be reviewed and when?''' The general rule of thumb is to get review ''early and often''.<br />
** '''BP:''' Ensure that each section or feature is reviewed when it is considered stable (this enables changes to be made early, which lowers the risk that deployed legacy will impact the possibilities for fixing something).<br />
<br />
=== Making reviews happen ===<br />
* '''Length of the Comment Period.''' The duration for comments (aka ''comment period'') depends on a number of factors including the version of the Process Document being used. As such, consult the Process being used.<br />
** '''BP:''' before a group asks another group to review a document, the requesting group should work with the review group to determine a mutually agreeable review timeline.<br />
<br />
* '''How to initiate a review request.''' Review requests should be sent to the review groups' Public mail list(s).<br />
** '''BP:''' please avoid cross-posting by using Bcc: if necessary.<br />
** '''BP:''' use the RfC template below.<br />
<br />
* '''Announce LCWD and pre-CR publications on the chairs list.''' The group Chair or W3C staff should announce all LCWD and pre-CR publications on the [https://lists.w3.org/Archives/Member/chairs/ chairs] list.<br />
<br />
* '''Announce all Requests for Review (f.ex. LCWD and pre-CR publications) on the <code>[http://lists.w3.org/Archives/Public/public-review-announce/ public-review-announce] e-mail list</code>'''. This announcement may be made by a group Chair, Consortium Staff, Editor or any other designated member of a group.<br />
** '''BP:''' use the RfC template below.<br />
<br />
* '''Use Public e-mail lists for review feedback.''' The requesting group's Public mail list should be used for review feedback.<br />
** '''BP:''' use the requesting group's main Public mail list for comments and do not use (nor create) a list whose sole purpose is for comments.<br />
<br />
* '''How can a group get acknowledgement that some person and/or group actually reviewed a document?''' Naturally, this isn't an issue if the reviewing group and/or individuals in the reviewing group actually provides review comments. However, in some cases, this can be somewhat difficult to determine and achieve (f.ex the reviewing group is small, the overlap in scope is minimal, etc.). <br />
** '''BP:''' when asking for review, explicitly ask the reviewing group to submit all feedback, even if the feedback is something like "I read it and have no comments".<br />
<br />
== Request for Comments (RfC) Template ==<br />
<br />
See the [http://www.w3.org/2014/11/getreview/ tool to assist with calls for specification review].<br />
<br />
=== General Information ===<br />
<br />
A RfC should include the following general information:<br />
<br />
* Name of the group seeking comments.<br />
<br />
* Deadline for comments.<br />
<br />
* <code>Subject:</code> header: include the maturity level, name of the document and document maturity level of the document<br />
** '''BP''': <code>Subject: RfC: FPWD of ''Name of Spec''; deadline MMM DD</code>.<br />
<br />
* Mail list for comments; include the mailto: address plus a link to the Public mail list archive<br />
** '''BP''': avoid cross-posting to multiple lists (and if this must be done, use Bcc:), except for the i18n WG, which needs to track issues on its technical list as well. (i18n WG members cannot subscribe to all the lists of the groups they review specs for.)<br />
<br />
* Alternate instructions for providing commentary ''(if needed)''. Some groups use bugzilla or github as a means of communication and for tracking issues. --[[User:Aphillip|Addison Phillips]] ([[User talk:Aphillip|talk]]) If your main or preferred tracking location is a database, make that clear in the SOD, since moving and tracking comments between mail threads and databases can waste time for both the reviewer and the reviewed group.<br />
<br />
* <code>Reply-to:</code> header: set the <code>Reply-to:</code> header to the mail list where all comments should be sent<br />
<br />
* State that all review be acknowledged, even if a reviewer or group has reviewed the document and has "no comments".<br />
<br />
=== Information for Each Document ===<br />
<br />
For each document that will be reviewed, provide at least:<br />
<br />
* Document title<br />
<br />
* URL<br />
** '''BP''': the contents of the document should be stable (i.e. not changed) during the review period. <br />
** '''BP''': if the contents of the document might change during the review, identify the specific section(s) that might change; or consider postponing the review until after those sections are stable.<br />
<br />
* Maturity level: FPWD, "pre-CR", CR, ...<br />
<br />
* Scope of the review: this can be the entire document, specific sections, specific issues, etc.<br />
** '''BP''': Identify the specific sections of the document that are newly stabilized, as well as those already considered stable. This allows reviewers who follow "at a distance" to focus on what's new, and allows new reviewers to focus on things that are ready for review, instead of providing a lot of comments on sections that are likely to shift.<br />
** '''BP''': Specifications should include information about stability and known implementation on a "section by section" basis.<br />
<br />
* If a review was previously requested, include the URL of a diff, using the previous version of the document as the diff's reference/base.<br />
** '''BP''': use [http://services.w3.org/htmldiff W3C HTML Diff service]<br />
** '''BP''': also provide a human-authored summary of the changes.<br />
<br />
=== Example Request for Comments ===<br />
<br />
Here are some example RfCs:<br />
<br />
* [http://lists.w3.org/Archives/Public/public-html/2014Sep/0099.html TTML Text and Imaging ... preCR]<br />
* [http://lists.w3.org/Archives/Public/public-review-announce/2014Nov/0002.html Pointer Events LCWD]<br />
<br />
== Horizontal Groups ==<br />
<br />
The consortium's so-called ''Horizontal Groups'' are groups that include review and coordination functions in their charter. Typically, these groups consist of individuals that can provide advice and guidance (to other groups) regarding their domain expertise.<br />
<br />
Groups with a horizontal review function, including their mail list are (alphabetical order):<br />
<br />
* [https://www.w3.org/WAI/APA/ Accessible Platform Architectures Working Group]; [https://lists.w3.org/Archives/Public/public-apa/ public-apa]; [https://www.w3.org/WAI/APA/wiki/Spec_Review APA Spec Review tracking]<br />
* [http://www.w3.org/International/ Internationalization Working Group]; [http://lists.w3.org/Archives/Public/www-international/ www-international] Reviews by Internationalization generally also involve the [http://www.w3.org/International/ig Interest Group], but are arranged through the WG.<br />
* [http://www.w3.org/Privacy/ Privacy Interest Group]; [http://lists.w3.org/Archives/Public/public-privacy/ public-privacy]<br />
* [http://www.w3.org/2001/tag/ Technical Architecture Group (TAG)]; [http://lists.w3.org/Archives/Public/www-tag/ www-tag]<br />
* [http://www.w3.org/2008/webapps/ Web API Consistency and Web IDL Conformance]; [http://lists.w3.org/Archives/Public/public-script-coord/ public-script-coord]; (this is a Web Platform WG list that liaises with ECMA's TC-39)<br />
* [http://www.w3.org/WAI/IG/ Web Accessibility Interest Group]; [http://lists.w3.org/Archives/Public/w3c-wai-ig/ w3c-wai-ig]<br />
* [http://www.w3.org/Security/wiki/IG Web Security Interest Group]; [http://lists.w3.org/Archives/Public/public-web-security/ public-web-security]<br />
<br />
=== Review Resources ===<br />
<br />
* Internationalization:<br />
** [https://www.w3.org/International/review-request I18n Request a review]<br />
** [http://w3c.github.io/i18n-activity/reviews/shortchecklist Short i18n review checklist]<br />
** [https://www.w3.org/International/techniques/developing-specs Expanding collapsing detailed checklist], generated from [https://w3c.github.io/bp-i18n-specdev/ ''Internationalization Best Practices for Spec Developers'']<br />
* Security/Privacy:<br />
** [https://www.w3.org/TR/security-privacy-questionnaire/ ''Self-Review Questionnaire: Security and Privacy''; Mike West]<br />
** [http://www.rfc-editor.org/rfc/rfc3552.txt Guidelines for Writing RFC Text on Security Considerations (RFC3552)]<br />
** [https://w3c.github.io/fingerprinting-guidance/ Mitigating Browser Fingerprinting in Web Specifications]<br />
** [http://gregnorc.github.io/ping-privacy-questions/ Ping-privacy-questions]<br />
** [https://yrlesru.github.io/SPA/ ''Specification Privacy Assessment (SPA) (Creating Privacy Considerations for W3C Technical Specifications)''; Frank Dawson]<br />
* Technical Architecture:<br />
** [https://www.w3.org/2001/tag/doc/webcomponents-design-guidelines/ Guidelines for creating web platform compatible components]<br />
** [https://www.w3.org/2001/tag/doc/promises-guide Writing Promise-Using Specifications]<br />
** [https://w3ctag.github.io/design-principles/ Client-side API Design Principles]<br />
** [https://www.w3.org/2001/tag/doc/capability-urls/ Good Practices for Capability URLs]<br />
** [https://github.com/w3ctag/spec-reviews TAG Repository for reviews]<br />
* Web Accessibility:<br />
** [http://w3c.github.io/apa/fast/checklist.html Framework for Accessibility in the Specification of Technologies Checklist; APA WG]<br />
** [https://www.w3.org/TR/media-accessibility-reqs/ Media Accessibility User Requirements; PFWG]<br />
<br />
== FAQ ==<br />
<br />
* '''Q: When is the best time to seek ''early'' review?'''<br />
** A: For a number factors (including document maturity, implementation status, etc.), there is no ''best time'' that applies to ''all'' documents. However, for most documents, after a ''First Public Working Draft'' is published is generally a good time to seek review of a specification.<br />
<br />
* '''Q: Is some type of ''security'' and/or ''privacy'' review mandatory before a ''First Public Working Draft'' is published?'''<br />
** A: Strictly speaking, the answer is No. However, getting early review for documents with features that might have security and/or privacy implications is '''strongly encouraged'''. See the [https://www.w3.org/wiki/DocumentReview#Horizontal_Groups Horizontal Groups] section below for information about security and privacy groups that can provide review and related review resources. <br />
<br />
* '''Q: Does a group need to prove its documents have had wide review before proceeding to CR?'''<br />
** A: The answer is yes, since Process-2019.<br />
<br />
* '''Q: How does a group prove its documents have had wide review before proceeding to CR?'''<br />
** A: See [http://lists.w3.org/Archives/Public/public-w3process/2014Oct/0133.html How to work with (experiment with) Wide Review] -SNZ<br />
** A: Keep a Disposition of Comments (DoC) Document that shows review comments and acknowledgements that have been received. It is the distribution of the reviewers that shows the review has been wide.-SNZ<br />
** A: Ask the W3C Team if your proposed approach is likely to meet the requirements. -SNZ<br />
<br />
* '''Q: Is there such a thing as too many reviews?'''<br />
** A: Not really<br />
<br />
* '''Q: Is it possible to make too many requests for review?'''<br />
** A: unfortunately, yes there is. Multiple requests for reviews can quickly result in a situation of diminishing returns. To help address this, subsequent review requests should clearly identify the exact differences between the last review and current review.<br />
** A: This is also the reason that the Process clearly suggests there should be (TR) Working Drafts published when there are "significant changes that would benefit from review beyond the Working Group", rather than every day or only twice in the life of a specâŚ<br />
** A: TR Working Drafts are also useful for reviews since they provide a dated snapshot which can be recovered when the review comments are being discussed. Trying to discuss review comments against a document which has changed out of all recognition can be a frustrating and inefficient experience.<br />
<br />
== Issues ==<br />
<br />
* <strike>'''Is ''pre-CR'' the ''best'' term to describe a Process-2014 snapshot that precedes CR or is there a better term?'''<br />
** Proposals: 2014-LC, 2014-Snapshot, pre-CR snapshot, 2014-Review Doc, pre-CR Review Doc, ...<br />
** Proposal: Don't do this in order to demonstrate "wide review". A "Last call" for a document that has already been reviewed in development is appropriate. Waiting until you think the document is finished to ask for review is a bad idea.</strike> ''This issue has become moot with the passing of time.''<br />
<br />
* <strike>'''How can a group or individual be automatically notified when a document has been published at one of the transitions that could/should initiate the start of an early or wide review?''' For Process-2005 documents, the transitions of interest are FPWD, LCWD and CR and for Proc-Doc-2015 documents the transitions of interest are: FPWD, pre-CR, and CR.</strike> ''This Issue was resolved via the creation of the <code>[http://lists.w3.org/Archives/Public/public-review-announce public-review-announce]</code> e-mail list.''<br />
<br />
* '''For all processes''' Working Drafts should be relevant for review - and should identify which parts are new or newly stabilized or changed, to facilitate '''timely''' review.<br />
** Potential solution: when a document is published on /TR, announce its publication on a Public mail list. See a related [http://lists.w3.org/Archives/Public/public-w3process/2014Oct/0102.html Call for Consensus] to create such a list, deadline for comments is October 15].<br />
<br />
== Terminology and Abbreviations ==<br />
<br />
* '''pre-CR''' - This is a version of a Working Draft that is created to get wide review.<br />
** note that this is a bad way to get review. In general, features should be reviewed as they are developed. Waiting for a "Last Call" for most review means that when reviews suggest changes it is far harder to make them, due to a commonly observed and logical reluctance to break deployed systems or content. [[User:Charles|Charles McCathie Nevile]] ([[User talk:Charles|talk]]) 11:18, 13 October 2014 (UTC)<br />
<br />
* '''requesting group''' - a group that is requesting a review <br />
<br />
Abbreviations:<br />
<br />
* BP = Best Practices<br />
* CR = Candidate Recommendation<br />
* RfC = Request for Comments (aka Review Request)<br />
* [http://www.w3.org/TR/ TR] = Technical Report, i.e. a formal W3C publication.<br />
* WD = Working Draft<br />
<br />
== Enhancement Requests ==<br />
<br />
* See the [https://www.w3.org/wiki/Dashboard#Document_Review_Dashboard Document Review Dashboard] document for information about creating a dashboard type service to facilitate document reviews.</div>Plehegarhttps://www.w3.org/wiki/index.php?title=DocumentReview&diff=109137DocumentReview2019-05-02T13:45:45Z<p>Plehegar: /* Information for Each Document */</p>
<hr />
<div>Getting ''early'' and ''wide'' review of a document is very important yet in practice, it can be challenging. Rather than defining explicit mandatory steps for getting wide and constructive review, this document provides some considerations, guidelines and best practices that groups should follow.<br />
<br />
'''Feedback on this document is welcome, preferably by directly editing this document, by sending email to <code>[mailto:public-openw3c@w3.org public-openw3c@w3.org]</code> ([http://lists.w3.org/Archives/Public/public-openw3c/ archive]), or by tweeting to the [https://twitter.com/@openw3c @openw3c] twitter account.'''<br />
<br />
SeeAlso:<br />
<br />
* [http://www.w3.org/2014/11/getreview/ Tool to Assist with Calls for Specification Review]<br />
* [https://www.w3.org/2019/Process-20190301/ Process Document 2019]<br />
<br />
<br />
== Introduction ==<br />
<br />
Getting early review and feedback is important, especially reviews from those groups that have identified a document as a dependency, and the so-called ''horizontal groups''. It is also important to get review from other stakeholders including Web developers, technology providers and implementers not active in the Working Group, external groups and Standards organisations working on related areas, etc.<br />
<br />
In Process-2019, the focus is on actually getting evidence that wide review has occurred. The considerations, guidelines and Best Practices (BP) in this document should provide reasonable guidance for document review.<br />
<br />
== TL;DR: ==<br />
<br />
When you have published a First Public Working Draft, you should work through available "self-review" materials, and request review of your results, in at least the following areas. "Long enough*" before you request a transition to CR, you should do the same again, identifying substantive specification changes since the first review.<br />
<br />
The meaning of "Long enough*" depends on how many changes there are, and how clearly you have explained them. Pointing to 14 concise points for a small spec means a short time, pointing to 900 diffs from commits and hoping people understand them in a 300 page spec means it will take a '''long''' time to get review. If you have effectively identified issues for review during development, and got feedback on them, the review time will probably be shortened. It also depends how busy the groups are, so planning in advance is useful.<br />
<br />
;Accessibility<br />
:Work through [http://w3c.github.io/apa/fast/checklist.html this questionnaire] then ask [https://www.w3.org/WAI/APA/ APA] for review: [mailto:public-apa@w3.org public-apa@w3.org]<br />
;Architecture<br />
:Ask the [http://www.w3.org/2001/tag/ TAG] for review; see [https://tag.w3.org/workmode/ how to work with the TAG]. If you are developing javascript APIs you may also want to ask [mailto:public-script-coord@w3.org public-script-coord@w3.org], a technical discussion list shared by W3C and ECMA's TC 39.<br />
;Internationalisation<br />
:Work through the [[https://www.w3.org/International/techniques/developing-specs Checklist]], then request [http://www.w3.org/International/ i18n] review by email to [mailto:www-international@w3.org www-international@w3.org] (A public list watched by the Working Group). If for some reason you want a member-confidential review, you can ask on [mailto:member-i18n-core@w3.org member-i18n-core@w3.org] (a member-only list watched by the Working Group).<br />
;Privacy<br />
:Go through [https://www.w3.org/wiki/Privacy/Privacy_Considerations this checklist] and the [https://www.w3.org/TR/security-privacy-questionnaire/ privacy/security checklist], then ask the [http://www.w3.org/Privacy/ Privacy Interest Group for a review: [mailto:public-privacy@w3.org public-privacy@w3.org]<br />
;Security<br />
:Use your results from the [https://www.w3.org/TR/security-privacy-questionnaire/ privacy/security questionnaire] (see privacy), then ask the [http://www.w3.org/Security/wiki/IG Security IG] for review: [mailto:public-web-security@w3.org public-web-security@w3.org]<br />
;Groups listed in your charter<br />
:If there are groups listed in your charter as depending on some specification, you should ask them too.<br />
<br />
=== Read on⌠===<br />
You should familiarise yourself with the rest of this document. This section is just a quick reminder for when you are in the middle of doing the work.<br />
<br />
== Considerations and Best Practices ==<br />
<br />
Among the considerations and best practices, regardless of the ''type of review'' (early, thorough wide review, etc.) are:<br />
=== Who to ask for review?===<br />
<br />
* '''Which group(s) should be asked to review a document?''' All group charters should include information about the groups and external liaisons that are interested in particular documents. At a minimum, those groups should be included in all review request for their related document(s). Additionally, it may be appropriate to explicitly seek review from others such as: other Consortium groups; external organizations and SSOs; ''stakeholders'' such as implementers, testing and interop experts, application developers, etc. If a document is explicitly identified as a joint deliverable with another group, it is especially important to make sure that group is included in all review requests.<br />
<br />
* '''Which Horizontal Groups should be asked to request a review?''' This can be a bit tricky because in some cases the set of relevant of ''horizontal groups'' (enumerated below) should be relatively obvious but in other cases it might not be. For example, Working Group Charters often explicitly identify Horizontal Group dependencies, but post-charter development may introduce features that require review by Horizontal Groups not called out in the charter. - SNZ<br />
** '''BP:''' if in doubt, before formally asking a horizontal group to review a document, talk to them informally (f.ex. via e-mail).<br />
<br />
''(comment): I agree that it may not be obvious that a document needs horizontal review, but I tend to take a stronger line: even if you have not identified a ''horizontal group'' dependency, you should always discuss whether a review is necessary or even request a review (saying if you think there are no issues of interest to the given group). --[[User:Aphillip|Addison Phillips]] ([[User talk:Aphillip|talk]])''<br />
<br />
* '''What should be done if it appears a document might be relevant to a [http://www.w3.org/2001/11/StdLiaison.html W3C liaison] but the liaison is not explicitly listed in the group's charter?''' The Chair(s) and Team Contacts should consult with their group, and if there is consensus within the group to contact the liaison, then that external group should be included in all review requests.<br />
** '''BP:''' That group should be included in review requests unless they ask not to be --CMN<br />
<br />
=== When should review be requested? ===<br />
<br />
* '''When is a group ''required'' to seek wide review of a Process-2019 document?''' For a document to enter CR, the group must show the document has had wide review. The requesting group is free to determine the timing for review requests.<br />
<br />
* '''When should reviews by Horizontal Groups be scheduled?''' Horizontal Groups are very often resource limited. This means that they can often only do one review and may have difficulty scheduling that review in a timely way. Secondly, to do a reasonable review, they need a document that is pretty stable, but still flexible enough to allow changes where issues are identified. -SNZ<br />
**'''BP:''' Contact the chair of each relevant Horizontal Group to arrange a suitable time in their schedule to review the document. - SNZ<br />
<br />
* '''What circumstances should trigger a RfC?''' When a new feature is added to a document after its FPWD is published or after the document has already been a target of a wide review, a group should seek wide review of that new feature. <br />
** Other reasons to consider wide review include: some other group expresses keen interest in a document.<br />
<br />
* '''What part of a document should be reviewed and when?''' The general rule of thumb is to get review ''early and often''.<br />
** '''BP:''' Ensure that each section or feature is reviewed when it is considered stable (this enables changes to be made early, which lowers the risk that deployed legacy will impact the possibilities for fixing something).<br />
<br />
=== Making reviews happen ===<br />
* '''Length of the Comment Period.''' The duration for comments (aka ''comment period'') depends on a number of factors including the version of the Process Document being used. As such, consult the Process being used.<br />
** '''BP:''' before a group asks another group to review a document, the requesting group should work with the review group to determine a mutually agreeable review timeline.<br />
<br />
* '''How to initiate a review request.''' Review requests should be sent to the review groups' Public mail list(s).<br />
** '''BP:''' please avoid cross-posting by using Bcc: if necessary.<br />
** '''BP:''' use the RfC template below.<br />
<br />
* '''Announce LCWD and pre-CR publications on the chairs list.''' The group Chair or W3C staff should announce all LCWD and pre-CR publications on the [https://lists.w3.org/Archives/Member/chairs/ chairs] list.<br />
<br />
* '''Announce all Requests for Review (f.ex. LCWD and pre-CR publications) on the <code>[http://lists.w3.org/Archives/Public/public-review-announce/ public-review-announce] e-mail list</code>'''. This announcement may be made by a group Chair, Consortium Staff, Editor or any other designated member of a group.<br />
** '''BP:''' use the RfC template below.<br />
<br />
* '''Use Public e-mail lists for review feedback.''' The requesting group's Public mail list should be used for review feedback.<br />
** '''BP:''' use the requesting group's main Public mail list for comments and do not use (nor create) a list whose sole purpose is for comments.<br />
<br />
* '''How can a group get acknowledgement that some person and/or group actually reviewed a document?''' Naturally, this isn't an issue if the reviewing group and/or individuals in the reviewing group actually provides review comments. However, in some cases, this can be somewhat difficult to determine and achieve (f.ex the reviewing group is small, the overlap in scope is minimal, etc.). <br />
** '''BP:''' when asking for review, explicitly ask the reviewing group to submit all feedback, even if the feedback is something like "I read it and have no comments".<br />
<br />
== Request for Comments (RfC) Template ==<br />
<br />
See the [http://www.w3.org/2014/11/getreview/ tool to assist with calls for specification review].<br />
<br />
=== General Information ===<br />
<br />
A RfC should include the following general information:<br />
<br />
* Name of the group seeking comments.<br />
<br />
* Deadline for comments.<br />
<br />
* <code>Subject:</code> header: include the maturity level, name of the document and document maturity level of the document<br />
** '''BP''': <code>Subject: RfC: FPWD of ''Name of Spec''; deadline MMM DD</code>.<br />
<br />
* Mail list for comments; include the mailto: address plus a link to the Public mail list archive<br />
** '''BP''': avoid cross-posting to multiple lists (and if this must be done, use Bcc:), except for the i18n WG, which needs to track issues on its technical list as well. (i18n WG members cannot subscribe to all the lists of the groups they review specs for.)<br />
<br />
* Alternate instructions for providing commentary ''(if needed)''. Some groups use bugzilla or github as a means of communication and for tracking issues. --[[User:Aphillip|Addison Phillips]] ([[User talk:Aphillip|talk]]) If your main or preferred tracking location is a database, make that clear in the SOD, since moving and tracking comments between mail threads and databases can waste time for both the reviewer and the reviewed group.<br />
<br />
* <code>Reply-to:</code> header: set the <code>Reply-to:</code> header to the mail list where all comments should be sent<br />
<br />
* State that all review be acknowledged, even if a reviewer or group has reviewed the document and has "no comments".<br />
<br />
=== Information for Each Document ===<br />
<br />
For each document that will be reviewed, provide at least:<br />
<br />
* Document title<br />
<br />
* URL<br />
** '''BP''': the contents of the document should be stable (i.e. not changed) during the review period. <br />
** '''BP''': if the contents of the document might change during the review, identify the specific section(s) that might change; or consider postponing the review until after those sections are stable.<br />
<br />
* Maturity level: FPWD, "pre-CR", CR, ...<br />
<br />
* Scope of the review: this can be the entire document, specific sections, specific issues, etc.<br />
** '''BP''': Identify the specific sections of the document that are newly stabilized, as well as those already considered stable. This allows reviewers who follow "at a distance" to focus on what's new, and allows new reviewers to focus on things that are ready for review, instead of providing a lot of comments on sections that are likely to shift.<br />
** '''BP''': Specifications should include information about stability and known implementation on a "section by section" basis.<br />
<br />
* If a review was previously requested, include the URL of a diff, using the previous version of the document as the diff's reference/base.<br />
** '''BP''': use [http://services.w3.org/htmldiff W3C HTML Diff service]<br />
** '''BP''': also provide a human-authored summary of the changes.<br />
<br />
=== Example Request for Comments ===<br />
<br />
Here are some example RfCs:<br />
<br />
* [http://lists.w3.org/Archives/Public/public-html/2014Sep/0099.html TTML Text and Imaging ... preCR]<br />
* [http://lists.w3.org/Archives/Public/public-review-announce/2014Nov/0002.html Pointer Events LCWD]<br />
<br />
== Horizontal Groups ==<br />
<br />
The consortium's so-called ''Horizontal Groups'' are groups that include review and coordination functions in their charter. Typically, these groups consist of individuals that can provide advice and guidance (to other groups) regarding their domain expertise.<br />
<br />
Groups with a horizontal review function, including their mail list are (alphabetical order):<br />
<br />
* [https://www.w3.org/WAI/APA/ Accessible Platform Architectures Working Group]; [https://lists.w3.org/Archives/Public/public-apa/ public-apa]; [https://www.w3.org/WAI/APA/wiki/Spec_Review APA Spec Review tracking]<br />
* [http://www.w3.org/International/ Internationalization Working Group]; [http://lists.w3.org/Archives/Public/www-international/ www-international] Reviews by Internationalization generally also involve the [http://www.w3.org/International/ig Interest Group], but are arranged through the WG.<br />
* [http://www.w3.org/Privacy/ Privacy Interest Group]; [http://lists.w3.org/Archives/Public/public-privacy/ public-privacy]<br />
* [http://www.w3.org/2001/tag/ Technical Architecture Group (TAG)]; [http://lists.w3.org/Archives/Public/www-tag/ www-tag]<br />
* [http://www.w3.org/2008/webapps/ Web API Consistency and Web IDL Conformance]; [http://lists.w3.org/Archives/Public/public-script-coord/ public-script-coord]; (this is a Web Platform WG list that liaises with ECMA's TC-39)<br />
* [http://www.w3.org/WAI/IG/ Web Accessibility Interest Group]; [http://lists.w3.org/Archives/Public/w3c-wai-ig/ w3c-wai-ig]<br />
* [http://www.w3.org/Security/wiki/IG Web Security Interest Group]; [http://lists.w3.org/Archives/Public/public-web-security/ public-web-security]<br />
<br />
=== Review Resources ===<br />
<br />
* Internationalization:<br />
** [https://www.w3.org/International/review-request I18n Request a review]<br />
** [http://w3c.github.io/i18n-activity/reviews/shortchecklist Short i18n review checklist]<br />
** [https://www.w3.org/International/techniques/developing-specs Expanding collapsing detailed checklist], generated from [https://w3c.github.io/bp-i18n-specdev/ ''Internationalization Best Practices for Spec Developers'']<br />
* Security/Privacy:<br />
** [https://www.w3.org/TR/security-privacy-questionnaire/ ''Self-Review Questionnaire: Security and Privacy''; Mike West]<br />
** [http://www.rfc-editor.org/rfc/rfc3552.txt Guidelines for Writing RFC Text on Security Considerations (RFC3552)]<br />
** [https://w3c.github.io/fingerprinting-guidance/ Mitigating Browser Fingerprinting in Web Specifications]<br />
** [http://gregnorc.github.io/ping-privacy-questions/ Ping-privacy-questions]<br />
** [https://yrlesru.github.io/SPA/ ''Specification Privacy Assessment (SPA) (Creating Privacy Considerations for W3C Technical Specifications)''; Frank Dawson]<br />
* Technical Architecture:<br />
** [https://www.w3.org/2001/tag/doc/webcomponents-design-guidelines/ Guidelines for creating web platform compatible components]<br />
** [https://www.w3.org/2001/tag/doc/promises-guide Writing Promise-Using Specifications]<br />
** [https://w3ctag.github.io/design-principles/ Client-side API Design Principles]<br />
** [https://www.w3.org/2001/tag/doc/capability-urls/ Good Practices for Capability URLs]<br />
** [https://github.com/w3ctag/spec-reviews TAG Repository for reviews]<br />
* Web Accessibility:<br />
** [http://w3c.github.io/apa/fast/checklist.html Framework for Accessibility in the Specification of Technologies Checklist; APA WG]<br />
** [https://www.w3.org/TR/media-accessibility-reqs/ Media Accessibility User Requirements; PFWG]<br />
<br />
== FAQ ==<br />
<br />
* '''Q: When is the best time to seek ''early'' review?'''<br />
** A: For a number factors (including document maturity, implementation status, etc.), there is no ''best time'' that applies to ''all'' documents. However, for most documents, after a ''First Public Working Draft'' is published is generally a good time to seek review of a specification.<br />
<br />
* '''Q: Is some type of ''security'' and/or ''privacy'' review mandatory before a ''First Public Working Draft'' is published?'''<br />
** A: Strictly speaking, the answer is No. However, getting early review for documents with features that might have security and/or privacy implications is '''strongly encouraged'''. See the [https://www.w3.org/wiki/DocumentReview#Horizontal_Groups Horizontal Groups] section below for information about security and privacy groups that can provide review and related review resources. <br />
<br />
* '''Q: Does a group need to prove its documents have had wide review before proceeding to CR?'''<br />
** A: The answer is yes, since Process-2019.<br />
<br />
* '''Q: How does a group prove its documents have had wide review before proceeding to CR?'''<br />
** A: See [http://lists.w3.org/Archives/Public/public-w3process/2014Oct/0133.html How to work with (experiment with) Wide Review] -SNZ<br />
** A: Keep a Disposition of Comments (DoC) Document that shows review comments and acknowledgements that have been received. It is the distribution of the reviewers that shows the review has been wide.-SNZ<br />
** A: Ask the W3C Team if your proposed approach is likely to meet the requirements. -SNZ<br />
<br />
* '''Q: Is there such a thing as too many reviews?'''<br />
** A: Not really<br />
<br />
* '''Q: Is it possible to make too many requests for review?'''<br />
** A: unfortunately, yes there is. Multiple requests for reviews can quickly result in a situation of diminishing returns. To help address this, subsequent review requests should clearly identify the exact differences between the last review and current review.<br />
** A: This is also the reason that the Process clearly suggests there should be (TR) Working Drafts published when there are "significant changes that would benefit from review beyond the Working Group", rather than every day or only twice in the life of a specâŚ<br />
** A: TR Working Drafts are also useful for reviews since they provide a dated snapshot which can be recovered when the review comments are being discussed. Trying to discuss review comments against a document which has changed out of all recognition can be a frustrating and inefficient experience.<br />
<br />
== Issues ==<br />
<br />
* <strike>'''Is ''pre-CR'' the ''best'' term to describe a Process-2014 snapshot that precedes CR or is there a better term?'''<br />
** Proposals: 2014-LC, 2014-Snapshot, pre-CR snapshot, 2014-Review Doc, pre-CR Review Doc, ...<br />
** Proposal: Don't do this in order to demonstrate "wide review". A "Last call" for a document that has already been reviewed in development is appropriate. Waiting until you think the document is finished to ask for review is a bad idea.</strike> ''This issue has become moot with the passing of time.''<br />
<br />
* <strike>'''How can a group or individual be automatically notified when a document has been published at one of the transitions that could/should initiate the start of an early or wide review?''' For Process-2005 documents, the transitions of interest are FPWD, LCWD and CR and for Proc-Doc-2015 documents the transitions of interest are: FPWD, pre-CR, and CR.</strike> ''This Issue was resolved via the creation of the <code>[http://lists.w3.org/Archives/Public/public-review-announce public-review-announce]</code> e-mail list.''<br />
<br />
* '''For all processes''' Working Drafts should be relevant for review - and should identify which parts are new or newly stabilized or changed, to facilitate '''timely''' review.<br />
** Potential solution: when a document is published on /TR, announce its publication on a Public mail list. See a related [http://lists.w3.org/Archives/Public/public-w3process/2014Oct/0102.html Call for Consensus] to create such a list, deadline for comments is October 15].<br />
<br />
== Terminology and Abbreviations ==<br />
<br />
* '''pre-CR''' - This is a version of a Working Draft that is created to get wide review.<br />
** note that this is a bad way to get review. In general, features should be reviewed as they are developed. Waiting for a "Last Call" for most review means that when reviews suggest changes it is far harder to make them, due to a commonly observed and logical reluctance to break deployed systems or content. [[User:Charles|Charles McCathie Nevile]] ([[User talk:Charles|talk]]) 11:18, 13 October 2014 (UTC)<br />
<br />
* '''requesting group''' - a group that is requesting a review <br />
<br />
Abbreviations:<br />
<br />
* BP = Best Practices<br />
* CR = Candidate Recommendation<br />
* RfC = Request for Comments (aka Review Request)<br />
* [http://www.w3.org/TR/ TR] = Technical Report, i.e. a formal W3C publication.<br />
* WD = Working Draft<br />
<br />
== Enhancement Requests ==<br />
<br />
* See the [https://www.w3.org/wiki/Dashboard#Document_Review_Dashboard Document Review Dashboard] document for information about creating a dashboard type service to facilitate document reviews.</div>Plehegarhttps://www.w3.org/wiki/index.php?title=DocumentReview&diff=109136DocumentReview2019-05-02T13:43:13Z<p>Plehegar: /* Horizontal Groups */</p>
<hr />
<div>Getting ''early'' and ''wide'' review of a document is very important yet in practice, it can be challenging. Rather than defining explicit mandatory steps for getting wide and constructive review, this document provides some considerations, guidelines and best practices that groups should follow.<br />
<br />
'''Feedback on this document is welcome, preferably by directly editing this document, by sending email to <code>[mailto:public-openw3c@w3.org public-openw3c@w3.org]</code> ([http://lists.w3.org/Archives/Public/public-openw3c/ archive]), or by tweeting to the [https://twitter.com/@openw3c @openw3c] twitter account.'''<br />
<br />
SeeAlso:<br />
<br />
* [http://www.w3.org/2014/11/getreview/ Tool to Assist with Calls for Specification Review]<br />
* [https://www.w3.org/2019/Process-20190301/ Process Document 2019]<br />
<br />
<br />
== Introduction ==<br />
<br />
Getting early review and feedback is important, especially reviews from those groups that have identified a document as a dependency, and the so-called ''horizontal groups''. It is also important to get review from other stakeholders including Web developers, technology providers and implementers not active in the Working Group, external groups and Standards organisations working on related areas, etc.<br />
<br />
In Process-2019, the focus is on actually getting evidence that wide review has occurred. The considerations, guidelines and Best Practices (BP) in this document should provide reasonable guidance for document review.<br />
<br />
== TL;DR: ==<br />
<br />
When you have published a First Public Working Draft, you should work through available "self-review" materials, and request review of your results, in at least the following areas. "Long enough*" before you request a transition to CR, you should do the same again, identifying substantive specification changes since the first review.<br />
<br />
The meaning of "Long enough*" depends on how many changes there are, and how clearly you have explained them. Pointing to 14 concise points for a small spec means a short time, pointing to 900 diffs from commits and hoping people understand them in a 300 page spec means it will take a '''long''' time to get review. If you have effectively identified issues for review during development, and got feedback on them, the review time will probably be shortened. It also depends how busy the groups are, so planning in advance is useful.<br />
<br />
;Accessibility<br />
:Work through [http://w3c.github.io/apa/fast/checklist.html this questionnaire] then ask [https://www.w3.org/WAI/APA/ APA] for review: [mailto:public-apa@w3.org public-apa@w3.org]<br />
;Architecture<br />
:Ask the [http://www.w3.org/2001/tag/ TAG] for review; see [https://tag.w3.org/workmode/ how to work with the TAG]. If you are developing javascript APIs you may also want to ask [mailto:public-script-coord@w3.org public-script-coord@w3.org], a technical discussion list shared by W3C and ECMA's TC 39.<br />
;Internationalisation<br />
:Work through the [[https://www.w3.org/International/techniques/developing-specs Checklist]], then request [http://www.w3.org/International/ i18n] review by email to [mailto:www-international@w3.org www-international@w3.org] (A public list watched by the Working Group). If for some reason you want a member-confidential review, you can ask on [mailto:member-i18n-core@w3.org member-i18n-core@w3.org] (a member-only list watched by the Working Group).<br />
;Privacy<br />
:Go through [https://www.w3.org/wiki/Privacy/Privacy_Considerations this checklist] and the [https://www.w3.org/TR/security-privacy-questionnaire/ privacy/security checklist], then ask the [http://www.w3.org/Privacy/ Privacy Interest Group for a review: [mailto:public-privacy@w3.org public-privacy@w3.org]<br />
;Security<br />
:Use your results from the [https://www.w3.org/TR/security-privacy-questionnaire/ privacy/security questionnaire] (see privacy), then ask the [http://www.w3.org/Security/wiki/IG Security IG] for review: [mailto:public-web-security@w3.org public-web-security@w3.org]<br />
;Groups listed in your charter<br />
:If there are groups listed in your charter as depending on some specification, you should ask them too.<br />
<br />
=== Read on⌠===<br />
You should familiarise yourself with the rest of this document. This section is just a quick reminder for when you are in the middle of doing the work.<br />
<br />
== Considerations and Best Practices ==<br />
<br />
Among the considerations and best practices, regardless of the ''type of review'' (early, thorough wide review, etc.) are:<br />
=== Who to ask for review?===<br />
<br />
* '''Which group(s) should be asked to review a document?''' All group charters should include information about the groups and external liaisons that are interested in particular documents. At a minimum, those groups should be included in all review request for their related document(s). Additionally, it may be appropriate to explicitly seek review from others such as: other Consortium groups; external organizations and SSOs; ''stakeholders'' such as implementers, testing and interop experts, application developers, etc. If a document is explicitly identified as a joint deliverable with another group, it is especially important to make sure that group is included in all review requests.<br />
<br />
* '''Which Horizontal Groups should be asked to request a review?''' This can be a bit tricky because in some cases the set of relevant of ''horizontal groups'' (enumerated below) should be relatively obvious but in other cases it might not be. For example, Working Group Charters often explicitly identify Horizontal Group dependencies, but post-charter development may introduce features that require review by Horizontal Groups not called out in the charter. - SNZ<br />
** '''BP:''' if in doubt, before formally asking a horizontal group to review a document, talk to them informally (f.ex. via e-mail).<br />
<br />
''(comment): I agree that it may not be obvious that a document needs horizontal review, but I tend to take a stronger line: even if you have not identified a ''horizontal group'' dependency, you should always discuss whether a review is necessary or even request a review (saying if you think there are no issues of interest to the given group). --[[User:Aphillip|Addison Phillips]] ([[User talk:Aphillip|talk]])''<br />
<br />
* '''What should be done if it appears a document might be relevant to a [http://www.w3.org/2001/11/StdLiaison.html W3C liaison] but the liaison is not explicitly listed in the group's charter?''' The Chair(s) and Team Contacts should consult with their group, and if there is consensus within the group to contact the liaison, then that external group should be included in all review requests.<br />
** '''BP:''' That group should be included in review requests unless they ask not to be --CMN<br />
<br />
=== When should review be requested? ===<br />
<br />
* '''When is a group ''required'' to seek wide review of a Process-2019 document?''' For a document to enter CR, the group must show the document has had wide review. The requesting group is free to determine the timing for review requests.<br />
<br />
* '''When should reviews by Horizontal Groups be scheduled?''' Horizontal Groups are very often resource limited. This means that they can often only do one review and may have difficulty scheduling that review in a timely way. Secondly, to do a reasonable review, they need a document that is pretty stable, but still flexible enough to allow changes where issues are identified. -SNZ<br />
**'''BP:''' Contact the chair of each relevant Horizontal Group to arrange a suitable time in their schedule to review the document. - SNZ<br />
<br />
* '''What circumstances should trigger a RfC?''' When a new feature is added to a document after its FPWD is published or after the document has already been a target of a wide review, a group should seek wide review of that new feature. <br />
** Other reasons to consider wide review include: some other group expresses keen interest in a document.<br />
<br />
* '''What part of a document should be reviewed and when?''' The general rule of thumb is to get review ''early and often''.<br />
** '''BP:''' Ensure that each section or feature is reviewed when it is considered stable (this enables changes to be made early, which lowers the risk that deployed legacy will impact the possibilities for fixing something).<br />
<br />
=== Making reviews happen ===<br />
* '''Length of the Comment Period.''' The duration for comments (aka ''comment period'') depends on a number of factors including the version of the Process Document being used. As such, consult the Process being used.<br />
** '''BP:''' before a group asks another group to review a document, the requesting group should work with the review group to determine a mutually agreeable review timeline.<br />
<br />
* '''How to initiate a review request.''' Review requests should be sent to the review groups' Public mail list(s).<br />
** '''BP:''' please avoid cross-posting by using Bcc: if necessary.<br />
** '''BP:''' use the RfC template below.<br />
<br />
* '''Announce LCWD and pre-CR publications on the chairs list.''' The group Chair or W3C staff should announce all LCWD and pre-CR publications on the [https://lists.w3.org/Archives/Member/chairs/ chairs] list.<br />
<br />
* '''Announce all Requests for Review (f.ex. LCWD and pre-CR publications) on the <code>[http://lists.w3.org/Archives/Public/public-review-announce/ public-review-announce] e-mail list</code>'''. This announcement may be made by a group Chair, Consortium Staff, Editor or any other designated member of a group.<br />
** '''BP:''' use the RfC template below.<br />
<br />
* '''Use Public e-mail lists for review feedback.''' The requesting group's Public mail list should be used for review feedback.<br />
** '''BP:''' use the requesting group's main Public mail list for comments and do not use (nor create) a list whose sole purpose is for comments.<br />
<br />
* '''How can a group get acknowledgement that some person and/or group actually reviewed a document?''' Naturally, this isn't an issue if the reviewing group and/or individuals in the reviewing group actually provides review comments. However, in some cases, this can be somewhat difficult to determine and achieve (f.ex the reviewing group is small, the overlap in scope is minimal, etc.). <br />
** '''BP:''' when asking for review, explicitly ask the reviewing group to submit all feedback, even if the feedback is something like "I read it and have no comments".<br />
<br />
== Request for Comments (RfC) Template ==<br />
<br />
See the [http://www.w3.org/2014/11/getreview/ tool to assist with calls for specification review].<br />
<br />
=== General Information ===<br />
<br />
A RfC should include the following general information:<br />
<br />
* Name of the group seeking comments.<br />
<br />
* Deadline for comments.<br />
<br />
* <code>Subject:</code> header: include the maturity level, name of the document and document maturity level of the document<br />
** '''BP''': <code>Subject: RfC: FPWD of ''Name of Spec''; deadline MMM DD</code>.<br />
<br />
* Mail list for comments; include the mailto: address plus a link to the Public mail list archive<br />
** '''BP''': avoid cross-posting to multiple lists (and if this must be done, use Bcc:), except for the i18n WG, which needs to track issues on its technical list as well. (i18n WG members cannot subscribe to all the lists of the groups they review specs for.)<br />
<br />
* Alternate instructions for providing commentary ''(if needed)''. Some groups use bugzilla or github as a means of communication and for tracking issues. --[[User:Aphillip|Addison Phillips]] ([[User talk:Aphillip|talk]]) If your main or preferred tracking location is a database, make that clear in the SOD, since moving and tracking comments between mail threads and databases can waste time for both the reviewer and the reviewed group.<br />
<br />
* <code>Reply-to:</code> header: set the <code>Reply-to:</code> header to the mail list where all comments should be sent<br />
<br />
* State that all review be acknowledged, even if a reviewer or group has reviewed the document and has "no comments".<br />
<br />
=== Information for Each Document ===<br />
<br />
For each document that will be reviewed, provide at least:<br />
<br />
* Document title<br />
<br />
* URL<br />
** '''BP''': the contents of the document should be stable (i.e. not changed) during the review period. <br />
** '''BP''': if the contents of the document might change during the review, identify the specific section(s) that might change; or consider postponing the review until after those sections are stable.<br />
<br />
* Maturity level: FPWD, CR, ...<br />
<br />
* Scope of the review: this can be the entire document, specific sections, specific issues, etc.<br />
** '''BP''': Identify the specific sections of the document that are newly stabilized, as well as those already considered stable. This allows reviewers who follow "at a distance" to focus on what's new, and allows new reviewers to focus on things that are ready for review, instead of providing a lot of comments on sections that are likely to shift.<br />
** '''BP''': Specifications should include information about stability and known implementation on a "section by section" basis.<br />
<br />
* If a review was previously requested, include the URL of a diff, using the previous version of the document as the diff's reference/base.<br />
** '''BP''': use [http://services.w3.org/htmldiff W3C HTML Diff service]<br />
** '''BP''': also provide a human-authored summary of the changes.<br />
<br />
=== Example Request for Comments ===<br />
<br />
Here are some example RfCs:<br />
<br />
* [http://lists.w3.org/Archives/Public/public-html/2014Sep/0099.html TTML Text and Imaging ... preCR]<br />
* [http://lists.w3.org/Archives/Public/public-review-announce/2014Nov/0002.html Pointer Events LCWD]<br />
<br />
== Horizontal Groups ==<br />
<br />
The consortium's so-called ''Horizontal Groups'' are groups that include review and coordination functions in their charter. Typically, these groups consist of individuals that can provide advice and guidance (to other groups) regarding their domain expertise.<br />
<br />
Groups with a horizontal review function, including their mail list are (alphabetical order):<br />
<br />
* [https://www.w3.org/WAI/APA/ Accessible Platform Architectures Working Group]; [https://lists.w3.org/Archives/Public/public-apa/ public-apa]; [https://www.w3.org/WAI/APA/wiki/Spec_Review APA Spec Review tracking]<br />
* [http://www.w3.org/International/ Internationalization Working Group]; [http://lists.w3.org/Archives/Public/www-international/ www-international] Reviews by Internationalization generally also involve the [http://www.w3.org/International/ig Interest Group], but are arranged through the WG.<br />
* [http://www.w3.org/Privacy/ Privacy Interest Group]; [http://lists.w3.org/Archives/Public/public-privacy/ public-privacy]<br />
* [http://www.w3.org/2001/tag/ Technical Architecture Group (TAG)]; [http://lists.w3.org/Archives/Public/www-tag/ www-tag]<br />
* [http://www.w3.org/2008/webapps/ Web API Consistency and Web IDL Conformance]; [http://lists.w3.org/Archives/Public/public-script-coord/ public-script-coord]; (this is a Web Platform WG list that liaises with ECMA's TC-39)<br />
* [http://www.w3.org/WAI/IG/ Web Accessibility Interest Group]; [http://lists.w3.org/Archives/Public/w3c-wai-ig/ w3c-wai-ig]<br />
* [http://www.w3.org/Security/wiki/IG Web Security Interest Group]; [http://lists.w3.org/Archives/Public/public-web-security/ public-web-security]<br />
<br />
=== Review Resources ===<br />
<br />
* Internationalization:<br />
** [https://www.w3.org/International/review-request I18n Request a review]<br />
** [http://w3c.github.io/i18n-activity/reviews/shortchecklist Short i18n review checklist]<br />
** [https://www.w3.org/International/techniques/developing-specs Expanding collapsing detailed checklist], generated from [https://w3c.github.io/bp-i18n-specdev/ ''Internationalization Best Practices for Spec Developers'']<br />
* Security/Privacy:<br />
** [https://www.w3.org/TR/security-privacy-questionnaire/ ''Self-Review Questionnaire: Security and Privacy''; Mike West]<br />
** [http://www.rfc-editor.org/rfc/rfc3552.txt Guidelines for Writing RFC Text on Security Considerations (RFC3552)]<br />
** [https://w3c.github.io/fingerprinting-guidance/ Mitigating Browser Fingerprinting in Web Specifications]<br />
** [http://gregnorc.github.io/ping-privacy-questions/ Ping-privacy-questions]<br />
** [https://yrlesru.github.io/SPA/ ''Specification Privacy Assessment (SPA) (Creating Privacy Considerations for W3C Technical Specifications)''; Frank Dawson]<br />
* Technical Architecture:<br />
** [https://www.w3.org/2001/tag/doc/webcomponents-design-guidelines/ Guidelines for creating web platform compatible components]<br />
** [https://www.w3.org/2001/tag/doc/promises-guide Writing Promise-Using Specifications]<br />
** [https://w3ctag.github.io/design-principles/ Client-side API Design Principles]<br />
** [https://www.w3.org/2001/tag/doc/capability-urls/ Good Practices for Capability URLs]<br />
** [https://github.com/w3ctag/spec-reviews TAG Repository for reviews]<br />
* Web Accessibility:<br />
** [http://w3c.github.io/apa/fast/checklist.html Framework for Accessibility in the Specification of Technologies Checklist; APA WG]<br />
** [https://www.w3.org/TR/media-accessibility-reqs/ Media Accessibility User Requirements; PFWG]<br />
<br />
== FAQ ==<br />
<br />
* '''Q: When is the best time to seek ''early'' review?'''<br />
** A: For a number factors (including document maturity, implementation status, etc.), there is no ''best time'' that applies to ''all'' documents. However, for most documents, after a ''First Public Working Draft'' is published is generally a good time to seek review of a specification.<br />
<br />
* '''Q: Is some type of ''security'' and/or ''privacy'' review mandatory before a ''First Public Working Draft'' is published?'''<br />
** A: Strictly speaking, the answer is No. However, getting early review for documents with features that might have security and/or privacy implications is '''strongly encouraged'''. See the [https://www.w3.org/wiki/DocumentReview#Horizontal_Groups Horizontal Groups] section below for information about security and privacy groups that can provide review and related review resources. <br />
<br />
* '''Q: Does a group need to prove its documents have had wide review before proceeding to CR?'''<br />
** A: The answer is yes, since Process-2019.<br />
<br />
* '''Q: How does a group prove its documents have had wide review before proceeding to CR?'''<br />
** A: See [http://lists.w3.org/Archives/Public/public-w3process/2014Oct/0133.html How to work with (experiment with) Wide Review] -SNZ<br />
** A: Keep a Disposition of Comments (DoC) Document that shows review comments and acknowledgements that have been received. It is the distribution of the reviewers that shows the review has been wide.-SNZ<br />
** A: Ask the W3C Team if your proposed approach is likely to meet the requirements. -SNZ<br />
<br />
* '''Q: Is there such a thing as too many reviews?'''<br />
** A: Not really<br />
<br />
* '''Q: Is it possible to make too many requests for review?'''<br />
** A: unfortunately, yes there is. Multiple requests for reviews can quickly result in a situation of diminishing returns. To help address this, subsequent review requests should clearly identify the exact differences between the last review and current review.<br />
** A: This is also the reason that the Process clearly suggests there should be (TR) Working Drafts published when there are "significant changes that would benefit from review beyond the Working Group", rather than every day or only twice in the life of a specâŚ<br />
** A: TR Working Drafts are also useful for reviews since they provide a dated snapshot which can be recovered when the review comments are being discussed. Trying to discuss review comments against a document which has changed out of all recognition can be a frustrating and inefficient experience.<br />
<br />
== Issues ==<br />
<br />
* <strike>'''Is ''pre-CR'' the ''best'' term to describe a Process-2014 snapshot that precedes CR or is there a better term?'''<br />
** Proposals: 2014-LC, 2014-Snapshot, pre-CR snapshot, 2014-Review Doc, pre-CR Review Doc, ...<br />
** Proposal: Don't do this in order to demonstrate "wide review". A "Last call" for a document that has already been reviewed in development is appropriate. Waiting until you think the document is finished to ask for review is a bad idea.</strike> ''This issue has become moot with the passing of time.''<br />
<br />
* <strike>'''How can a group or individual be automatically notified when a document has been published at one of the transitions that could/should initiate the start of an early or wide review?''' For Process-2005 documents, the transitions of interest are FPWD, LCWD and CR and for Proc-Doc-2015 documents the transitions of interest are: FPWD, pre-CR, and CR.</strike> ''This Issue was resolved via the creation of the <code>[http://lists.w3.org/Archives/Public/public-review-announce public-review-announce]</code> e-mail list.''<br />
<br />
* '''For all processes''' Working Drafts should be relevant for review - and should identify which parts are new or newly stabilized or changed, to facilitate '''timely''' review.<br />
** Potential solution: when a document is published on /TR, announce its publication on a Public mail list. See a related [http://lists.w3.org/Archives/Public/public-w3process/2014Oct/0102.html Call for Consensus] to create such a list, deadline for comments is October 15].<br />
<br />
== Terminology and Abbreviations ==<br />
<br />
* '''pre-CR''' - This is a version of a Working Draft that is created to get wide review.<br />
** note that this is a bad way to get review. In general, features should be reviewed as they are developed. Waiting for a "Last Call" for most review means that when reviews suggest changes it is far harder to make them, due to a commonly observed and logical reluctance to break deployed systems or content. [[User:Charles|Charles McCathie Nevile]] ([[User talk:Charles|talk]]) 11:18, 13 October 2014 (UTC)<br />
<br />
* '''requesting group''' - a group that is requesting a review <br />
<br />
Abbreviations:<br />
<br />
* BP = Best Practices<br />
* CR = Candidate Recommendation<br />
* RfC = Request for Comments (aka Review Request)<br />
* [http://www.w3.org/TR/ TR] = Technical Report, i.e. a formal W3C publication.<br />
* WD = Working Draft<br />
<br />
== Enhancement Requests ==<br />
<br />
* See the [https://www.w3.org/wiki/Dashboard#Document_Review_Dashboard Document Review Dashboard] document for information about creating a dashboard type service to facilitate document reviews.</div>Plehegarhttps://www.w3.org/wiki/index.php?title=DocumentReview&diff=109135DocumentReview2019-05-02T13:42:56Z<p>Plehegar: /* Information for Each Document */</p>
<hr />
<div>Getting ''early'' and ''wide'' review of a document is very important yet in practice, it can be challenging. Rather than defining explicit mandatory steps for getting wide and constructive review, this document provides some considerations, guidelines and best practices that groups should follow.<br />
<br />
'''Feedback on this document is welcome, preferably by directly editing this document, by sending email to <code>[mailto:public-openw3c@w3.org public-openw3c@w3.org]</code> ([http://lists.w3.org/Archives/Public/public-openw3c/ archive]), or by tweeting to the [https://twitter.com/@openw3c @openw3c] twitter account.'''<br />
<br />
SeeAlso:<br />
<br />
* [http://www.w3.org/2014/11/getreview/ Tool to Assist with Calls for Specification Review]<br />
* [https://www.w3.org/2019/Process-20190301/ Process Document 2019]<br />
<br />
<br />
== Introduction ==<br />
<br />
Getting early review and feedback is important, especially reviews from those groups that have identified a document as a dependency, and the so-called ''horizontal groups''. It is also important to get review from other stakeholders including Web developers, technology providers and implementers not active in the Working Group, external groups and Standards organisations working on related areas, etc.<br />
<br />
In Process-2019, the focus is on actually getting evidence that wide review has occurred. The considerations, guidelines and Best Practices (BP) in this document should provide reasonable guidance for document review.<br />
<br />
== TL;DR: ==<br />
<br />
When you have published a First Public Working Draft, you should work through available "self-review" materials, and request review of your results, in at least the following areas. "Long enough*" before you request a transition to CR, you should do the same again, identifying substantive specification changes since the first review.<br />
<br />
The meaning of "Long enough*" depends on how many changes there are, and how clearly you have explained them. Pointing to 14 concise points for a small spec means a short time, pointing to 900 diffs from commits and hoping people understand them in a 300 page spec means it will take a '''long''' time to get review. If you have effectively identified issues for review during development, and got feedback on them, the review time will probably be shortened. It also depends how busy the groups are, so planning in advance is useful.<br />
<br />
;Accessibility<br />
:Work through [http://w3c.github.io/apa/fast/checklist.html this questionnaire] then ask [https://www.w3.org/WAI/APA/ APA] for review: [mailto:public-apa@w3.org public-apa@w3.org]<br />
;Architecture<br />
:Ask the [http://www.w3.org/2001/tag/ TAG] for review; see [https://tag.w3.org/workmode/ how to work with the TAG]. If you are developing javascript APIs you may also want to ask [mailto:public-script-coord@w3.org public-script-coord@w3.org], a technical discussion list shared by W3C and ECMA's TC 39.<br />
;Internationalisation<br />
:Work through the [[https://www.w3.org/International/techniques/developing-specs Checklist]], then request [http://www.w3.org/International/ i18n] review by email to [mailto:www-international@w3.org www-international@w3.org] (A public list watched by the Working Group). If for some reason you want a member-confidential review, you can ask on [mailto:member-i18n-core@w3.org member-i18n-core@w3.org] (a member-only list watched by the Working Group).<br />
;Privacy<br />
:Go through [https://www.w3.org/wiki/Privacy/Privacy_Considerations this checklist] and the [https://www.w3.org/TR/security-privacy-questionnaire/ privacy/security checklist], then ask the [http://www.w3.org/Privacy/ Privacy Interest Group for a review: [mailto:public-privacy@w3.org public-privacy@w3.org]<br />
;Security<br />
:Use your results from the [https://www.w3.org/TR/security-privacy-questionnaire/ privacy/security questionnaire] (see privacy), then ask the [http://www.w3.org/Security/wiki/IG Security IG] for review: [mailto:public-web-security@w3.org public-web-security@w3.org]<br />
;Groups listed in your charter<br />
:If there are groups listed in your charter as depending on some specification, you should ask them too.<br />
<br />
=== Read on⌠===<br />
You should familiarise yourself with the rest of this document. This section is just a quick reminder for when you are in the middle of doing the work.<br />
<br />
== Considerations and Best Practices ==<br />
<br />
Among the considerations and best practices, regardless of the ''type of review'' (early, thorough wide review, etc.) are:<br />
=== Who to ask for review?===<br />
<br />
* '''Which group(s) should be asked to review a document?''' All group charters should include information about the groups and external liaisons that are interested in particular documents. At a minimum, those groups should be included in all review request for their related document(s). Additionally, it may be appropriate to explicitly seek review from others such as: other Consortium groups; external organizations and SSOs; ''stakeholders'' such as implementers, testing and interop experts, application developers, etc. If a document is explicitly identified as a joint deliverable with another group, it is especially important to make sure that group is included in all review requests.<br />
<br />
* '''Which Horizontal Groups should be asked to request a review?''' This can be a bit tricky because in some cases the set of relevant of ''horizontal groups'' (enumerated below) should be relatively obvious but in other cases it might not be. For example, Working Group Charters often explicitly identify Horizontal Group dependencies, but post-charter development may introduce features that require review by Horizontal Groups not called out in the charter. - SNZ<br />
** '''BP:''' if in doubt, before formally asking a horizontal group to review a document, talk to them informally (f.ex. via e-mail).<br />
<br />
''(comment): I agree that it may not be obvious that a document needs horizontal review, but I tend to take a stronger line: even if you have not identified a ''horizontal group'' dependency, you should always discuss whether a review is necessary or even request a review (saying if you think there are no issues of interest to the given group). --[[User:Aphillip|Addison Phillips]] ([[User talk:Aphillip|talk]])''<br />
<br />
* '''What should be done if it appears a document might be relevant to a [http://www.w3.org/2001/11/StdLiaison.html W3C liaison] but the liaison is not explicitly listed in the group's charter?''' The Chair(s) and Team Contacts should consult with their group, and if there is consensus within the group to contact the liaison, then that external group should be included in all review requests.<br />
** '''BP:''' That group should be included in review requests unless they ask not to be --CMN<br />
<br />
=== When should review be requested? ===<br />
<br />
* '''When is a group ''required'' to seek wide review of a Process-2019 document?''' For a document to enter CR, the group must show the document has had wide review. The requesting group is free to determine the timing for review requests.<br />
<br />
* '''When should reviews by Horizontal Groups be scheduled?''' Horizontal Groups are very often resource limited. This means that they can often only do one review and may have difficulty scheduling that review in a timely way. Secondly, to do a reasonable review, they need a document that is pretty stable, but still flexible enough to allow changes where issues are identified. -SNZ<br />
**'''BP:''' Contact the chair of each relevant Horizontal Group to arrange a suitable time in their schedule to review the document. - SNZ<br />
<br />
* '''What circumstances should trigger a RfC?''' When a new feature is added to a document after its FPWD is published or after the document has already been a target of a wide review, a group should seek wide review of that new feature. <br />
** Other reasons to consider wide review include: some other group expresses keen interest in a document.<br />
<br />
* '''What part of a document should be reviewed and when?''' The general rule of thumb is to get review ''early and often''.<br />
** '''BP:''' Ensure that each section or feature is reviewed when it is considered stable (this enables changes to be made early, which lowers the risk that deployed legacy will impact the possibilities for fixing something).<br />
<br />
=== Making reviews happen ===<br />
* '''Length of the Comment Period.''' The duration for comments (aka ''comment period'') depends on a number of factors including the version of the Process Document being used. As such, consult the Process being used.<br />
** '''BP:''' before a group asks another group to review a document, the requesting group should work with the review group to determine a mutually agreeable review timeline.<br />
<br />
* '''How to initiate a review request.''' Review requests should be sent to the review groups' Public mail list(s).<br />
** '''BP:''' please avoid cross-posting by using Bcc: if necessary.<br />
** '''BP:''' use the RfC template below.<br />
<br />
* '''Announce LCWD and pre-CR publications on the chairs list.''' The group Chair or W3C staff should announce all LCWD and pre-CR publications on the [https://lists.w3.org/Archives/Member/chairs/ chairs] list.<br />
<br />
* '''Announce all Requests for Review (f.ex. LCWD and pre-CR publications) on the <code>[http://lists.w3.org/Archives/Public/public-review-announce/ public-review-announce] e-mail list</code>'''. This announcement may be made by a group Chair, Consortium Staff, Editor or any other designated member of a group.<br />
** '''BP:''' use the RfC template below.<br />
<br />
* '''Use Public e-mail lists for review feedback.''' The requesting group's Public mail list should be used for review feedback.<br />
** '''BP:''' use the requesting group's main Public mail list for comments and do not use (nor create) a list whose sole purpose is for comments.<br />
<br />
* '''How can a group get acknowledgement that some person and/or group actually reviewed a document?''' Naturally, this isn't an issue if the reviewing group and/or individuals in the reviewing group actually provides review comments. However, in some cases, this can be somewhat difficult to determine and achieve (f.ex the reviewing group is small, the overlap in scope is minimal, etc.). <br />
** '''BP:''' when asking for review, explicitly ask the reviewing group to submit all feedback, even if the feedback is something like "I read it and have no comments".<br />
<br />
== Request for Comments (RfC) Template ==<br />
<br />
See the [http://www.w3.org/2014/11/getreview/ tool to assist with calls for specification review].<br />
<br />
=== General Information ===<br />
<br />
A RfC should include the following general information:<br />
<br />
* Name of the group seeking comments.<br />
<br />
* Deadline for comments.<br />
<br />
* <code>Subject:</code> header: include the maturity level, name of the document and document maturity level of the document<br />
** '''BP''': <code>Subject: RfC: FPWD of ''Name of Spec''; deadline MMM DD</code>.<br />
<br />
* Mail list for comments; include the mailto: address plus a link to the Public mail list archive<br />
** '''BP''': avoid cross-posting to multiple lists (and if this must be done, use Bcc:), except for the i18n WG, which needs to track issues on its technical list as well. (i18n WG members cannot subscribe to all the lists of the groups they review specs for.)<br />
<br />
* Alternate instructions for providing commentary ''(if needed)''. Some groups use bugzilla or github as a means of communication and for tracking issues. --[[User:Aphillip|Addison Phillips]] ([[User talk:Aphillip|talk]]) If your main or preferred tracking location is a database, make that clear in the SOD, since moving and tracking comments between mail threads and databases can waste time for both the reviewer and the reviewed group.<br />
<br />
* <code>Reply-to:</code> header: set the <code>Reply-to:</code> header to the mail list where all comments should be sent<br />
<br />
* State that all review be acknowledged, even if a reviewer or group has reviewed the document and has "no comments".<br />
<br />
=== Information for Each Document ===<br />
<br />
For each document that will be reviewed, provide at least:<br />
<br />
* Document title<br />
<br />
* URL<br />
** '''BP''': the contents of the document should be stable (i.e. not changed) during the review period. <br />
** '''BP''': if the contents of the document might change during the review, identify the specific section(s) that might change; or consider postponing the review until after those sections are stable.<br />
<br />
* Maturity level: FPWD, CR, ...<br />
<br />
* Scope of the review: this can be the entire document, specific sections, specific issues, etc.<br />
** '''BP''': Identify the specific sections of the document that are newly stabilized, as well as those already considered stable. This allows reviewers who follow "at a distance" to focus on what's new, and allows new reviewers to focus on things that are ready for review, instead of providing a lot of comments on sections that are likely to shift.<br />
** '''BP''': Specifications should include information about stability and known implementation on a "section by section" basis.<br />
<br />
* If a review was previously requested, include the URL of a diff, using the previous version of the document as the diff's reference/base.<br />
** '''BP''': use [http://services.w3.org/htmldiff W3C HTML Diff service]<br />
** '''BP''': also provide a human-authored summary of the changes.<br />
<br />
=== Example Request for Comments ===<br />
<br />
Here are some example RfCs:<br />
<br />
* [http://lists.w3.org/Archives/Public/public-html/2014Sep/0099.html TTML Text and Imaging ... preCR]<br />
* [http://lists.w3.org/Archives/Public/public-review-announce/2014Nov/0002.html Pointer Events LCWD]<br />
<br />
== Horizontal Groups ==<br />
<br />
The consortium's so-called ''Horizontal Groups'' are groups that include review and coordination functions in their charter. Typically, these groups consist of individuals that can provide advice and guidance (to other groups) regarding their domain expertise.<br />
<br />
Groups with a horizontal review function, including their mail list are (alphabetical order):<br />
<br />
* [https://www.w3.org/WAI/APA/ Accessible Platform Architectures Working Group]; [https://lists.w3.org/Archives/Public/public-apa/ public-apa]; [https://www.w3.org/WAI/APA/wiki/Spec_Review APA Spec Review tracking]<br />
* [http://www.w3.org/International/ Internationalization Working Group]; [http://lists.w3.org/Archives/Public/www-international/ www-international] Reviews by Internationalization generally also involve the [http://www.w3.org/International/ig Interest Group], but are arranged through the WG.<br />
* [http://www.w3.org/Privacy/ Privacy Interest Group]; [http://lists.w3.org/Archives/Public/public-privacy/ public-privacy]<br />
* [http://www.w3.org/2001/tag/ Technical Architecture Group (TAG)]; [http://lists.w3.org/Archives/Public/www-tag/ www-tag]<br />
* [http://www.w3.org/2008/webapps/ Web API Consistency and Web IDL Conformance]; [http://lists.w3.org/Archives/Public/public-script-coord/ public-script-coord]; (this is a Web Platform WG list that liases with ECMA's TC-39)<br />
* [http://www.w3.org/WAI/IG/ Web Accessibility Interest Group]; [http://lists.w3.org/Archives/Public/w3c-wai-ig/ w3c-wai-ig]<br />
* [http://www.w3.org/Security/wiki/IG Web Security Interest Group]; [http://lists.w3.org/Archives/Public/public-web-security/ public-web-security]<br />
<br />
=== Review Resources ===<br />
<br />
* Internationalization:<br />
** [https://www.w3.org/International/review-request I18n Request a review]<br />
** [http://w3c.github.io/i18n-activity/reviews/shortchecklist Short i18n review checklist]<br />
** [https://www.w3.org/International/techniques/developing-specs Expanding collapsing detailed checklist], generated from [https://w3c.github.io/bp-i18n-specdev/ ''Internationalization Best Practices for Spec Developers'']<br />
* Security/Privacy:<br />
** [https://www.w3.org/TR/security-privacy-questionnaire/ ''Self-Review Questionnaire: Security and Privacy''; Mike West]<br />
** [http://www.rfc-editor.org/rfc/rfc3552.txt Guidelines for Writing RFC Text on Security Considerations (RFC3552)]<br />
** [https://w3c.github.io/fingerprinting-guidance/ Mitigating Browser Fingerprinting in Web Specifications]<br />
** [http://gregnorc.github.io/ping-privacy-questions/ Ping-privacy-questions]<br />
** [https://yrlesru.github.io/SPA/ ''Specification Privacy Assessment (SPA) (Creating Privacy Considerations for W3C Technical Specifications)''; Frank Dawson]<br />
* Technical Architecture:<br />
** [https://www.w3.org/2001/tag/doc/webcomponents-design-guidelines/ Guidelines for creating web platform compatible components]<br />
** [https://www.w3.org/2001/tag/doc/promises-guide Writing Promise-Using Specifications]<br />
** [https://w3ctag.github.io/design-principles/ Client-side API Design Principles]<br />
** [https://www.w3.org/2001/tag/doc/capability-urls/ Good Practices for Capability URLs]<br />
** [https://github.com/w3ctag/spec-reviews TAG Repository for reviews]<br />
* Web Accessibility:<br />
** [http://w3c.github.io/apa/fast/checklist.html Framework for Accessibility in the Specification of Technologies Checklist; APA WG]<br />
** [https://www.w3.org/TR/media-accessibility-reqs/ Media Accessibility User Requirements; PFWG]<br />
<br />
== FAQ ==<br />
<br />
* '''Q: When is the best time to seek ''early'' review?'''<br />
** A: For a number factors (including document maturity, implementation status, etc.), there is no ''best time'' that applies to ''all'' documents. However, for most documents, after a ''First Public Working Draft'' is published is generally a good time to seek review of a specification.<br />
<br />
* '''Q: Is some type of ''security'' and/or ''privacy'' review mandatory before a ''First Public Working Draft'' is published?'''<br />
** A: Strictly speaking, the answer is No. However, getting early review for documents with features that might have security and/or privacy implications is '''strongly encouraged'''. See the [https://www.w3.org/wiki/DocumentReview#Horizontal_Groups Horizontal Groups] section below for information about security and privacy groups that can provide review and related review resources. <br />
<br />
* '''Q: Does a group need to prove its documents have had wide review before proceeding to CR?'''<br />
** A: The answer is yes, since Process-2019.<br />
<br />
* '''Q: How does a group prove its documents have had wide review before proceeding to CR?'''<br />
** A: See [http://lists.w3.org/Archives/Public/public-w3process/2014Oct/0133.html How to work with (experiment with) Wide Review] -SNZ<br />
** A: Keep a Disposition of Comments (DoC) Document that shows review comments and acknowledgements that have been received. It is the distribution of the reviewers that shows the review has been wide.-SNZ<br />
** A: Ask the W3C Team if your proposed approach is likely to meet the requirements. -SNZ<br />
<br />
* '''Q: Is there such a thing as too many reviews?'''<br />
** A: Not really<br />
<br />
* '''Q: Is it possible to make too many requests for review?'''<br />
** A: unfortunately, yes there is. Multiple requests for reviews can quickly result in a situation of diminishing returns. To help address this, subsequent review requests should clearly identify the exact differences between the last review and current review.<br />
** A: This is also the reason that the Process clearly suggests there should be (TR) Working Drafts published when there are "significant changes that would benefit from review beyond the Working Group", rather than every day or only twice in the life of a specâŚ<br />
** A: TR Working Drafts are also useful for reviews since they provide a dated snapshot which can be recovered when the review comments are being discussed. Trying to discuss review comments against a document which has changed out of all recognition can be a frustrating and inefficient experience.<br />
<br />
== Issues ==<br />
<br />
* <strike>'''Is ''pre-CR'' the ''best'' term to describe a Process-2014 snapshot that precedes CR or is there a better term?'''<br />
** Proposals: 2014-LC, 2014-Snapshot, pre-CR snapshot, 2014-Review Doc, pre-CR Review Doc, ...<br />
** Proposal: Don't do this in order to demonstrate "wide review". A "Last call" for a document that has already been reviewed in development is appropriate. Waiting until you think the document is finished to ask for review is a bad idea.</strike> ''This issue has become moot with the passing of time.''<br />
<br />
* <strike>'''How can a group or individual be automatically notified when a document has been published at one of the transitions that could/should initiate the start of an early or wide review?''' For Process-2005 documents, the transitions of interest are FPWD, LCWD and CR and for Proc-Doc-2015 documents the transitions of interest are: FPWD, pre-CR, and CR.</strike> ''This Issue was resolved via the creation of the <code>[http://lists.w3.org/Archives/Public/public-review-announce public-review-announce]</code> e-mail list.''<br />
<br />
* '''For all processes''' Working Drafts should be relevant for review - and should identify which parts are new or newly stabilized or changed, to facilitate '''timely''' review.<br />
** Potential solution: when a document is published on /TR, announce its publication on a Public mail list. See a related [http://lists.w3.org/Archives/Public/public-w3process/2014Oct/0102.html Call for Consensus] to create such a list, deadline for comments is October 15].<br />
<br />
== Terminology and Abbreviations ==<br />
<br />
* '''pre-CR''' - This is a version of a Working Draft that is created to get wide review.<br />
** note that this is a bad way to get review. In general, features should be reviewed as they are developed. Waiting for a "Last Call" for most review means that when reviews suggest changes it is far harder to make them, due to a commonly observed and logical reluctance to break deployed systems or content. [[User:Charles|Charles McCathie Nevile]] ([[User talk:Charles|talk]]) 11:18, 13 October 2014 (UTC)<br />
<br />
* '''requesting group''' - a group that is requesting a review <br />
<br />
Abbreviations:<br />
<br />
* BP = Best Practices<br />
* CR = Candidate Recommendation<br />
* RfC = Request for Comments (aka Review Request)<br />
* [http://www.w3.org/TR/ TR] = Technical Report, i.e. a formal W3C publication.<br />
* WD = Working Draft<br />
<br />
== Enhancement Requests ==<br />
<br />
* See the [https://www.w3.org/wiki/Dashboard#Document_Review_Dashboard Document Review Dashboard] document for information about creating a dashboard type service to facilitate document reviews.</div>Plehegarhttps://www.w3.org/wiki/index.php?title=DocumentReview&diff=109134DocumentReview2019-05-02T13:42:25Z<p>Plehegar: /* Making reviews happen */</p>
<hr />
<div>Getting ''early'' and ''wide'' review of a document is very important yet in practice, it can be challenging. Rather than defining explicit mandatory steps for getting wide and constructive review, this document provides some considerations, guidelines and best practices that groups should follow.<br />
<br />
'''Feedback on this document is welcome, preferably by directly editing this document, by sending email to <code>[mailto:public-openw3c@w3.org public-openw3c@w3.org]</code> ([http://lists.w3.org/Archives/Public/public-openw3c/ archive]), or by tweeting to the [https://twitter.com/@openw3c @openw3c] twitter account.'''<br />
<br />
SeeAlso:<br />
<br />
* [http://www.w3.org/2014/11/getreview/ Tool to Assist with Calls for Specification Review]<br />
* [https://www.w3.org/2019/Process-20190301/ Process Document 2019]<br />
<br />
<br />
== Introduction ==<br />
<br />
Getting early review and feedback is important, especially reviews from those groups that have identified a document as a dependency, and the so-called ''horizontal groups''. It is also important to get review from other stakeholders including Web developers, technology providers and implementers not active in the Working Group, external groups and Standards organisations working on related areas, etc.<br />
<br />
In Process-2019, the focus is on actually getting evidence that wide review has occurred. The considerations, guidelines and Best Practices (BP) in this document should provide reasonable guidance for document review.<br />
<br />
== TL;DR: ==<br />
<br />
When you have published a First Public Working Draft, you should work through available "self-review" materials, and request review of your results, in at least the following areas. "Long enough*" before you request a transition to CR, you should do the same again, identifying substantive specification changes since the first review.<br />
<br />
The meaning of "Long enough*" depends on how many changes there are, and how clearly you have explained them. Pointing to 14 concise points for a small spec means a short time, pointing to 900 diffs from commits and hoping people understand them in a 300 page spec means it will take a '''long''' time to get review. If you have effectively identified issues for review during development, and got feedback on them, the review time will probably be shortened. It also depends how busy the groups are, so planning in advance is useful.<br />
<br />
;Accessibility<br />
:Work through [http://w3c.github.io/apa/fast/checklist.html this questionnaire] then ask [https://www.w3.org/WAI/APA/ APA] for review: [mailto:public-apa@w3.org public-apa@w3.org]<br />
;Architecture<br />
:Ask the [http://www.w3.org/2001/tag/ TAG] for review; see [https://tag.w3.org/workmode/ how to work with the TAG]. If you are developing javascript APIs you may also want to ask [mailto:public-script-coord@w3.org public-script-coord@w3.org], a technical discussion list shared by W3C and ECMA's TC 39.<br />
;Internationalisation<br />
:Work through the [[https://www.w3.org/International/techniques/developing-specs Checklist]], then request [http://www.w3.org/International/ i18n] review by email to [mailto:www-international@w3.org www-international@w3.org] (A public list watched by the Working Group). If for some reason you want a member-confidential review, you can ask on [mailto:member-i18n-core@w3.org member-i18n-core@w3.org] (a member-only list watched by the Working Group).<br />
;Privacy<br />
:Go through [https://www.w3.org/wiki/Privacy/Privacy_Considerations this checklist] and the [https://www.w3.org/TR/security-privacy-questionnaire/ privacy/security checklist], then ask the [http://www.w3.org/Privacy/ Privacy Interest Group for a review: [mailto:public-privacy@w3.org public-privacy@w3.org]<br />
;Security<br />
:Use your results from the [https://www.w3.org/TR/security-privacy-questionnaire/ privacy/security questionnaire] (see privacy), then ask the [http://www.w3.org/Security/wiki/IG Security IG] for review: [mailto:public-web-security@w3.org public-web-security@w3.org]<br />
;Groups listed in your charter<br />
:If there are groups listed in your charter as depending on some specification, you should ask them too.<br />
<br />
=== Read on⌠===<br />
You should familiarise yourself with the rest of this document. This section is just a quick reminder for when you are in the middle of doing the work.<br />
<br />
== Considerations and Best Practices ==<br />
<br />
Among the considerations and best practices, regardless of the ''type of review'' (early, thorough wide review, etc.) are:<br />
=== Who to ask for review?===<br />
<br />
* '''Which group(s) should be asked to review a document?''' All group charters should include information about the groups and external liaisons that are interested in particular documents. At a minimum, those groups should be included in all review request for their related document(s). Additionally, it may be appropriate to explicitly seek review from others such as: other Consortium groups; external organizations and SSOs; ''stakeholders'' such as implementers, testing and interop experts, application developers, etc. If a document is explicitly identified as a joint deliverable with another group, it is especially important to make sure that group is included in all review requests.<br />
<br />
* '''Which Horizontal Groups should be asked to request a review?''' This can be a bit tricky because in some cases the set of relevant of ''horizontal groups'' (enumerated below) should be relatively obvious but in other cases it might not be. For example, Working Group Charters often explicitly identify Horizontal Group dependencies, but post-charter development may introduce features that require review by Horizontal Groups not called out in the charter. - SNZ<br />
** '''BP:''' if in doubt, before formally asking a horizontal group to review a document, talk to them informally (f.ex. via e-mail).<br />
<br />
''(comment): I agree that it may not be obvious that a document needs horizontal review, but I tend to take a stronger line: even if you have not identified a ''horizontal group'' dependency, you should always discuss whether a review is necessary or even request a review (saying if you think there are no issues of interest to the given group). --[[User:Aphillip|Addison Phillips]] ([[User talk:Aphillip|talk]])''<br />
<br />
* '''What should be done if it appears a document might be relevant to a [http://www.w3.org/2001/11/StdLiaison.html W3C liaison] but the liaison is not explicitly listed in the group's charter?''' The Chair(s) and Team Contacts should consult with their group, and if there is consensus within the group to contact the liaison, then that external group should be included in all review requests.<br />
** '''BP:''' That group should be included in review requests unless they ask not to be --CMN<br />
<br />
=== When should review be requested? ===<br />
<br />
* '''When is a group ''required'' to seek wide review of a Process-2019 document?''' For a document to enter CR, the group must show the document has had wide review. The requesting group is free to determine the timing for review requests.<br />
<br />
* '''When should reviews by Horizontal Groups be scheduled?''' Horizontal Groups are very often resource limited. This means that they can often only do one review and may have difficulty scheduling that review in a timely way. Secondly, to do a reasonable review, they need a document that is pretty stable, but still flexible enough to allow changes where issues are identified. -SNZ<br />
**'''BP:''' Contact the chair of each relevant Horizontal Group to arrange a suitable time in their schedule to review the document. - SNZ<br />
<br />
* '''What circumstances should trigger a RfC?''' When a new feature is added to a document after its FPWD is published or after the document has already been a target of a wide review, a group should seek wide review of that new feature. <br />
** Other reasons to consider wide review include: some other group expresses keen interest in a document.<br />
<br />
* '''What part of a document should be reviewed and when?''' The general rule of thumb is to get review ''early and often''.<br />
** '''BP:''' Ensure that each section or feature is reviewed when it is considered stable (this enables changes to be made early, which lowers the risk that deployed legacy will impact the possibilities for fixing something).<br />
<br />
=== Making reviews happen ===<br />
* '''Length of the Comment Period.''' The duration for comments (aka ''comment period'') depends on a number of factors including the version of the Process Document being used. As such, consult the Process being used.<br />
** '''BP:''' before a group asks another group to review a document, the requesting group should work with the review group to determine a mutually agreeable review timeline.<br />
<br />
* '''How to initiate a review request.''' Review requests should be sent to the review groups' Public mail list(s).<br />
** '''BP:''' please avoid cross-posting by using Bcc: if necessary.<br />
** '''BP:''' use the RfC template below.<br />
<br />
* '''Announce LCWD and pre-CR publications on the chairs list.''' The group Chair or W3C staff should announce all LCWD and pre-CR publications on the [https://lists.w3.org/Archives/Member/chairs/ chairs] list.<br />
<br />
* '''Announce all Requests for Review (f.ex. LCWD and pre-CR publications) on the <code>[http://lists.w3.org/Archives/Public/public-review-announce/ public-review-announce] e-mail list</code>'''. This announcement may be made by a group Chair, Consortium Staff, Editor or any other designated member of a group.<br />
** '''BP:''' use the RfC template below.<br />
<br />
* '''Use Public e-mail lists for review feedback.''' The requesting group's Public mail list should be used for review feedback.<br />
** '''BP:''' use the requesting group's main Public mail list for comments and do not use (nor create) a list whose sole purpose is for comments.<br />
<br />
* '''How can a group get acknowledgement that some person and/or group actually reviewed a document?''' Naturally, this isn't an issue if the reviewing group and/or individuals in the reviewing group actually provides review comments. However, in some cases, this can be somewhat difficult to determine and achieve (f.ex the reviewing group is small, the overlap in scope is minimal, etc.). <br />
** '''BP:''' when asking for review, explicitly ask the reviewing group to submit all feedback, even if the feedback is something like "I read it and have no comments".<br />
<br />
== Request for Comments (RfC) Template ==<br />
<br />
See the [http://www.w3.org/2014/11/getreview/ tool to assist with calls for specification review].<br />
<br />
=== General Information ===<br />
<br />
A RfC should include the following general information:<br />
<br />
* Name of the group seeking comments.<br />
<br />
* Deadline for comments.<br />
<br />
* <code>Subject:</code> header: include the maturity level, name of the document and document maturity level of the document<br />
** '''BP''': <code>Subject: RfC: FPWD of ''Name of Spec''; deadline MMM DD</code>.<br />
<br />
* Mail list for comments; include the mailto: address plus a link to the Public mail list archive<br />
** '''BP''': avoid cross-posting to multiple lists (and if this must be done, use Bcc:), except for the i18n WG, which needs to track issues on its technical list as well. (i18n WG members cannot subscribe to all the lists of the groups they review specs for.)<br />
<br />
* Alternate instructions for providing commentary ''(if needed)''. Some groups use bugzilla or github as a means of communication and for tracking issues. --[[User:Aphillip|Addison Phillips]] ([[User talk:Aphillip|talk]]) If your main or preferred tracking location is a database, make that clear in the SOD, since moving and tracking comments between mail threads and databases can waste time for both the reviewer and the reviewed group.<br />
<br />
* <code>Reply-to:</code> header: set the <code>Reply-to:</code> header to the mail list where all comments should be sent<br />
<br />
* State that all review be acknowledged, even if a reviewer or group has reviewed the document and has "no comments".<br />
<br />
=== Information for Each Document ===<br />
<br />
For each document that will be reviewed, provide at least:<br />
<br />
* Document title<br />
<br />
* URL<br />
** '''BP''': the contents of the document should be stable (i.e. not changed) during the review period. <br />
** '''BP''': if the contents of the document might change during the review, identify the specific section(s) that might change; or consider postponing the review until after those sections are stable.<br />
<br />
* Maturity level: FPWD, LCWD (for Process-2005 documents), pre-CR (for Process-2015 documents), CR, ...<br />
<br />
* Scope of the review: this can be the entire document, specific sections, specific issues, etc.<br />
** '''BP''': Identify the specific sections of the document that are newly stabilised, as well as those already considered stable. This allows reviewers who follw "at a distance" to focus on what's new, and allows new reviewers to focus on things that are ready for review, instead of providing a lot of comments on sections that are likely to shift.<br />
** '''BP''': Specifications should include information about stability and known implementation on a "section by section" basis.<br />
<br />
* If a review was previously requested, include the URL of a diff, using the previous version of the document as the diff's reference/base.<br />
** '''BP''': use [http://services.w3.org/htmldiff W3C HTML Diff service]<br />
** '''BP''': also provide a human-authored summary of the changes.<br />
<br />
=== Example Request for Comments ===<br />
<br />
Here are some example RfCs:<br />
<br />
* [http://lists.w3.org/Archives/Public/public-html/2014Sep/0099.html TTML Text and Imaging ... preCR]<br />
* [http://lists.w3.org/Archives/Public/public-review-announce/2014Nov/0002.html Pointer Events LCWD]<br />
<br />
== Horizontal Groups ==<br />
<br />
The consortium's so-called ''Horizontal Groups'' are groups that include review and coordination functions in their charter. Typically, these groups consist of individuals that can provide advice and guidance (to other groups) regarding their domain expertise.<br />
<br />
Groups with a horizontal review function, including their mail list are (alphabetical order):<br />
<br />
* [https://www.w3.org/WAI/APA/ Accessible Platform Architectures Working Group]; [https://lists.w3.org/Archives/Public/public-apa/ public-apa]; [https://www.w3.org/WAI/APA/wiki/Spec_Review APA Spec Review tracking]<br />
* [http://www.w3.org/International/ Internationalization Working Group]; [http://lists.w3.org/Archives/Public/www-international/ www-international] Reviews by Internationalization generally also involve the [http://www.w3.org/International/ig Interest Group], but are arranged through the WG.<br />
* [http://www.w3.org/Privacy/ Privacy Interest Group]; [http://lists.w3.org/Archives/Public/public-privacy/ public-privacy]<br />
* [http://www.w3.org/2001/tag/ Technical Architecture Group (TAG)]; [http://lists.w3.org/Archives/Public/www-tag/ www-tag]<br />
* [http://www.w3.org/2008/webapps/ Web API Consistency and Web IDL Conformance]; [http://lists.w3.org/Archives/Public/public-script-coord/ public-script-coord]; (this is a Web Platform WG list that liases with ECMA's TC-39)<br />
* [http://www.w3.org/WAI/IG/ Web Accessibility Interest Group]; [http://lists.w3.org/Archives/Public/w3c-wai-ig/ w3c-wai-ig]<br />
* [http://www.w3.org/Security/wiki/IG Web Security Interest Group]; [http://lists.w3.org/Archives/Public/public-web-security/ public-web-security]<br />
<br />
=== Review Resources ===<br />
<br />
* Internationalization:<br />
** [https://www.w3.org/International/review-request I18n Request a review]<br />
** [http://w3c.github.io/i18n-activity/reviews/shortchecklist Short i18n review checklist]<br />
** [https://www.w3.org/International/techniques/developing-specs Expanding collapsing detailed checklist], generated from [https://w3c.github.io/bp-i18n-specdev/ ''Internationalization Best Practices for Spec Developers'']<br />
* Security/Privacy:<br />
** [https://www.w3.org/TR/security-privacy-questionnaire/ ''Self-Review Questionnaire: Security and Privacy''; Mike West]<br />
** [http://www.rfc-editor.org/rfc/rfc3552.txt Guidelines for Writing RFC Text on Security Considerations (RFC3552)]<br />
** [https://w3c.github.io/fingerprinting-guidance/ Mitigating Browser Fingerprinting in Web Specifications]<br />
** [http://gregnorc.github.io/ping-privacy-questions/ Ping-privacy-questions]<br />
** [https://yrlesru.github.io/SPA/ ''Specification Privacy Assessment (SPA) (Creating Privacy Considerations for W3C Technical Specifications)''; Frank Dawson]<br />
* Technical Architecture:<br />
** [https://www.w3.org/2001/tag/doc/webcomponents-design-guidelines/ Guidelines for creating web platform compatible components]<br />
** [https://www.w3.org/2001/tag/doc/promises-guide Writing Promise-Using Specifications]<br />
** [https://w3ctag.github.io/design-principles/ Client-side API Design Principles]<br />
** [https://www.w3.org/2001/tag/doc/capability-urls/ Good Practices for Capability URLs]<br />
** [https://github.com/w3ctag/spec-reviews TAG Repository for reviews]<br />
* Web Accessibility:<br />
** [http://w3c.github.io/apa/fast/checklist.html Framework for Accessibility in the Specification of Technologies Checklist; APA WG]<br />
** [https://www.w3.org/TR/media-accessibility-reqs/ Media Accessibility User Requirements; PFWG]<br />
<br />
== FAQ ==<br />
<br />
* '''Q: When is the best time to seek ''early'' review?'''<br />
** A: For a number factors (including document maturity, implementation status, etc.), there is no ''best time'' that applies to ''all'' documents. However, for most documents, after a ''First Public Working Draft'' is published is generally a good time to seek review of a specification.<br />
<br />
* '''Q: Is some type of ''security'' and/or ''privacy'' review mandatory before a ''First Public Working Draft'' is published?'''<br />
** A: Strictly speaking, the answer is No. However, getting early review for documents with features that might have security and/or privacy implications is '''strongly encouraged'''. See the [https://www.w3.org/wiki/DocumentReview#Horizontal_Groups Horizontal Groups] section below for information about security and privacy groups that can provide review and related review resources. <br />
<br />
* '''Q: Does a group need to prove its documents have had wide review before proceeding to CR?'''<br />
** A: The answer is yes, since Process-2019.<br />
<br />
* '''Q: How does a group prove its documents have had wide review before proceeding to CR?'''<br />
** A: See [http://lists.w3.org/Archives/Public/public-w3process/2014Oct/0133.html How to work with (experiment with) Wide Review] -SNZ<br />
** A: Keep a Disposition of Comments (DoC) Document that shows review comments and acknowledgements that have been received. It is the distribution of the reviewers that shows the review has been wide.-SNZ<br />
** A: Ask the W3C Team if your proposed approach is likely to meet the requirements. -SNZ<br />
<br />
* '''Q: Is there such a thing as too many reviews?'''<br />
** A: Not really<br />
<br />
* '''Q: Is it possible to make too many requests for review?'''<br />
** A: unfortunately, yes there is. Multiple requests for reviews can quickly result in a situation of diminishing returns. To help address this, subsequent review requests should clearly identify the exact differences between the last review and current review.<br />
** A: This is also the reason that the Process clearly suggests there should be (TR) Working Drafts published when there are "significant changes that would benefit from review beyond the Working Group", rather than every day or only twice in the life of a specâŚ<br />
** A: TR Working Drafts are also useful for reviews since they provide a dated snapshot which can be recovered when the review comments are being discussed. Trying to discuss review comments against a document which has changed out of all recognition can be a frustrating and inefficient experience.<br />
<br />
== Issues ==<br />
<br />
* <strike>'''Is ''pre-CR'' the ''best'' term to describe a Process-2014 snapshot that precedes CR or is there a better term?'''<br />
** Proposals: 2014-LC, 2014-Snapshot, pre-CR snapshot, 2014-Review Doc, pre-CR Review Doc, ...<br />
** Proposal: Don't do this in order to demonstrate "wide review". A "Last call" for a document that has already been reviewed in development is appropriate. Waiting until you think the document is finished to ask for review is a bad idea.</strike> ''This issue has become moot with the passing of time.''<br />
<br />
* <strike>'''How can a group or individual be automatically notified when a document has been published at one of the transitions that could/should initiate the start of an early or wide review?''' For Process-2005 documents, the transitions of interest are FPWD, LCWD and CR and for Proc-Doc-2015 documents the transitions of interest are: FPWD, pre-CR, and CR.</strike> ''This Issue was resolved via the creation of the <code>[http://lists.w3.org/Archives/Public/public-review-announce public-review-announce]</code> e-mail list.''<br />
<br />
* '''For all processes''' Working Drafts should be relevant for review - and should identify which parts are new or newly stabilized or changed, to facilitate '''timely''' review.<br />
** Potential solution: when a document is published on /TR, announce its publication on a Public mail list. See a related [http://lists.w3.org/Archives/Public/public-w3process/2014Oct/0102.html Call for Consensus] to create such a list, deadline for comments is October 15].<br />
<br />
== Terminology and Abbreviations ==<br />
<br />
* '''pre-CR''' - This is a version of a Working Draft that is created to get wide review.<br />
** note that this is a bad way to get review. In general, features should be reviewed as they are developed. Waiting for a "Last Call" for most review means that when reviews suggest changes it is far harder to make them, due to a commonly observed and logical reluctance to break deployed systems or content. [[User:Charles|Charles McCathie Nevile]] ([[User talk:Charles|talk]]) 11:18, 13 October 2014 (UTC)<br />
<br />
* '''requesting group''' - a group that is requesting a review <br />
<br />
Abbreviations:<br />
<br />
* BP = Best Practices<br />
* CR = Candidate Recommendation<br />
* RfC = Request for Comments (aka Review Request)<br />
* [http://www.w3.org/TR/ TR] = Technical Report, i.e. a formal W3C publication.<br />
* WD = Working Draft<br />
<br />
== Enhancement Requests ==<br />
<br />
* See the [https://www.w3.org/wiki/Dashboard#Document_Review_Dashboard Document Review Dashboard] document for information about creating a dashboard type service to facilitate document reviews.</div>Plehegarhttps://www.w3.org/wiki/index.php?title=DocumentReview&diff=109133DocumentReview2019-05-02T13:41:41Z<p>Plehegar: Process 2019</p>
<hr />
<div>Getting ''early'' and ''wide'' review of a document is very important yet in practice, it can be challenging. Rather than defining explicit mandatory steps for getting wide and constructive review, this document provides some considerations, guidelines and best practices that groups should follow.<br />
<br />
'''Feedback on this document is welcome, preferably by directly editing this document, by sending email to <code>[mailto:public-openw3c@w3.org public-openw3c@w3.org]</code> ([http://lists.w3.org/Archives/Public/public-openw3c/ archive]), or by tweeting to the [https://twitter.com/@openw3c @openw3c] twitter account.'''<br />
<br />
SeeAlso:<br />
<br />
* [http://www.w3.org/2014/11/getreview/ Tool to Assist with Calls for Specification Review]<br />
* [https://www.w3.org/2019/Process-20190301/ Process Document 2019]<br />
<br />
<br />
== Introduction ==<br />
<br />
Getting early review and feedback is important, especially reviews from those groups that have identified a document as a dependency, and the so-called ''horizontal groups''. It is also important to get review from other stakeholders including Web developers, technology providers and implementers not active in the Working Group, external groups and Standards organisations working on related areas, etc.<br />
<br />
In Process-2019, the focus is on actually getting evidence that wide review has occurred. The considerations, guidelines and Best Practices (BP) in this document should provide reasonable guidance for document review.<br />
<br />
== TL;DR: ==<br />
<br />
When you have published a First Public Working Draft, you should work through available "self-review" materials, and request review of your results, in at least the following areas. "Long enough*" before you request a transition to CR, you should do the same again, identifying substantive specification changes since the first review.<br />
<br />
The meaning of "Long enough*" depends on how many changes there are, and how clearly you have explained them. Pointing to 14 concise points for a small spec means a short time, pointing to 900 diffs from commits and hoping people understand them in a 300 page spec means it will take a '''long''' time to get review. If you have effectively identified issues for review during development, and got feedback on them, the review time will probably be shortened. It also depends how busy the groups are, so planning in advance is useful.<br />
<br />
;Accessibility<br />
:Work through [http://w3c.github.io/apa/fast/checklist.html this questionnaire] then ask [https://www.w3.org/WAI/APA/ APA] for review: [mailto:public-apa@w3.org public-apa@w3.org]<br />
;Architecture<br />
:Ask the [http://www.w3.org/2001/tag/ TAG] for review; see [https://tag.w3.org/workmode/ how to work with the TAG]. If you are developing javascript APIs you may also want to ask [mailto:public-script-coord@w3.org public-script-coord@w3.org], a technical discussion list shared by W3C and ECMA's TC 39.<br />
;Internationalisation<br />
:Work through the [[https://www.w3.org/International/techniques/developing-specs Checklist]], then request [http://www.w3.org/International/ i18n] review by email to [mailto:www-international@w3.org www-international@w3.org] (A public list watched by the Working Group). If for some reason you want a member-confidential review, you can ask on [mailto:member-i18n-core@w3.org member-i18n-core@w3.org] (a member-only list watched by the Working Group).<br />
;Privacy<br />
:Go through [https://www.w3.org/wiki/Privacy/Privacy_Considerations this checklist] and the [https://www.w3.org/TR/security-privacy-questionnaire/ privacy/security checklist], then ask the [http://www.w3.org/Privacy/ Privacy Interest Group for a review: [mailto:public-privacy@w3.org public-privacy@w3.org]<br />
;Security<br />
:Use your results from the [https://www.w3.org/TR/security-privacy-questionnaire/ privacy/security questionnaire] (see privacy), then ask the [http://www.w3.org/Security/wiki/IG Security IG] for review: [mailto:public-web-security@w3.org public-web-security@w3.org]<br />
;Groups listed in your charter<br />
:If there are groups listed in your charter as depending on some specification, you should ask them too.<br />
<br />
=== Read on⌠===<br />
You should familiarise yourself with the rest of this document. This section is just a quick reminder for when you are in the middle of doing the work.<br />
<br />
== Considerations and Best Practices ==<br />
<br />
Among the considerations and best practices, regardless of the ''type of review'' (early, thorough wide review, etc.) are:<br />
=== Who to ask for review?===<br />
<br />
* '''Which group(s) should be asked to review a document?''' All group charters should include information about the groups and external liaisons that are interested in particular documents. At a minimum, those groups should be included in all review request for their related document(s). Additionally, it may be appropriate to explicitly seek review from others such as: other Consortium groups; external organizations and SSOs; ''stakeholders'' such as implementers, testing and interop experts, application developers, etc. If a document is explicitly identified as a joint deliverable with another group, it is especially important to make sure that group is included in all review requests.<br />
<br />
* '''Which Horizontal Groups should be asked to request a review?''' This can be a bit tricky because in some cases the set of relevant of ''horizontal groups'' (enumerated below) should be relatively obvious but in other cases it might not be. For example, Working Group Charters often explicitly identify Horizontal Group dependencies, but post-charter development may introduce features that require review by Horizontal Groups not called out in the charter. - SNZ<br />
** '''BP:''' if in doubt, before formally asking a horizontal group to review a document, talk to them informally (f.ex. via e-mail).<br />
<br />
''(comment): I agree that it may not be obvious that a document needs horizontal review, but I tend to take a stronger line: even if you have not identified a ''horizontal group'' dependency, you should always discuss whether a review is necessary or even request a review (saying if you think there are no issues of interest to the given group). --[[User:Aphillip|Addison Phillips]] ([[User talk:Aphillip|talk]])''<br />
<br />
* '''What should be done if it appears a document might be relevant to a [http://www.w3.org/2001/11/StdLiaison.html W3C liaison] but the liaison is not explicitly listed in the group's charter?''' The Chair(s) and Team Contacts should consult with their group, and if there is consensus within the group to contact the liaison, then that external group should be included in all review requests.<br />
** '''BP:''' That group should be included in review requests unless they ask not to be --CMN<br />
<br />
=== When should review be requested? ===<br />
<br />
* '''When is a group ''required'' to seek wide review of a Process-2019 document?''' For a document to enter CR, the group must show the document has had wide review. The requesting group is free to determine the timing for review requests.<br />
<br />
* '''When should reviews by Horizontal Groups be scheduled?''' Horizontal Groups are very often resource limited. This means that they can often only do one review and may have difficulty scheduling that review in a timely way. Secondly, to do a reasonable review, they need a document that is pretty stable, but still flexible enough to allow changes where issues are identified. -SNZ<br />
**'''BP:''' Contact the chair of each relevant Horizontal Group to arrange a suitable time in their schedule to review the document. - SNZ<br />
<br />
* '''What circumstances should trigger a RfC?''' When a new feature is added to a document after its FPWD is published or after the document has already been a target of a wide review, a group should seek wide review of that new feature. <br />
** Other reasons to consider wide review include: some other group expresses keen interest in a document.<br />
<br />
* '''What part of a document should be reviewed and when?''' The general rule of thumb is to get review ''early and often''.<br />
** '''BP:''' Ensure that each section or feature is reviewed when it is considered stable (this enables changes to be made early, which lowers the risk that deployed legacy will impact the possibilities for fixing something).<br />
<br />
=== Making reviews happen ===<br />
* '''Length of the Comment Period.''' The duration for comments (aka ''comment period'') depends on a number of factors including the version of the Process Document being used. As such, consult the version of the Process being used: [http://www.w3.org/2005/10/Process-20051014/ Process-2005] or [http://www.w3.org/2015/Process-20150901/ Process-2015].<br />
** '''BP:''' before a group asks another group to review a document, the requesting group should work with the review group to determine a mutually agreeable review timeline.<br />
<br />
* '''How to initiate a review request.''' Review requests should be sent to the review groups' Public mail list(s).<br />
** '''BP:''' please avoid cross-posting by using Bcc: if necessary.<br />
** '''BP:''' use the RfC template below.<br />
<br />
* '''Announce LCWD and pre-CR publications on the chairs list.''' The group Chair or W3C staff should announce all LCWD and pre-CR publications on the [https://lists.w3.org/Archives/Member/chairs/ chairs] list.<br />
<br />
* '''Announce all Requests for Review (f.ex. LCWD and pre-CR publications) on the <code>[http://lists.w3.org/Archives/Public/public-review-announce/ public-review-announce] e-mail list</code>'''. This announcement may be made by a group Chair, Consortium Staff, Editor or any other designated member of a group.<br />
** '''BP:''' use the RfC template below.<br />
<br />
* '''Use Public e-mail lists for review feedback.''' The requesting group's Public mail list should be used for review feedback.<br />
** '''BP:''' use the requesting group's main Public mail list for comments and do not use (nor create) a list whose sole purpose is for comments.<br />
<br />
* '''How can a group get acknowledgement that some person and/or group actually reviewed a document?''' Naturally, this isn't an issue if the reviewing group and/or individuals in the reviewing group actually provides review comments. However, in some cases, this can be somewhat difficult to determine and achieve (f.ex the reviewing group is small, the overlap in scope is minimal, etc.). <br />
** '''BP:''' when asking for review, explicitly ask the reviewing group to submit all feedback, even if the feedback is something like "I read it and have no comments".<br />
<br />
== Request for Comments (RfC) Template ==<br />
<br />
See the [http://www.w3.org/2014/11/getreview/ tool to assist with calls for specification review].<br />
<br />
=== General Information ===<br />
<br />
A RfC should include the following general information:<br />
<br />
* Name of the group seeking comments.<br />
<br />
* Deadline for comments.<br />
<br />
* <code>Subject:</code> header: include the maturity level, name of the document and document maturity level of the document<br />
** '''BP''': <code>Subject: RfC: FPWD of ''Name of Spec''; deadline MMM DD</code>.<br />
<br />
* Mail list for comments; include the mailto: address plus a link to the Public mail list archive<br />
** '''BP''': avoid cross-posting to multiple lists (and if this must be done, use Bcc:), except for the i18n WG, which needs to track issues on its technical list as well. (i18n WG members cannot subscribe to all the lists of the groups they review specs for.)<br />
<br />
* Alternate instructions for providing commentary ''(if needed)''. Some groups use bugzilla or github as a means of communication and for tracking issues. --[[User:Aphillip|Addison Phillips]] ([[User talk:Aphillip|talk]]) If your main or preferred tracking location is a database, make that clear in the SOD, since moving and tracking comments between mail threads and databases can waste time for both the reviewer and the reviewed group.<br />
<br />
* <code>Reply-to:</code> header: set the <code>Reply-to:</code> header to the mail list where all comments should be sent<br />
<br />
* State that all review be acknowledged, even if a reviewer or group has reviewed the document and has "no comments".<br />
<br />
=== Information for Each Document ===<br />
<br />
For each document that will be reviewed, provide at least:<br />
<br />
* Document title<br />
<br />
* URL<br />
** '''BP''': the contents of the document should be stable (i.e. not changed) during the review period. <br />
** '''BP''': if the contents of the document might change during the review, identify the specific section(s) that might change; or consider postponing the review until after those sections are stable.<br />
<br />
* Maturity level: FPWD, LCWD (for Process-2005 documents), pre-CR (for Process-2015 documents), CR, ...<br />
<br />
* Scope of the review: this can be the entire document, specific sections, specific issues, etc.<br />
** '''BP''': Identify the specific sections of the document that are newly stabilised, as well as those already considered stable. This allows reviewers who follw "at a distance" to focus on what's new, and allows new reviewers to focus on things that are ready for review, instead of providing a lot of comments on sections that are likely to shift.<br />
** '''BP''': Specifications should include information about stability and known implementation on a "section by section" basis.<br />
<br />
* If a review was previously requested, include the URL of a diff, using the previous version of the document as the diff's reference/base.<br />
** '''BP''': use [http://services.w3.org/htmldiff W3C HTML Diff service]<br />
** '''BP''': also provide a human-authored summary of the changes.<br />
<br />
=== Example Request for Comments ===<br />
<br />
Here are some example RfCs:<br />
<br />
* [http://lists.w3.org/Archives/Public/public-html/2014Sep/0099.html TTML Text and Imaging ... preCR]<br />
* [http://lists.w3.org/Archives/Public/public-review-announce/2014Nov/0002.html Pointer Events LCWD]<br />
<br />
== Horizontal Groups ==<br />
<br />
The consortium's so-called ''Horizontal Groups'' are groups that include review and coordination functions in their charter. Typically, these groups consist of individuals that can provide advice and guidance (to other groups) regarding their domain expertise.<br />
<br />
Groups with a horizontal review function, including their mail list are (alphabetical order):<br />
<br />
* [https://www.w3.org/WAI/APA/ Accessible Platform Architectures Working Group]; [https://lists.w3.org/Archives/Public/public-apa/ public-apa]; [https://www.w3.org/WAI/APA/wiki/Spec_Review APA Spec Review tracking]<br />
* [http://www.w3.org/International/ Internationalization Working Group]; [http://lists.w3.org/Archives/Public/www-international/ www-international] Reviews by Internationalization generally also involve the [http://www.w3.org/International/ig Interest Group], but are arranged through the WG.<br />
* [http://www.w3.org/Privacy/ Privacy Interest Group]; [http://lists.w3.org/Archives/Public/public-privacy/ public-privacy]<br />
* [http://www.w3.org/2001/tag/ Technical Architecture Group (TAG)]; [http://lists.w3.org/Archives/Public/www-tag/ www-tag]<br />
* [http://www.w3.org/2008/webapps/ Web API Consistency and Web IDL Conformance]; [http://lists.w3.org/Archives/Public/public-script-coord/ public-script-coord]; (this is a Web Platform WG list that liases with ECMA's TC-39)<br />
* [http://www.w3.org/WAI/IG/ Web Accessibility Interest Group]; [http://lists.w3.org/Archives/Public/w3c-wai-ig/ w3c-wai-ig]<br />
* [http://www.w3.org/Security/wiki/IG Web Security Interest Group]; [http://lists.w3.org/Archives/Public/public-web-security/ public-web-security]<br />
<br />
=== Review Resources ===<br />
<br />
* Internationalization:<br />
** [https://www.w3.org/International/review-request I18n Request a review]<br />
** [http://w3c.github.io/i18n-activity/reviews/shortchecklist Short i18n review checklist]<br />
** [https://www.w3.org/International/techniques/developing-specs Expanding collapsing detailed checklist], generated from [https://w3c.github.io/bp-i18n-specdev/ ''Internationalization Best Practices for Spec Developers'']<br />
* Security/Privacy:<br />
** [https://www.w3.org/TR/security-privacy-questionnaire/ ''Self-Review Questionnaire: Security and Privacy''; Mike West]<br />
** [http://www.rfc-editor.org/rfc/rfc3552.txt Guidelines for Writing RFC Text on Security Considerations (RFC3552)]<br />
** [https://w3c.github.io/fingerprinting-guidance/ Mitigating Browser Fingerprinting in Web Specifications]<br />
** [http://gregnorc.github.io/ping-privacy-questions/ Ping-privacy-questions]<br />
** [https://yrlesru.github.io/SPA/ ''Specification Privacy Assessment (SPA) (Creating Privacy Considerations for W3C Technical Specifications)''; Frank Dawson]<br />
* Technical Architecture:<br />
** [https://www.w3.org/2001/tag/doc/webcomponents-design-guidelines/ Guidelines for creating web platform compatible components]<br />
** [https://www.w3.org/2001/tag/doc/promises-guide Writing Promise-Using Specifications]<br />
** [https://w3ctag.github.io/design-principles/ Client-side API Design Principles]<br />
** [https://www.w3.org/2001/tag/doc/capability-urls/ Good Practices for Capability URLs]<br />
** [https://github.com/w3ctag/spec-reviews TAG Repository for reviews]<br />
* Web Accessibility:<br />
** [http://w3c.github.io/apa/fast/checklist.html Framework for Accessibility in the Specification of Technologies Checklist; APA WG]<br />
** [https://www.w3.org/TR/media-accessibility-reqs/ Media Accessibility User Requirements; PFWG]<br />
<br />
== FAQ ==<br />
<br />
* '''Q: When is the best time to seek ''early'' review?'''<br />
** A: For a number factors (including document maturity, implementation status, etc.), there is no ''best time'' that applies to ''all'' documents. However, for most documents, after a ''First Public Working Draft'' is published is generally a good time to seek review of a specification.<br />
<br />
* '''Q: Is some type of ''security'' and/or ''privacy'' review mandatory before a ''First Public Working Draft'' is published?'''<br />
** A: Strictly speaking, the answer is No. However, getting early review for documents with features that might have security and/or privacy implications is '''strongly encouraged'''. See the [https://www.w3.org/wiki/DocumentReview#Horizontal_Groups Horizontal Groups] section below for information about security and privacy groups that can provide review and related review resources. <br />
<br />
* '''Q: Does a group need to prove its documents have had wide review before proceeding to CR?'''<br />
** A: The answer is yes, since Process-2019.<br />
<br />
* '''Q: How does a group prove its documents have had wide review before proceeding to CR?'''<br />
** A: See [http://lists.w3.org/Archives/Public/public-w3process/2014Oct/0133.html How to work with (experiment with) Wide Review] -SNZ<br />
** A: Keep a Disposition of Comments (DoC) Document that shows review comments and acknowledgements that have been received. It is the distribution of the reviewers that shows the review has been wide.-SNZ<br />
** A: Ask the W3C Team if your proposed approach is likely to meet the requirements. -SNZ<br />
<br />
* '''Q: Is there such a thing as too many reviews?'''<br />
** A: Not really<br />
<br />
* '''Q: Is it possible to make too many requests for review?'''<br />
** A: unfortunately, yes there is. Multiple requests for reviews can quickly result in a situation of diminishing returns. To help address this, subsequent review requests should clearly identify the exact differences between the last review and current review.<br />
** A: This is also the reason that the Process clearly suggests there should be (TR) Working Drafts published when there are "significant changes that would benefit from review beyond the Working Group", rather than every day or only twice in the life of a specâŚ<br />
** A: TR Working Drafts are also useful for reviews since they provide a dated snapshot which can be recovered when the review comments are being discussed. Trying to discuss review comments against a document which has changed out of all recognition can be a frustrating and inefficient experience.<br />
<br />
== Issues ==<br />
<br />
* <strike>'''Is ''pre-CR'' the ''best'' term to describe a Process-2014 snapshot that precedes CR or is there a better term?'''<br />
** Proposals: 2014-LC, 2014-Snapshot, pre-CR snapshot, 2014-Review Doc, pre-CR Review Doc, ...<br />
** Proposal: Don't do this in order to demonstrate "wide review". A "Last call" for a document that has already been reviewed in development is appropriate. Waiting until you think the document is finished to ask for review is a bad idea.</strike> ''This issue has become moot with the passing of time.''<br />
<br />
* <strike>'''How can a group or individual be automatically notified when a document has been published at one of the transitions that could/should initiate the start of an early or wide review?''' For Process-2005 documents, the transitions of interest are FPWD, LCWD and CR and for Proc-Doc-2015 documents the transitions of interest are: FPWD, pre-CR, and CR.</strike> ''This Issue was resolved via the creation of the <code>[http://lists.w3.org/Archives/Public/public-review-announce public-review-announce]</code> e-mail list.''<br />
<br />
* '''For all processes''' Working Drafts should be relevant for review - and should identify which parts are new or newly stabilized or changed, to facilitate '''timely''' review.<br />
** Potential solution: when a document is published on /TR, announce its publication on a Public mail list. See a related [http://lists.w3.org/Archives/Public/public-w3process/2014Oct/0102.html Call for Consensus] to create such a list, deadline for comments is October 15].<br />
<br />
== Terminology and Abbreviations ==<br />
<br />
* '''pre-CR''' - This is a version of a Working Draft that is created to get wide review.<br />
** note that this is a bad way to get review. In general, features should be reviewed as they are developed. Waiting for a "Last Call" for most review means that when reviews suggest changes it is far harder to make them, due to a commonly observed and logical reluctance to break deployed systems or content. [[User:Charles|Charles McCathie Nevile]] ([[User talk:Charles|talk]]) 11:18, 13 October 2014 (UTC)<br />
<br />
* '''requesting group''' - a group that is requesting a review <br />
<br />
Abbreviations:<br />
<br />
* BP = Best Practices<br />
* CR = Candidate Recommendation<br />
* RfC = Request for Comments (aka Review Request)<br />
* [http://www.w3.org/TR/ TR] = Technical Report, i.e. a formal W3C publication.<br />
* WD = Working Draft<br />
<br />
== Enhancement Requests ==<br />
<br />
* See the [https://www.w3.org/wiki/Dashboard#Document_Review_Dashboard Document Review Dashboard] document for information about creating a dashboard type service to facilitate document reviews.</div>Plehegarhttps://www.w3.org/wiki/index.php?title=DocumentReview&diff=109132DocumentReview2019-05-02T13:40:10Z<p>Plehegar: </p>
<hr />
<div>Getting ''early'' and ''wide'' review of a document is very important yet in practice, it can be challenging. Rather than defining explicit mandatory steps for getting wide and constructive review, this document provides some considerations, guidelines and best practices that groups should follow.<br />
<br />
'''Feedback on this document is welcome, preferably by directly editing this document, by sending email to <code>[mailto:public-openw3c@w3.org public-openw3c@w3.org]</code> ([http://lists.w3.org/Archives/Public/public-openw3c/ archive]), or by tweeting to the [https://twitter.com/@openw3c @openw3c] twitter account.'''<br />
<br />
SeeAlso:<br />
<br />
* [http://www.w3.org/2014/11/getreview/ Tool to Assist with Calls for Specification Review]<br />
* [https://www.w3.org/2019/Process-20190301/ Process Document 2019]<br />
<br />
<br />
== Introduction ==<br />
<br />
Getting early review and feedback is important, especially reviews from those groups that have identified a document as a dependency, and the so-called ''horizontal groups''. It is also important to get review from other stakeholders including Web developers, technology providers and implementers not active in the Working Group, external groups and Standards organisations working on related areas, etc.<br />
<br />
In Process-2017, the focus is on actually getting evidence that wide review has occurred. The considerations, guidelines and Best Practices (BP) in this document should provide reasonable guidance for document review.<br />
<br />
== TL;DR: ==<br />
<br />
When you have published a First Public Working Draft, you should work through available "self-review" materials, and request review of your results, in at least the following areas. "Long enough*" before you request a transition to CR, you should do the same again, identifying substantive specification changes since the first review.<br />
<br />
The meaning of "Long enough*" depends on how many changes there are, and how clearly you have explained them. Pointing to 14 concise points for a small spec means a short time, pointing to 900 diffs from commits and hoping people understand them in a 300 page spec means it will take a '''long''' time to get review. If you have effectively identified issues for review during development, and got feedback on them, the review time will probably be shortened. It also depends how busy the groups are, so planning in advance is useful.<br />
<br />
;Accessibility<br />
:Work through [http://w3c.github.io/apa/fast/checklist.html this questionnaire] then ask [https://www.w3.org/WAI/APA/ APA] for review: [mailto:public-apa@w3.org public-apa@w3.org]<br />
;Architecture<br />
:Ask the [http://www.w3.org/2001/tag/ TAG] for review; see [https://tag.w3.org/workmode/ how to work with the TAG]. If you are developing javascript APIs you may also want to ask [mailto:public-script-coord@w3.org public-script-coord@w3.org], a technical discussion list shared by W3C and ECMA's TC 39.<br />
;Internationalisation<br />
:Work through the [[https://www.w3.org/International/techniques/developing-specs Checklist]], then request [http://www.w3.org/International/ i18n] review by email to [mailto:www-international@w3.org www-international@w3.org] (A public list watched by the Working Group). If for some reason you want a member-confidential review, you can ask on [mailto:member-i18n-core@w3.org member-i18n-core@w3.org] (a member-only list watched by the Working Group).<br />
;Privacy<br />
:Go through [https://www.w3.org/wiki/Privacy/Privacy_Considerations this checklist] and the [https://www.w3.org/TR/security-privacy-questionnaire/ privacy/security checklist], then ask the [http://www.w3.org/Privacy/ Privacy Interest Group for a review: [mailto:public-privacy@w3.org public-privacy@w3.org]<br />
;Security<br />
:Use your results from the [https://www.w3.org/TR/security-privacy-questionnaire/ privacy/security questionnaire] (see privacy), then ask the [http://www.w3.org/Security/wiki/IG Security IG] for review: [mailto:public-web-security@w3.org public-web-security@w3.org]<br />
;Groups listed in your charter<br />
:If there are groups listed in your charter as depending on some specification, you should ask them too.<br />
<br />
=== Read on⌠===<br />
You should familiarise yourself with the rest of this document. This section is just a quick reminder for when you are in the middle of doing the work.<br />
<br />
== Considerations and Best Practices ==<br />
<br />
Among the considerations and best practices, regardless of the ''type of review'' (early, thorough wide review, etc.) are:<br />
=== Who to ask for review?===<br />
<br />
* '''Which group(s) should be asked to review a document?''' All group charters should include information about the groups and external liaisons that are interested in particular documents. At a minimum, those groups should be included in all review request for their related document(s). Additionally, it may be appropriate to explicitly seek review from others such as: other Consortium groups; external organizations and SSOs; ''stakeholders'' such as implementers, testing and interop experts, application developers, etc. If a document is explicitly identified as a joint deliverable with another group, it is especially important to make sure that group is included in all review requests.<br />
<br />
* '''Which Horizontal Groups should be asked to request a review?''' This can be a bit tricky because in some cases the set of relevant of ''horizontal groups'' (enumerated below) should be relatively obvious but in other cases it might not be. For example, Working Group Charters often explicitly identify Horizontal Group dependencies, but post-charter development may introduce features that require review by Horizontal Groups not called out in the charter. - SNZ<br />
** '''BP:''' if in doubt, before formally asking a horizontal group to review a document, talk to them informally (f.ex. via e-mail).<br />
<br />
''(comment): I agree that it may not be obvious that a document needs horizontal review, but I tend to take a stronger line: even if you have not identified a ''horizontal group'' dependency, you should always discuss whether a review is necessary or even request a review (saying if you think there are no issues of interest to the given group). --[[User:Aphillip|Addison Phillips]] ([[User talk:Aphillip|talk]])''<br />
<br />
* '''What should be done if it appears a document might be relevant to a [http://www.w3.org/2001/11/StdLiaison.html W3C liaison] but the liaison is not explicitly listed in the group's charter?''' The Chair(s) and Team Contacts should consult with their group, and if there is consensus within the group to contact the liaison, then that external group should be included in all review requests.<br />
** '''BP:''' That group should be included in review requests unless they ask not to be --CMN<br />
<br />
=== When should review be requested? ===<br />
<br />
* '''When is a group ''required'' to seek wide review of a Process-2017 document?''' For a document to enter CR, the group must show the document has had wide review. The requesting group is free to determine the timing for review requests.<br />
<br />
* '''When should reviews by Horizontal Groups be scheduled?''' Horizontal Groups are very often resource limited. This means that they can often only do one review and may have difficulty scheduling that review in a timely way. Secondly, to do a reasonable review, they need a document that is pretty stable, but still flexible enough to allow changes where issues are identified. -SNZ<br />
**'''BP:''' Contact the chair of each relevant Horizontal Group to arrange a suitable time in their schedule to review the document. - SNZ<br />
<br />
* '''What circumstances should trigger a RfC?''' When a new feature is added to a document after its FPWD is published or after the document has already been a target of a wide review, a group should seek wide review of that new feature. <br />
** Other reasons to consider wide review include: some other group expresses keen interest in a document.<br />
<br />
* '''What part of a document should be reviewed and when?''' The general rule of thumb is to get review ''early and often''.<br />
** '''BP:''' Ensure that each section or feature is reviewed when it is considered stable (this enables changes to be made early, which lowers the risk that deployed legacy will impact the possibilities for fixing something).<br />
<br />
=== Making reviews happen ===<br />
* '''Length of the Comment Period.''' The duration for comments (aka ''comment period'') depends on a number of factors including the version of the Process Document being used. As such, consult the version of the Process being used: [http://www.w3.org/2005/10/Process-20051014/ Process-2005] or [http://www.w3.org/2015/Process-20150901/ Process-2015].<br />
** '''BP:''' before a group asks another group to review a document, the requesting group should work with the review group to determine a mutually agreeable review timeline.<br />
<br />
* '''How to initiate a review request.''' Review requests should be sent to the review groups' Public mail list(s).<br />
** '''BP:''' please avoid cross-posting by using Bcc: if necessary.<br />
** '''BP:''' use the RfC template below.<br />
<br />
* '''Announce LCWD and pre-CR publications on the chairs list.''' The group Chair or W3C staff should announce all LCWD and pre-CR publications on the [https://lists.w3.org/Archives/Member/chairs/ chairs] list.<br />
<br />
* '''Announce all Requests for Review (f.ex. LCWD and pre-CR publications) on the <code>[http://lists.w3.org/Archives/Public/public-review-announce/ public-review-announce] e-mail list</code>'''. This announcement may be made by a group Chair, Consortium Staff, Editor or any other designated member of a group.<br />
** '''BP:''' use the RfC template below.<br />
<br />
* '''Use Public e-mail lists for review feedback.''' The requesting group's Public mail list should be used for review feedback.<br />
** '''BP:''' use the requesting group's main Public mail list for comments and do not use (nor create) a list whose sole purpose is for comments.<br />
<br />
* '''How can a group get acknowledgement that some person and/or group actually reviewed a document?''' Naturally, this isn't an issue if the reviewing group and/or individuals in the reviewing group actually provides review comments. However, in some cases, this can be somewhat difficult to determine and achieve (f.ex the reviewing group is small, the overlap in scope is minimal, etc.). <br />
** '''BP:''' when asking for review, explicitly ask the reviewing group to submit all feedback, even if the feedback is something like "I read it and have no comments".<br />
<br />
== Request for Comments (RfC) Template ==<br />
<br />
See the [http://www.w3.org/2014/11/getreview/ tool to assist with calls for specification review].<br />
<br />
=== General Information ===<br />
<br />
A RfC should include the following general information:<br />
<br />
* Name of the group seeking comments.<br />
<br />
* Deadline for comments.<br />
<br />
* <code>Subject:</code> header: include the maturity level, name of the document and document maturity level of the document<br />
** '''BP''': <code>Subject: RfC: FPWD of ''Name of Spec''; deadline MMM DD</code>.<br />
<br />
* Mail list for comments; include the mailto: address plus a link to the Public mail list archive<br />
** '''BP''': avoid cross-posting to multiple lists (and if this must be done, use Bcc:), except for the i18n WG, which needs to track issues on its technical list as well. (i18n WG members cannot subscribe to all the lists of the groups they review specs for.)<br />
<br />
* Alternate instructions for providing commentary ''(if needed)''. Some groups use bugzilla or github as a means of communication and for tracking issues. --[[User:Aphillip|Addison Phillips]] ([[User talk:Aphillip|talk]]) If your main or preferred tracking location is a database, make that clear in the SOD, since moving and tracking comments between mail threads and databases can waste time for both the reviewer and the reviewed group.<br />
<br />
* <code>Reply-to:</code> header: set the <code>Reply-to:</code> header to the mail list where all comments should be sent<br />
<br />
* State that all review be acknowledged, even if a reviewer or group has reviewed the document and has "no comments".<br />
<br />
=== Information for Each Document ===<br />
<br />
For each document that will be reviewed, provide at least:<br />
<br />
* Document title<br />
<br />
* URL<br />
** '''BP''': the contents of the document should be stable (i.e. not changed) during the review period. <br />
** '''BP''': if the contents of the document might change during the review, identify the specific section(s) that might change; or consider postponing the review until after those sections are stable.<br />
<br />
* Maturity level: FPWD, LCWD (for Process-2005 documents), pre-CR (for Process-2015 documents), CR, ...<br />
<br />
* Scope of the review: this can be the entire document, specific sections, specific issues, etc.<br />
** '''BP''': Identify the specific sections of the document that are newly stabilised, as well as those already considered stable. This allows reviewers who follw "at a distance" to focus on what's new, and allows new reviewers to focus on things that are ready for review, instead of providing a lot of comments on sections that are likely to shift.<br />
** '''BP''': Specifications should include information about stability and known implementation on a "section by section" basis.<br />
<br />
* If a review was previously requested, include the URL of a diff, using the previous version of the document as the diff's reference/base.<br />
** '''BP''': use [http://services.w3.org/htmldiff W3C HTML Diff service]<br />
** '''BP''': also provide a human-authored summary of the changes.<br />
<br />
=== Example Request for Comments ===<br />
<br />
Here are some example RfCs:<br />
<br />
* [http://lists.w3.org/Archives/Public/public-html/2014Sep/0099.html TTML Text and Imaging ... preCR]<br />
* [http://lists.w3.org/Archives/Public/public-review-announce/2014Nov/0002.html Pointer Events LCWD]<br />
<br />
== Horizontal Groups ==<br />
<br />
The consortium's so-called ''Horizontal Groups'' are groups that include review and coordination functions in their charter. Typically, these groups consist of individuals that can provide advice and guidance (to other groups) regarding their domain expertise.<br />
<br />
Groups with a horizontal review function, including their mail list are (alphabetical order):<br />
<br />
* [https://www.w3.org/WAI/APA/ Accessible Platform Architectures Working Group]; [https://lists.w3.org/Archives/Public/public-apa/ public-apa]; [https://www.w3.org/WAI/APA/wiki/Spec_Review APA Spec Review tracking]<br />
* [http://www.w3.org/International/ Internationalization Working Group]; [http://lists.w3.org/Archives/Public/www-international/ www-international] Reviews by Internationalization generally also involve the [http://www.w3.org/International/ig Interest Group], but are arranged through the WG.<br />
* [http://www.w3.org/Privacy/ Privacy Interest Group]; [http://lists.w3.org/Archives/Public/public-privacy/ public-privacy]<br />
* [http://www.w3.org/2001/tag/ Technical Architecture Group (TAG)]; [http://lists.w3.org/Archives/Public/www-tag/ www-tag]<br />
* [http://www.w3.org/2008/webapps/ Web API Consistency and Web IDL Conformance]; [http://lists.w3.org/Archives/Public/public-script-coord/ public-script-coord]; (this is a Web Platform WG list that liases with ECMA's TC-39)<br />
* [http://www.w3.org/WAI/IG/ Web Accessibility Interest Group]; [http://lists.w3.org/Archives/Public/w3c-wai-ig/ w3c-wai-ig]<br />
* [http://www.w3.org/Security/wiki/IG Web Security Interest Group]; [http://lists.w3.org/Archives/Public/public-web-security/ public-web-security]<br />
<br />
=== Review Resources ===<br />
<br />
* Internationalization:<br />
** [https://www.w3.org/International/review-request I18n Request a review]<br />
** [http://w3c.github.io/i18n-activity/reviews/shortchecklist Short i18n review checklist]<br />
** [https://www.w3.org/International/techniques/developing-specs Expanding collapsing detailed checklist], generated from [https://w3c.github.io/bp-i18n-specdev/ ''Internationalization Best Practices for Spec Developers'']<br />
* Security/Privacy:<br />
** [https://www.w3.org/TR/security-privacy-questionnaire/ ''Self-Review Questionnaire: Security and Privacy''; Mike West]<br />
** [http://www.rfc-editor.org/rfc/rfc3552.txt Guidelines for Writing RFC Text on Security Considerations (RFC3552)]<br />
** [https://w3c.github.io/fingerprinting-guidance/ Mitigating Browser Fingerprinting in Web Specifications]<br />
** [http://gregnorc.github.io/ping-privacy-questions/ Ping-privacy-questions]<br />
** [https://yrlesru.github.io/SPA/ ''Specification Privacy Assessment (SPA) (Creating Privacy Considerations for W3C Technical Specifications)''; Frank Dawson]<br />
* Technical Architecture:<br />
** [https://www.w3.org/2001/tag/doc/webcomponents-design-guidelines/ Guidelines for creating web platform compatible components]<br />
** [https://www.w3.org/2001/tag/doc/promises-guide Writing Promise-Using Specifications]<br />
** [https://w3ctag.github.io/design-principles/ Client-side API Design Principles]<br />
** [https://www.w3.org/2001/tag/doc/capability-urls/ Good Practices for Capability URLs]<br />
** [https://github.com/w3ctag/spec-reviews TAG Repository for reviews]<br />
* Web Accessibility:<br />
** [http://w3c.github.io/apa/fast/checklist.html Framework for Accessibility in the Specification of Technologies Checklist; APA WG]<br />
** [https://www.w3.org/TR/media-accessibility-reqs/ Media Accessibility User Requirements; PFWG]<br />
<br />
== FAQ ==<br />
<br />
* '''Q: When is the best time to seek ''early'' review?'''<br />
** A: For a number factors (including document maturity, implementation status, etc.), there is no ''best time'' that applies to ''all'' documents. However, for most documents, after a ''First Public Working Draft'' is published is generally a good time to seek review of a specification.<br />
<br />
* '''Q: Is some type of ''security'' and/or ''privacy'' review mandatory before a ''First Public Working Draft'' is published?'''<br />
** A: Strictly speaking, the answer is No. However, getting early review for documents with features that might have security and/or privacy implications is '''strongly encouraged'''. See the [https://www.w3.org/wiki/DocumentReview#Horizontal_Groups Horizontal Groups] section below for information about security and privacy groups that can provide review and related review resources. <br />
<br />
* '''Q: Does a group need to prove its documents have had wide review before proceeding to CR?'''<br />
** A: The answer is yes, since Process-2017.<br />
<br />
* '''Q: How does a group prove its documents have had wide review before proceeding to CR?'''<br />
** A: See [http://lists.w3.org/Archives/Public/public-w3process/2014Oct/0133.html How to work with (experiment with) Wide Review] -SNZ<br />
** A: Keep a Disposition of Comments (DoC) Document that shows review comments and acknowledgements that have been received. It is the distribution of the reviewers that shows the review has been wide.-SNZ<br />
** A: Ask the W3C Team if your proposed approach is likely to meet the requirements. -SNZ<br />
<br />
* '''Q: Is there such a thing as too many reviews?'''<br />
** A: Not really<br />
<br />
* '''Q: Is it possible to make too many requests for review?'''<br />
** A: unfortunately, yes there is. Multiple requests for reviews can quickly result in a situation of diminishing returns. To help address this, subsequent review requests should clearly identify the exact differences between the last review and current review.<br />
** A: This is also the reason that the Process clearly suggests there should be (TR) Working Drafts published when there are "significant changes that would benefit from review beyond the Working Group", rather than every day or only twice in the life of a specâŚ<br />
** A: TR Working Drafts are also useful for reviews since they provide a dated snapshot which can be recovered when the review comments are being discussed. Trying to discuss review comments against a document which has changed out of all recognition can be a frustrating and inefficient experience.<br />
<br />
== Issues ==<br />
<br />
* <strike>'''Is ''pre-CR'' the ''best'' term to describe a Process-2014 snapshot that precedes CR or is there a better term?'''<br />
** Proposals: 2014-LC, 2014-Snapshot, pre-CR snapshot, 2014-Review Doc, pre-CR Review Doc, ...<br />
** Proposal: Don't do this in order to demonstrate "wide review". A "Last call" for a document that has already been reviewed in development is appropriate. Waiting until you think the document is finished to ask for review is a bad idea.</strike> ''This issue has become moot with the passing of time.''<br />
<br />
* <strike>'''How can a group or individual be automatically notified when a document has been published at one of the transitions that could/should initiate the start of an early or wide review?''' For Process-2005 documents, the transitions of interest are FPWD, LCWD and CR and for Proc-Doc-2015 documents the transitions of interest are: FPWD, pre-CR, and CR.</strike> ''This Issue was resolved via the creation of the <code>[http://lists.w3.org/Archives/Public/public-review-announce public-review-announce]</code> e-mail list.''<br />
<br />
* '''For all processes''' Working Drafts should be relevant for review - and should identify which parts are new or newly stabilized or changed, to facilitate '''timely''' review.<br />
** Potential solution: when a document is published on /TR, announce its publication on a Public mail list. See a related [http://lists.w3.org/Archives/Public/public-w3process/2014Oct/0102.html Call for Consensus] to create such a list, deadline for comments is October 15].<br />
<br />
== Terminology and Abbreviations ==<br />
<br />
* '''pre-CR''' - This is a version of a Working Draft that is created to get wide review.<br />
** note that this is a bad way to get review. In general, features should be reviewed as they are developed. Waiting for a "Last Call" for most review means that when reviews suggest changes it is far harder to make them, due to a commonly observed and logical reluctance to break deployed systems or content. [[User:Charles|Charles McCathie Nevile]] ([[User talk:Charles|talk]]) 11:18, 13 October 2014 (UTC)<br />
<br />
* '''requesting group''' - a group that is requesting a review <br />
<br />
Abbreviations:<br />
<br />
* BP = Best Practices<br />
* CR = Candidate Recommendation<br />
* RfC = Request for Comments (aka Review Request)<br />
* [http://www.w3.org/TR/ TR] = Technical Report, i.e. a formal W3C publication.<br />
* WD = Working Draft<br />
<br />
== Enhancement Requests ==<br />
<br />
* See the [https://www.w3.org/wiki/Dashboard#Document_Review_Dashboard Document Review Dashboard] document for information about creating a dashboard type service to facilitate document reviews.</div>Plehegarhttps://www.w3.org/wiki/index.php?title=Evergreen_Standards&diff=109040Evergreen Standards2019-03-13T13:24:23Z<p>Plehegar: /* Review tooling */</p>
<hr />
<div>= Introduction =<br />
<br />
== Overview ==<br />
<br />
As the Web evolves continuously, some groups are looking for ways for specifications to do so as well. So-called [https://www.w3.org/2001/tag/doc/evergreen-web/ "evergreen recommendations"] or "living standards" aim to: <br />
* track continuous development and maintenance of features<br />
* get review and patent commitments <br />
* report on implementation status<br />
all on a more granular level, namely feature-by-feature rather than only at the entire specification set. <br />
<br />
This proposal seeks to develop in greater detail what it would take for W3C to ''recommend'' such evergreen documents. In the analysis, we consider various aspects and values embodied in the current W3C Process and Patent Policy to assess how those can be met in an iterative mode. This process is inspired by work in W3C WGs, CGs, and [https://whatwg.org WHATWG]. <br />
<br />
'''Note to readers:''' This wiki contains many levels of detail. A general overview can be found in the sections Overview-Licensing, with further details (and possible contradictions) elaborated further down. Consider also the final [[Evergreen_Standards#Comparison_of_the_Continuous_and_Traditional_Recommendation_Tracks|comparison table]]<br />
<br />
== Continuous Development == <br />
<br />
ER Specifications are developed on a continuous basis. Working Drafts published to /TR should represent WG consensus, but rather than a daily call for consensus, the WG may adopt a procedural consensus, as defined [[Evergreen_Standards#Roles.2C_Responsibilities.2C_and_Consensus_in_the_Evergreen_Model|below]], by which they agree in advance on the conditions under which a feature can be added.<br />
<br />
We also seek continuous review, such that all material that has been in the specification for six months or more has been '''available''' for review:<br />
** by the community â but particularly the working group, the Advisory Committee, and the Team â that the specification meets the charter requirements (for testing, implementation, and interoperability, for example);<br />
** by the cross-functional groups for acceptability;<br />
** by the liaison groups and the wider public for acceptability.<br />
* all material that has passed a snapshot exclusion opportunity carries a license to the unexcluded essential IPR from those who had the opportunity<br />
[[Evergreen_Standards#Tooling_Requirements|Tooling]] and markup would support groups seeking and providing reviews to identify new and changed material.<br />
<br />
Under the current [https://www.w3.org/2018/Process-20180201/ Process] and [https://www.w3.org/Consortium/Patent-Policy-20170801/ Patent Policy], royalty-free patent commitments attach when a document is published as a Recommendation, after exclusion periods at FPWD (First Public Working Draft) and CR (Candidate Recommendation). We propose that for continuous publication, there be periodic snapshots, after which patents not excluded would be licensed royalty-free.<br />
<br />
== Terminology == <br />
<br />
* Evergreen Recommendation (ER): the product of a continuous publication process; tip-of-tree<br />
* ER Snapshot: a dated version taken from the ER, e.g. for IPR review purposes<br />
<br />
= Roles, Responsibilities, and Consensus in the Evergreen Model =<br />
<br />
As with any W3C Working Group, there are Chairs for the group, Editors for the documents of the group, and Participants in the group. However the roles and responsibilities may be somewhat different in these groups from those in groups producing Rec-track work. One of the important ways that the roles must differ is because of the role of consensus.<br />
<br />
As opposed to a Working Draft on the Recommendations track, an Evergreen Recommendation must always represent consensus. That is because the ER document itself has status as something recommended by W3C; hence it must represent a consensus. But there is no need for the consensus to be achieved by a daily Call for Consensus; or anything that formal. That would slow down the effort considerably.<br />
<br />
Instead, the means to achieving consensus can be decided by each group. For example, groups producing Evergreen Recommendations may operate on procedural consensus. The charter or chairs specify a work-mode for adding to the ER, and reach WG consensus on that mode. The editors have primary responsibility to implement that work-mode, with review by the WG and appeal to the chairs as a backstop against overstep. <br />
<br />
An example of how that might work could be:<br />
* All merge/commits on the editor's draft document needs to get approved/supported by at least one reviewer or group participant<br />
* All substantive merge/commits on the editor's draft document needs to get approved/supported by at least one or more implementors, have a corresponding web platform test (WPT) pull requests (or lists a reason not to), and must allow a 10 day review period to the group participants<br />
- all new feature merge/commits on the editor's draft document needs to get approved/supported by at least two or more implementors<br />
<br />
This is just an example, but it illustrates that for the most part - within the rules set by the group - the Editors of the specification have the primary role to ensure that the specification represents the current consensus of the Working Group. This is done by informal means: regular conversations between the editor and participants; participants raising issues about the spec in github; editors addressing issues and pull requests; and editors tracking implementations to ensure that the ER is both reflective of implementation as well as sensitive to the issues raised by the community. The Editor achieves this consensus without issuing formal calls for consensus; instead the Editor is continually in contact with the group to ensure that the ER document represents a consensus.<br />
<br />
As opposed to the REC track, the Chair does not have the responsibility to call for consensus or assess consensus as a result of a poll of participants. But the Chair has an important oversight role to ensure that the group's discussions proceed according to the procedural approach chartered for the group, are in accordance with CEPC, and is a resource for participants who disagree with the way that the editors are documenting the evolving consensus of the group. If a participant believes that the editor is not behaving fairly, the chair facilitates discussion between the participant and editor. If that does not solve the issue, the chair may also issue informative calls for consensus, or engage in other discussions to see whether consensus can be reached or whether the editor can adjust their position. <br />
<br />
Despite this important facilitation role of the chair, they generally do not have the authority to overrule the sense of the editor of where consensus lies during the ER phase of a specification development as long as the editor is following the procedure of the group. However, in an extreme case, the chair can request that the Director look into the situation and possibly remove the editor.<br />
<br />
We discussed in the [https://www.w3.org/wiki/Evergreen_Standards#Overview Overview] that we expect incremental community review of an ER. It is the responsibility of the chair to ensure that there is appropriate notification to review groups about the progress of the ER.<br />
<br />
However, when the ER is ready to make the transition to the REC track, the chairs will have a more significant role assessing consensus in the usual way.<br />
<br />
= Reviews = <br />
<br />
The W3C has a value that all substantive changes are subject to these four kinds of review: "horizontal review," "wide review,", Director, and Advisory Committee review. For Continuous Publication, we mandate automated reports to the AC and cross-functional groups on a regular basis, reporting on substantive changes. This signals to cross-functional groups that they may perform their reviews. The ES process may still require further confirmation to assure that the reviews are completed.<br />
<br />
External groups should be notified by liaison of the existence of the Continuous Publication, as early as is practical and useful, and agreement reached with them how they will review substantive changes. They may request to be added to the automated report, for example; they may elect to watch the repository manually; or ask to be notified manually by the WG e.g. in liaison or email. Such manual notification should be both archived and also occur no less frequently than every 180 days.<br />
<br />
'''Imputed review''' There is a 180-day period before changes are considered reviewed. This period starts on the first report that details the change (even if it was later reverted and re-inserted). Note that anyone, including AC, cross-functional groups, public, and members of the WG, are free to comment on anything at any time, of course; the 180-day deadline merely sets a date before which changes ought to be considered by the working group, and after which they might apply more back-pressure.<br />
<br />
== Review tooling == <br />
<br />
This implies a tooling requirement: automated tools must inform the community when a change has been made, giving notice which changes are about to become accepted. A reviewer may also seek to know changes since their last review. To enable such automated reports, all changes must be made through Pull Requests (no direct commits). Pull Requests are considered '''substantive''' unless tagged as "Editorial" or "Minor technical". Issues are assumed non-substantive '''unless''' tagged explicitly as substantive (to avoid flooding the reports with issues that have not yet been categorized).<br />
<br />
(Note that the tagging for issues is necessarily the opposite to Pull Requests, as we don't want to report untagged, newly filed, issues, that the WG has not yet considered, as automatically substantive.)<br />
<br />
The automated report must detail:<br />
* new substantive changes since the prior report<br />
* substantive changes that will be declared past their 180 day review period in the next automated report (i.e. a kind of 'last call' for comments)<br />
* substantive changes that have just passed their 180 review period<br />
* all other changes (minor, editorial, etc.) performed via Pull Requests<br />
* suitable reporting on issues, noting particularly any tagged "substantive" or "cross-functional" (recently opened, recently closed, tagged substantive but still open, etc.)<br />
<br />
(Note the the WG, cross-functional groups, external bodies, and AC are at liberty to request other tags, e.g. identifying issues or pull requests of particular concern to those communities; we already have a substantial set of [https://w3c.github.io/issue-metadata.html tags].)<br />
<br />
A meaningful manual change log entry must be made in Github for any substantive change. There must be a way to generate a diff for a specification based on dates.<br />
<br />
For any issue filed against the document, the WG should consider whether an inline "issue" or âerratumâ notice should be placed in the document.<br />
<br />
For âreviewâ issues filed by the AC, a cross-functional W3C group, or by an external âliaisonâ body, the filing group can request, at any time after filing the issue and until the issue is resolved, any or all of:<br />
# that there be an inline issue/erratum notice, and/or <br />
# that the feature be marked as âprovisionalâ<br />
#that the feature be removed until consensus is reached.<br />
The WG is not automatically obliged to grant any request, but note that such denial may escalate the disagreement.<br />
<br />
If the WG and filer are unable to reach consensus, then the usual recourse to Formal Objections, Appeals, and Director rulings can be followed. As the continuous publication process does not entail formal Transitions, Director review can be triggered by the filer and WG deciding that they are at an impasse and one of them filing a Formal Objection. Formal Objections must be documented in the header of the document until the resolution is implemented. <br />
<br />
Since features that are stable in the specification for 180 days are considered final (there is an implied "acceptance" decision), disagreements should be raised to the editor, and then to the chairs before that 180-day period expires. If an issue is raised to the editor and the chair does not feel that the editor has sufficiently addressed the issue, the chair may appeal to the Director; possibly removing the editor.<br />
<br />
Similarly, if a participant has raised an issue and believes that neither is appropriately addressing their issue, they should Formally Object to the Director prior to a feature being around for 180 days. But they may only do that if they have first raised the issue with the editor and the chair and they have not gotten satisfaction.<br />
<br />
= Transitions between the Evergreen and Recommendation Tracks =<br />
<br />
The following initiations or transitions are envisaged:<br />
* A document may be initiated on either track ("this document will be developed as a Recommendation | Evergreen Recommendation")<br />
* A document previously on the Recommendation track may switch to the Evergreen track; typically this happens after Recommendation status, for maintenance, but may happen on any re-chartering;<br />
* A document on the Evergreen track may enter the Recommendation track by satisfying the requirements for a WG Working Draft or Candidate Recommendation, and entering as such. Generally, when a WG wants to take a document to the Recommendation track they would first take an ER Snapshot to cement patent commitments to date.<br />
** Transition to the REC track does not necessarily mean that specification development as an ER stops because the work is entirely completed. For key parts of the web architecture, the spec is in constant evolution. However moving a snapshot to the REC level provides certain checking and validation for the work (e.g. complete cross-functional and AC review) which adds value in the technology development. There could still be an ER version that is further developed and developers wanting the most up to date version of the specification should use that.<br />
* Although a specification might remain as an ER for many years, there is value for any spec to transition to the REC track, because it is only at the REC track where full horizontal review and AC review is provide. While this value might not be appreciated by all developers that are primarily focused on current state of implementations, it is important for the broader community. The Charter for an ER must specify whether an ER is expected to transition to the Recommendation track - and if so - the expected point in time for transition to W3C Recommendation, even if that time is beyond the time-horizon of a particular charter. If the ER is never expected to transition, the charter should explain how full review is achieved or why it is not necessary for this specification.<br />
= Licensing =<br />
<br />
We intend to have Royalty-Free licensing as with all W3C specs, with licensing commitments made continuously through spec development, and exclusion opportunities prior to final commitment. <br />
<br />
We ask the PSIG to look at spec development in the Evergreen model, the RF licensing requirements of W3C, and the spec review process within a member organization, with this general philosophy: <br />
<br />
Based on the WHATWG [https://whatwg.org/workstream-policy process], perhaps with <br />
* an adjustment of intervals (we probably prefer a longer filing period, say 60 days).<br />
* a provision that WHATWG lacks, for an exclusion opportunity on the current Working Draft, on leaving the WG (to match the Patent Policy, and close a significant gap).<br />
<br />
An exclusion filing must result in:<br />
# A notification to at least the WG general mailing list, the advisory committee, and PSIG, so that the community is immediately aware and can take appropriate steps.<br />
# The formation of a [https://www.w3.org/Consortium/Patent-Policy-20170801/#sec-Exception Patent Advisory Group] (PAG).<br />
# The documentation, in the header of the specification, of the exclusion and the PAG, until the PAG completes its operation and its recommendations implemented.<br />
<br />
= Process Edits =<br />
<br />
There is a [https://www.w3.org/2019/03/Evergreen.html draft] of what the relevant process chapters might look like, under development.<br />
<br />
= *** More detail below *** =<br />
<br />
= Tooling Requirements =<br />
<br />
We have indicated above some of the required tooling for features. Since features achieve greater status by aging (in particular, we assume after 180 days there has been sufficient time for incremental horizontal review), there needs to be tooling so it is easy to determine when a feature was introduced and/or last changed.<br />
<br />
Since features achieve greater status by acquiring implementation experience, testing, and demonstrating interoperability, there needs to be tooling so it is easy to determine that a feature has all of this experience.<br />
<br />
Since a feature is more meaningful to implementors when there are implementation commitments, there must be tooling for that.<br />
<br />
Since a feature is considered normative in an ER when it has 180 days of aging and implementation experience, tooling must make it easy to identify that status as well.<br />
<br />
Tooling related to tagging issues in GH is as follows:<br />
<br />
We need <br />
* to define the standard tags that the report tool will use to work on, for Issues and Pull Requests.<br />
* the report tool to distil Pull Requests by tag (editorial, minor technical, or assumed substantive) and date (first appearance, will hit 180 days in the next 30 days, has passed 180 days, all since merging)<br />
* the report tool to distill Issues by tag also<br />
<br />
Ideally there is a commit hook that generates a "permanent link to this version" header.<br />
<br />
Note that all documents in a Github pages repo can have a unique URL, and are immutable; these come free. Those wanting to reference a specific unchanging version can do that. You can refer to a specific revision in GitHub using htmlpreview or rawgit.com; for example the August 17th version of WebVTT is<br />
<br />
<http://htmlpreview.github.io/?https://github.com/w3c/webvtt/blob/2b24ae60e84e8cbac033c148db2715104e0b9368/index.html><br />
<br />
or rawgit.com<br />
<br />
<https://rawgit.com/w3c/webvtt/2b24ae60e84e8cbac033c148db2715104e0b9368/index.html><br />
<br />
It should be easy to mark a document as under PAG review or under a Formal Objection, while exclusion or FO processing is in progress.<br />
<br />
We might like better support for in-line errata, and provisional material, and the ability to see a document without those (and thus make a snapshot), but this is optional.<br />
<br />
= Tooling Design =<br />
<br />
The tooling is intended to leverage information coming from multiple sources: WPT (tests, results), caniuse.com, specification, github.com, etc.<br />
<br />
For a given section, sub-section, paragraph, we may identify the following:<br />
<br />
# tests<br />
# test results<br />
# feature implementation information<br />
# feature implementation commitment information<br />
# 180 days information<br />
# articles in MDN<br />
<br />
For ES, the annotations will be providing as JSON objects, contained in one file per commit and per specification generated on the day of the ES snapshot, then loaded and render using a JS script. The annotations within a given snapshot are NOT expected to change/involve overtime. In order of preference, each annotation object will be identifiable with:<br />
<br />
* API information (eg AuthenticationExtensionsClientOutputs, AuthenticationExtensionsClientOutputs.rawId)<br />
* CSS property name (eg "background-size")<br />
* Markup elements and attributes (eg "use", "use@width")<br />
* section title (eg "Android Key Attestation Statement Format")<br />
* CSS Selector (eg "pre.idl")<br />
* fragment identifiers (eg #preventSilentAccessCredential)<br />
* section numbering<br />
<br />
The same identifier may apply to more than one annotation object.<br />
<br />
Bikeshed and ReSpec, the most currently used spec editing framework, will need proper support to identify annotation object identifiers as well as WPT, caniuse.com, and MDN identifiers. Test files can be identified by providing a list of files in WPT. Test results can be deduced from that list. A test file may contain more than one test and we will need to work with WPT folks to get a method to identify specific tests within a test file. caniuse.com already provide annotations to integrate a feature implementation information.<br />
<br />
Last update information will be generated based on running diffs with the 180 days-ago version and generating resulting JSON annotation objects. We should be able to leverage the [[https://w3c.github.io/issue-metadata.html|GitHub tagging]], on issues and pull requests. We'll need to explore if the result can be refined using commit history information (see [https://github.com/w3c/payment-request/commits/gh-pages payment-request commits]).<br />
<br />
A tool will generate the annotation file using information embedded within the specification. The specification may contain additional annotation objects to be merged as well. A tool should check the resulting annotations to determine if all annotation objects are still relevant.<br />
<br />
The commit hook will be tasked to generate an ES snapshot and the annotations associated with it.<br />
<br />
= Referenceability =<br />
<br />
For all W3C specifications, it is important to know how they are normatively referenced by other specifications - both on the ER track as well as the REC track.<br />
<br />
It is possible to normatively reference a W3C specification, evergreen or working draft, from a W3C Recommendation as long as the [[https://www.w3.org/2013/09/normative-references|Director's consideration]] are applied, in particular:<br />
<br />
* Stability of the referenced part(s)<br />
* Nature of the dependency<br />
* Status of implementations<br />
<br />
<br />
= Charter, Repository, Document, Testing, and Implementation Requirements =<br />
<br />
WG Charters may declare that a document is developed on the Recommendation Track, or on the Continuous Publication track. Changes between tracks, for any document, require a new approved charter unless the changes are already in the charter. <br />
<br />
In order to enable 'harvesting' of the Github repository URLs of Continuous Publications, by both lawyers and the tools that inform reviewers, the Github repositories must be created before the charter is sent to formal AC review, and the URLs to those repositories must be in the charter, in a section clearly listing those documents on the Continuous Publication track.<br />
<br />
Those Github repositories must be in the W3C space and also must document the publication URL (usually Github.io) of the readable document.<br />
<br />
The readable document must list, in its header, the URL that refers to the latest viewable version, and also a permanent URL to the specific revision being viewed. It should also identify the Github repository where issues are filed and revisions made. As noted above, both unresolved (a) Patent Exclusions and (b) Formal Objections must be documented in the header of the specification.<br />
<br />
The charter must identify the implementability, implementation, test suite, and test pass coverage requirements for a feature to be considered not provisional but final. Features that do not meet these requirements should be integrated first as provisional, and a second Pull Request made to change them to non-provisional, when the requirements are met.<br />
<br />
= Implementation expectations =<br />
<br />
Typically speaking an ER specification will consist of different features at different levels of implementation maturity due to the requirement to be "Evergreen", that is, very reflective of current implementation and thinking among implementors. Included in that are features:<br />
<br />
* For which there is sufficient implementation experience and testing that the Director would ordinarily feel that those features could be approved in a W3C Recommendation.<br />
* For which interoperability has not yet been demonstrated, but there are at least commitments from sufficient implementors that there is a strong likelihood that the features will ultimately be accepted as Recommendations.<br />
* (In rare cases) Draft features that the WG is working on that are significant chartered deliverables being developed in the WG which are expected to be implemented but which lack firm implementation commitments at this time.<br />
<br />
While there could be good reasons to have features of various levels of maturity in a specification, it is important to clarify what part of the specification is actually being given support by W3C for developers to implement.<br />
<br />
For all specifications for which W3C is conferring status, the rule is that the status is only being conferred on those features where there has been sufficient implementation experience and testing to demonstrate interoperability. This is true whether the features are in an ER, an ER snapshot, or a W3C Recommendation.<br />
<br />
That does not mean that the other features need to be stripped from the document. They remain in the document but are considered as informative material for the spec, not normative, endorsed features for implementors.<br />
<br />
This characterization of what parts of the spec are considered normative must appear in the status of the document.<br />
<br />
<br />
= Sample Charter Language =<br />
<br />
The Fruit Action Working Group (FAWG) will develop the following on the Recommendation Track:<br />
* Pineapple picking and handling, <br />
and the following on the Continuous Publication Track,<br />
* Olive picking, pitting, curing and bottling; in the Github Repo (URL goes here)<br />
** The ES spec for Olive picking will have an IPR snapshot every 12 months.<br />
** While the Olive picking spec is on the Continuous Publication Track, it is intended that after 4.7 years, a snapshot will be taken to Recommendation.<br />
<br />
For a feature to be considered final by the working group (on either track):<br />
* it must be testable by a test in the Agricultural Products Test (APT) suite at (URL goes here)<br />
* there must be at least 3 complete implementations<br />
* at least 2 of those implementations must pass the applicable APT tests<br />
* at least 1 of those implementations generates packed olives, and at least one uses packed olives, and they interoperate<br />
<br />
Features that do not meet these requirements will be integrated first as provisional, and a second Pull Request made to change them to non-provisional, when the requirements are met.<br />
<br />
= Sample Document Header =<br />
<br />
Olive picking, pitting, curing and bottling.<br />
<br />
W3C Evergreen Standard 15 March 55BCE<br />
<br />
'''Latest version''': (URL to the evergreen standard goes here)<br />
<br />
'''Permanent link to this version''': (URL for this exact version goes here)<br />
<br />
'''Repository''': (URL to the Github repository for issues etc.)<br />
<br />
'''Editors''': (Editors listed by name)<br />
<br />
'''Current unresolved Patent Licensing Exclusions''': none, or a URL to the exclusion plus a URL to the PAG information<br />
<br />
'''Current unresolved Formal Objections''': none, or a URL to the Formal Objection filing<br />
<br />
'''Abstract''': (as usual)<br />
<br />
'''Status of this document''': <br />
<br />
This document is developed by the (link to Working Group). Comments and issues are welcomed and should be filed at the (URL to the issues page of the Github repository). <br />
<br />
This document was produced by a group operating under the W3C [https://www.w3.org/wiki/Living_Standards Continuous Publication] process and policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with [https://www.w3.org/Consortium/Patent-Policy-20170801/#sec-Disclosure section 6 of the W3C Patent Policy].<br />
<br />
The disclosure obligations of the Participants of this group are described in the Working Group charter.<br />
<br />
= Detailed explanation of the Continuous Track Patent policy =<br />
<br />
Looking for input from PSIG.<br />
<br />
= Summaries for various constituencies =<br />
<br />
== Lawyers ==<br />
<br />
(needs editing to match the snapshot model)<br />
<br />
Lawyers will need to take roughly the following steps:<br />
* Review the charters of the working groups that your organization intends to participate in. <br />
* Collect, from the charters, the URLs of the Continuous Publication repositories and add them to your 'watch list'.<br />
* When you join a working group, review the most recent snapshot and file any applicable exclusions, within the deadline.<br />
* When snapshots are made, review it and file any applicable exclusions, within the deadline.<br />
* Watch other exclusion filings, of course; take any steps you think indicated, and consider joining the PAG.<br />
* Optionally, if you want early notification of changes, watch the monthly automated reports of Pull Requests, or get automated immediate notification by GitHub of Pull Requests, for repositories in your watch list.<br />
* When you leave a working group, do a final exclusion check on the working draft that was current as of the time you left the group.<br />
<br />
== Working Groups ==<br />
<br />
Working groups need to do the following:<br />
* Create Github repositories for your documents on the Continuous Publication track before writing your charter.<br />
* Define clearly in your charter the documents on the Continuous Publication track; list the URIs of their repositories.<br />
* Define clearly in your charter what requirements a feature must meet to be considered acceptable (testing, implementation, interop, etc.).<br />
* Watch Pull Requests and make sure:<br />
** that Pull Requests are correctly tagged (editorial, minor, or, by default, substantive);<br />
** that if Pull Requests add to 'core draft' (ie. material that is not an erratum report, provisional, or editor's note) that the addition meets the WG requirements (testing, implementation, interop, etc.).<br />
* Watch issue filings and tag those also.<br />
<br />
== Editors == <br />
<br />
Editors need to make sure that material that is provisional, an erratum report, or an editor's note, is correctly tagged, and that tags are removed when the material becomes final. If a new feature is too complex to be inserted inline as provisional, manage separate "editor's drafts" that the WG can review until such time as they agree to merging. Check that the 'core draft' reads correctly as well as checking the entire document.<br />
<br />
If there have been any technical changes since the last snapshot, make a new snapshot no later than 180 days after the last one.<br />
<br />
== Other Groups ==<br />
<br />
Read the automated reports and review the changes as they happen. File an issue with at most 180 days if there is a problem. Raise a Formal Objection, ideally within 180 days, if impasse is reached so that Chairs can facilitate a discussion and (if necessary) the Director can get involved if needed to resolve disagreement.<br />
<br />
== Team == <br />
<br />
The team:<br />
* makes sure the process is followed, Charters are correctly drafted, etc.<br />
* makes sure that the Pull Requests (and issues) are tagged correctly, and that technical changes meet the charter requirements;<br />
* makes sure that snapshots are made if technical changes have occurred since the last snapshot, and 180 days are about to elapse;<br />
* ensures that the comments from outside the WG are given due and timely consideration by the WG (notably, within the six months tacit acceptance period);<br />
* when an exclusion is filed, the PAG is formed, notifications sent, and the document header updated (and removed when the PAG is completed);<br />
* when a Formal Objection is filed, notifications sent, and the document header updated (and removed when the Formal Objection is resolved).<br />
<br />
<br />
= Use Cases =<br />
<br />
Possible use cases include: <br />
<br />
* Accessibility API Mappings (see https://github.com/w3c/w3process/issues/79)<br />
* Vocabularies. Most vocabulary definitions have little IPR contention, and grow in a natural incremental fashion.<br />
* Registries. Similar reasons to vocabularies<br />
* Profiles of the Web Platform (e.g Web Media). Profiles of the Web Platform involve little spec development, but indicate which portions of the standards are most appropriate for industry segments.<br />
* Maintenance. Maintenance of specification by nature is intended to track evergreen incremental enhancements rather than bold new features; plus have less IPR contention.<br />
* Core infrastructure. Some specs provide core infrastructure for other specs; but may not need to reach a level of Recommendation per se. Web IDL might be an example.<br />
* Incremental guidance. Specification such as WebAppSec seem well suited for an incremental or evergreen approach.<br />
* All specifications. Some feel that an Evergreen approach is a best fit for all specs.<br />
<br />
<br />
= Documents and their status =<br />
<br />
What is W3C recommending in an ER? What should developers do with it? What can developers depend on, and what risks are there? <br />
<br />
== Status of several kinds of W3C documents ==<br />
For each type of document W3C produces, it conveys "status" of the document based on the process used to generate the document.<br />
<br />
* Community Group Specifications. These documents have no particular W3C status, although the individual contributions come with a level of patent protection through the W3C CLA.<br />
<br />
* Community Group Final Specifications. These documents have no particular W3C Status, although the entire specification comes with enhanced patent protection through the FSA agreement that may be signed by participating organizations.<br />
<br />
* Working Group Working Draft. These documents have no particular W3C status, but they are guaranteed to be within the scope of a WG approved by the Director after review by the AC.<br />
<br />
* Working Group Candidate Recommendation. These documents, like Working Drafts are within an approved scope. Additionally, they:<br />
** Have met the requirements of the WG, or explained why the requirements have changed.<br />
** Have addressed issues raised<br />
** Represent the consensus of the WG<br />
** Have a plan to demonstrate implementation experience<br />
** Have received wide review (including horizontal review)<br />
** Have received Director's approval for this status<br />
<br />
* Working Group Recommendation. These documents have all of the status attributes of CR documents. They have the additional status of:<br />
** Have demonstrated implementation experience<br />
** Have W3C Royalty Free licensing commitments associated with the specification.<br />
** Have received AC review of the spec<br />
** Have ensured that all Formal Objections are resolved through Director review<br />
** Have an Appeals process if the AC disagrees with the Director<br />
** Represents a stable reference.<br />
** Has been adopted<br />
<br />
* ''Proposed'' Evergreen Recommendations<br />
** Are within the approved scope of a WG<br />
** Represent the consensus of a WG (driven by the editor with oversight from the WG chair)<br />
** Have demonstrated implementation experience<br />
** Have received incremental wide review (including incremental horizontal review)<br />
** All key horizontal issues have been resolved<br />
** Have ER contribution Patent Commitments associated with the spec<br />
<br />
Thus the ER has achieved much of what the community is looking for and hence W3C confers it with the status of ER which both informs the community of what they can rely on, and also establishes where there is incompleteness.<br />
<br />
The most serious incompleteness is the incompleteness of patent commitments. Accordingly, it is expected that the WG will on a regular basis (e.g. every 12 months) create an ER Snapshot which gets the benefit of full patent commitments for the ER spec.<br />
<br />
* Proposed ER to REC, adds <br />
** Full wide review (including horizontal review)<br />
** Director approval<br />
** Received an AC review of the spec<br />
** Ensured that all Formal Objections are resolved through Director review<br />
** The benefit of an Appeals process if the AC disagrees with the Director<br />
** A stable reference.<br />
<br />
= Different Evergreen Models =<br />
<br />
There is a choice between a âsnapshot' and sliding-window model, for both IPR review and functional review. What we have here is hybrid -- sliding-window for the technical reviewers, snapshot for the IPR.<br />
<br />
This is like the WHATWG [https://whatwg.org/workstream-policy process] which requires a periodic manual "review draft" ('snapshot') approximately every 6 months, and at that time all the legal reviewers have 45 days to respond. WhatWG doesnât have liaisons, cross-functional groups, an Advisory Committee, or Director/team.<br />
<br />
In the sliding-window model, we deem all the technical groups (external, cross-functional, Advisory Committee, and Director/team) to have tacitly accepted features 180 days after they first appear, unless they file an issue. This incremental tacit acceptance is sufficient for W3C to confer status on an ER that there is sufficient review to be reasonably confident that a feature is stable and can be implemented. But it is less than the status associated with a full W3C Recommendation which has had wider and more complete review.<br />
<br />
If an issue has been raised, the editor has the lead role to address the issue and re-establish consensus. This is discussed in: [https://www.w3.org/wiki/Evergreen_Standards#Roles_and_Responsibilities_in_the_Evergreen_Model Roles and Responsibilities]<br />
<br />
There is little '''functional''' difference between âWeâll keep you informed of the grocery list as it builds, and you must do your grocery shopping at least once a weekâ and âYou must do your grocery shopping immediately when the editor issues the weekly shopping listâ â it is the same amount of work, at the same frequency; but the former allows you to choose when, and indeed spread it out if you want to, while the latter says âjump nowâ. But there is a difference of work-mode.<br />
<br />
<br />
<br />
= Comparison of the Continuous and Traditional Recommendation Tracks =<br />
<br />
{| class="wikitable"<br />
|-<br />
! Concept !! Continuous !! Traditional<br />
|-<br />
| wide review || Incremental, by automatic notification and lack of objection || On Transitions<br />
|-<br />
| horizontal review (i18n, a11y, security, privacy, perf, device independence, TAG, etc.) || Incremental, by automatic notification and lack of objection || On Transitions<br />
|-<br />
| Advisory Committee review || Incremental, by automatic notification and lack of objection || On Transitions<br />
|-<br />
| tests || Defined in charter, verified by WG and reviewers incrementally || Defined in charter, verified by WG and reviewers on transitions<br />
|-<br />
| issues addressed || Verified incrementally || Verified on transitions<br />
|-<br />
| IP || Whole spec from all WG members given exclusion opportunity at a snapshot || Whole spec from all WG members at Rec<br />
|-<br />
| consensus || verified continuously || verified at transitions etc.<br />
|-<br />
| errata || In issues and possibly inline || Not well handled; in issues or possible erratum document<br />
|-<br />
| maintenance || Ongoing || Episodic<br />
|-<br />
| use cases || In charter or requirements document (which may also be Continuous) || In charter or Wiki or somewhere<br />
|-<br />
| requirements || In charter or requirements document (which may also be Continuous) || In charter or Wiki or somewhere<br />
|-<br />
| implementation commitments || Requirements defined by charter || Requirements defined by charter<br />
|-<br />
| implementation experience || Requirements defined by charter || Requirements defined by charter<br />
|-<br />
| Director's approval || Incremental, tacit unless objections raised || On transitions<br />
|-<br />
| Appeal process || After Formal Objection || After Formal Objection<br />
|-<br />
| stable reference || By using specific revision references or periodic Rec snapshots || Normal<br />
|-<br />
| adoption || Requirements defined by charter || Requirements defined by charter<br />
|-<br />
| status duration || Indefinite || Indefinite<br />
|}</div>Plehegarhttps://www.w3.org/wiki/index.php?title=Evergreen_Standards&diff=109039Evergreen Standards2019-03-13T13:04:26Z<p>Plehegar: Judy's comment</p>
<hr />
<div>= Introduction =<br />
<br />
== Overview ==<br />
<br />
As the Web evolves continuously, some groups are looking for ways for specifications to do so as well. So-called [https://www.w3.org/2001/tag/doc/evergreen-web/ "evergreen recommendations"] or "living standards" aim to: <br />
* track continuous development and maintenance of features<br />
* get review and patent commitments <br />
* report on implementation status<br />
all on a more granular level, namely feature-by-feature rather than only at the entire specification set. <br />
<br />
This proposal seeks to develop in greater detail what it would take for W3C to ''recommend'' such evergreen documents. In the analysis, we consider various aspects and values embodied in the current W3C Process and Patent Policy to assess how those can be met in an iterative mode. This process is inspired by work in W3C WGs, CGs, and [https://whatwg.org WHATWG]. <br />
<br />
'''Note to readers:''' This wiki contains many levels of detail. A general overview can be found in the sections Overview-Licensing, with further details (and possible contradictions) elaborated further down. Consider also the final [[Evergreen_Standards#Comparison_of_the_Continuous_and_Traditional_Recommendation_Tracks|comparison table]]<br />
<br />
== Continuous Development == <br />
<br />
ER Specifications are developed on a continuous basis. Working Drafts published to /TR should represent WG consensus, but rather than a daily call for consensus, the WG may adopt a procedural consensus, as defined [[Evergreen_Standards#Roles.2C_Responsibilities.2C_and_Consensus_in_the_Evergreen_Model|below]], by which they agree in advance on the conditions under which a feature can be added.<br />
<br />
We also seek continuous review, such that all material that has been in the specification for six months or more has been '''available''' for review:<br />
** by the community â but particularly the working group, the Advisory Committee, and the Team â that the specification meets the charter requirements (for testing, implementation, and interoperability, for example);<br />
** by the cross-functional groups for acceptability;<br />
** by the liaison groups and the wider public for acceptability.<br />
* all material that has passed a snapshot exclusion opportunity carries a license to the unexcluded essential IPR from those who had the opportunity<br />
[[Evergreen_Standards#Tooling_Requirements|Tooling]] and markup would support groups seeking and providing reviews to identify new and changed material.<br />
<br />
Under the current [https://www.w3.org/2018/Process-20180201/ Process] and [https://www.w3.org/Consortium/Patent-Policy-20170801/ Patent Policy], royalty-free patent commitments attach when a document is published as a Recommendation, after exclusion periods at FPWD (First Public Working Draft) and CR (Candidate Recommendation). We propose that for continuous publication, there be periodic snapshots, after which patents not excluded would be licensed royalty-free.<br />
<br />
== Terminology == <br />
<br />
* Evergreen Recommendation (ER): the product of a continuous publication process; tip-of-tree<br />
* ER Snapshot: a dated version taken from the ER, e.g. for IPR review purposes<br />
<br />
= Roles, Responsibilities, and Consensus in the Evergreen Model =<br />
<br />
As with any W3C Working Group, there are Chairs for the group, Editors for the documents of the group, and Participants in the group. However the roles and responsibilities may be somewhat different in these groups from those in groups producing Rec-track work. One of the important ways that the roles must differ is because of the role of consensus.<br />
<br />
As opposed to a Working Draft on the Recommendations track, an Evergreen Recommendation must always represent consensus. That is because the ER document itself has status as something recommended by W3C; hence it must represent a consensus. But there is no need for the consensus to be achieved by a daily Call for Consensus; or anything that formal. That would slow down the effort considerably.<br />
<br />
Instead, the means to achieving consensus can be decided by each group. For example, groups producing Evergreen Recommendations may operate on procedural consensus. The charter or chairs specify a work-mode for adding to the ER, and reach WG consensus on that mode. The editors have primary responsibility to implement that work-mode, with review by the WG and appeal to the chairs as a backstop against overstep. <br />
<br />
An example of how that might work could be:<br />
* All merge/commits on the editor's draft document needs to get approved/supported by at least one reviewer or group participant<br />
* All substantive merge/commits on the editor's draft document needs to get approved/supported by at least one or more implementors, have a corresponding web platform test (WPT) pull requests (or lists a reason not to), and must allow a 10 day review period to the group participants<br />
- all new feature merge/commits on the editor's draft document needs to get approved/supported by at least two or more implementors<br />
<br />
This is just an example, but it illustrates that for the most part - within the rules set by the group - the Editors of the specification have the primary role to ensure that the specification represents the current consensus of the Working Group. This is done by informal means: regular conversations between the editor and participants; participants raising issues about the spec in github; editors addressing issues and pull requests; and editors tracking implementations to ensure that the ER is both reflective of implementation as well as sensitive to the issues raised by the community. The Editor achieves this consensus without issuing formal calls for consensus; instead the Editor is continually in contact with the group to ensure that the ER document represents a consensus.<br />
<br />
As opposed to the REC track, the Chair does not have the responsibility to call for consensus or assess consensus as a result of a poll of participants. But the Chair has an important oversight role to ensure that the group's discussions proceed according to the procedural approach chartered for the group, are in accordance with CEPC, and is a resource for participants who disagree with the way that the editors are documenting the evolving consensus of the group. If a participant believes that the editor is not behaving fairly, the chair facilitates discussion between the participant and editor. If that does not solve the issue, the chair may also issue informative calls for consensus, or engage in other discussions to see whether consensus can be reached or whether the editor can adjust their position. <br />
<br />
Despite this important facilitation role of the chair, they generally do not have the authority to overrule the sense of the editor of where consensus lies during the ER phase of a specification development as long as the editor is following the procedure of the group. However, in an extreme case, the chair can request that the Director look into the situation and possibly remove the editor.<br />
<br />
We discussed in the [https://www.w3.org/wiki/Evergreen_Standards#Overview Overview] that we expect incremental community review of an ER. It is the responsibility of the chair to ensure that there is appropriate notification to review groups about the progress of the ER.<br />
<br />
However, when the ER is ready to make the transition to the REC track, the chairs will have a more significant role assessing consensus in the usual way.<br />
<br />
= Reviews = <br />
<br />
The W3C has a value that all substantive changes are subject to these four kinds of review: "horizontal review," "wide review,", Director, and Advisory Committee review. For Continuous Publication, we mandate automated reports to the AC and cross-functional groups on a regular basis, reporting on substantive changes. This signals to cross-functional groups that they may perform their reviews. The ES process may still require further confirmation to assure that the reviews are completed.<br />
<br />
External groups should be notified by liaison of the existence of the Continuous Publication, as early as is practical and useful, and agreement reached with them how they will review substantive changes. They may request to be added to the automated report, for example; they may elect to watch the repository manually; or ask to be notified manually by the WG e.g. in liaison or email. Such manual notification should be both archived and also occur no less frequently than every 180 days.<br />
<br />
'''Imputed review''' There is a 180-day period before changes are considered reviewed. This period starts on the first report that details the change (even if it was later reverted and re-inserted). Note that anyone, including AC, cross-functional groups, public, and members of the WG, are free to comment on anything at any time, of course; the 180-day deadline merely sets a date before which changes ought to be considered by the working group, and after which they might apply more back-pressure.<br />
<br />
== Review tooling == <br />
<br />
This implies a tooling requirement: automated tools must inform the community when a change has been made, giving notice which changes are about to become accepted. A reviewer may also seek to know changes since their last review. To enable such automated reports, all changes must be made through Pull Requests (no direct commits). Pull Requests are considered '''substantive''' unless tagged as "Editorial" or "Minor technical". Issues are assumed non-substantive '''unless''' tagged explicitly as substantive (to avoid flooding the reports with issues that have not yet been categorized).<br />
<br />
(Note that the tagging for issues is necessarily the opposite to Pull Requests, as we don't want to report untagged, newly filed, issues, that the WG has not yet considered, as automatically substantive.)<br />
<br />
The automated report must detail:<br />
* new substantive changes since the prior report<br />
* substantive changes that will be declared past their 180 day review period in the next automated report (i.e. a kind of 'last call' for comments)<br />
* substantive changes that have just passed their 180 review period<br />
* all other changes (minor, editorial, etc.) performed via Pull Requests<br />
* suitable reporting on issues, noting particularly any tagged "substantive" or "cross-functional" (recently opened, recently closed, tagged substantive but still open, etc.)<br />
<br />
(Note the the WG, cross-functional groups, external bodies, and AC are at liberty to request other tags, e.g. identifying issues or pull requests of particular concern to those communities; we already have a substantial set of [https://w3c.github.io/issue-metadata.html tags].)<br />
<br />
A meaningful manual change log entry must be made in Github for any substantive change.<br />
<br />
For any issue filed against the document, the WG should consider whether an inline "issue" or âerratumâ notice should be placed in the document.<br />
<br />
For âreviewâ issues filed by the AC, a cross-functional W3C group, or by an external âliaisonâ body, the filing group can request, at any time after filing the issue and until the issue is resolved, any or all of:<br />
# that there be an inline issue/erratum notice, and/or <br />
# that the feature be marked as âprovisionalâ<br />
#that the feature be removed until consensus is reached.<br />
The WG is not automatically obliged to grant any request, but note that such denial may escalate the disagreement.<br />
<br />
If the WG and filer are unable to reach consensus, then the usual recourse to Formal Objections, Appeals, and Director rulings can be followed. As the continuous publication process does not entail formal Transitions, Director review can be triggered by the filer and WG deciding that they are at an impasse and one of them filing a Formal Objection. Formal Objections must be documented in the header of the document until the resolution is implemented. <br />
<br />
Since features that are stable in the specification for 180 days are considered final (there is an implied "acceptance" decision), disagreements should be raised to the editor, and then to the chairs before that 180-day period expires. If an issue is raised to the editor and the chair does not feel that the editor has sufficiently addressed the issue, the chair may appeal to the Director; possibly removing the editor.<br />
<br />
Similarly, if a participant has raised an issue and believes that neither is appropriately addressing their issue, they should Formally Object to the Director prior to a feature being around for 180 days. But they may only do that if they have first raised the issue with the editor and the chair and they have not gotten satisfaction.<br />
<br />
= Transitions between the Evergreen and Recommendation Tracks =<br />
<br />
The following initiations or transitions are envisaged:<br />
* A document may be initiated on either track ("this document will be developed as a Recommendation | Evergreen Recommendation")<br />
* A document previously on the Recommendation track may switch to the Evergreen track; typically this happens after Recommendation status, for maintenance, but may happen on any re-chartering;<br />
* A document on the Evergreen track may enter the Recommendation track by satisfying the requirements for a WG Working Draft or Candidate Recommendation, and entering as such. Generally, when a WG wants to take a document to the Recommendation track they would first take an ER Snapshot to cement patent commitments to date.<br />
** Transition to the REC track does not necessarily mean that specification development as an ER stops because the work is entirely completed. For key parts of the web architecture, the spec is in constant evolution. However moving a snapshot to the REC level provides certain checking and validation for the work (e.g. complete cross-functional and AC review) which adds value in the technology development. There could still be an ER version that is further developed and developers wanting the most up to date version of the specification should use that.<br />
* Although a specification might remain as an ER for many years, there is value for any spec to transition to the REC track, because it is only at the REC track where full horizontal review and AC review is provide. While this value might not be appreciated by all developers that are primarily focused on current state of implementations, it is important for the broader community. The Charter for an ER must specify whether an ER is expected to transition to the Recommendation track - and if so - the expected point in time for transition to W3C Recommendation, even if that time is beyond the time-horizon of a particular charter. If the ER is never expected to transition, the charter should explain how full review is achieved or why it is not necessary for this specification.<br />
= Licensing =<br />
<br />
We intend to have Royalty-Free licensing as with all W3C specs, with licensing commitments made continuously through spec development, and exclusion opportunities prior to final commitment. <br />
<br />
We ask the PSIG to look at spec development in the Evergreen model, the RF licensing requirements of W3C, and the spec review process within a member organization, with this general philosophy: <br />
<br />
Based on the WHATWG [https://whatwg.org/workstream-policy process], perhaps with <br />
* an adjustment of intervals (we probably prefer a longer filing period, say 60 days).<br />
* a provision that WHATWG lacks, for an exclusion opportunity on the current Working Draft, on leaving the WG (to match the Patent Policy, and close a significant gap).<br />
<br />
An exclusion filing must result in:<br />
# A notification to at least the WG general mailing list, the advisory committee, and PSIG, so that the community is immediately aware and can take appropriate steps.<br />
# The formation of a [https://www.w3.org/Consortium/Patent-Policy-20170801/#sec-Exception Patent Advisory Group] (PAG).<br />
# The documentation, in the header of the specification, of the exclusion and the PAG, until the PAG completes its operation and its recommendations implemented.<br />
<br />
= Process Edits =<br />
<br />
There is a [https://www.w3.org/2019/03/Evergreen.html draft] of what the relevant process chapters might look like, under development.<br />
<br />
= *** More detail below *** =<br />
<br />
= Tooling Requirements =<br />
<br />
We have indicated above some of the required tooling for features. Since features achieve greater status by aging (in particular, we assume after 180 days there has been sufficient time for incremental horizontal review), there needs to be tooling so it is easy to determine when a feature was introduced and/or last changed.<br />
<br />
Since features achieve greater status by acquiring implementation experience, testing, and demonstrating interoperability, there needs to be tooling so it is easy to determine that a feature has all of this experience.<br />
<br />
Since a feature is more meaningful to implementors when there are implementation commitments, there must be tooling for that.<br />
<br />
Since a feature is considered normative in an ER when it has 180 days of aging and implementation experience, tooling must make it easy to identify that status as well.<br />
<br />
Tooling related to tagging issues in GH is as follows:<br />
<br />
We need <br />
* to define the standard tags that the report tool will use to work on, for Issues and Pull Requests.<br />
* the report tool to distil Pull Requests by tag (editorial, minor technical, or assumed substantive) and date (first appearance, will hit 180 days in the next 30 days, has passed 180 days, all since merging)<br />
* the report tool to distill Issues by tag also<br />
<br />
Ideally there is a commit hook that generates a "permanent link to this version" header.<br />
<br />
Note that all documents in a Github pages repo can have a unique URL, and are immutable; these come free. Those wanting to reference a specific unchanging version can do that. You can refer to a specific revision in GitHub using htmlpreview or rawgit.com; for example the August 17th version of WebVTT is<br />
<br />
<http://htmlpreview.github.io/?https://github.com/w3c/webvtt/blob/2b24ae60e84e8cbac033c148db2715104e0b9368/index.html><br />
<br />
or rawgit.com<br />
<br />
<https://rawgit.com/w3c/webvtt/2b24ae60e84e8cbac033c148db2715104e0b9368/index.html><br />
<br />
It should be easy to mark a document as under PAG review or under a Formal Objection, while exclusion or FO processing is in progress.<br />
<br />
We might like better support for in-line errata, and provisional material, and the ability to see a document without those (and thus make a snapshot), but this is optional.<br />
<br />
= Tooling Design =<br />
<br />
The tooling is intended to leverage information coming from multiple sources: WPT (tests, results), caniuse.com, specification, github.com, etc.<br />
<br />
For a given section, sub-section, paragraph, we may identify the following:<br />
<br />
# tests<br />
# test results<br />
# feature implementation information<br />
# feature implementation commitment information<br />
# 180 days information<br />
# articles in MDN<br />
<br />
For ES, the annotations will be providing as JSON objects, contained in one file per commit and per specification generated on the day of the ES snapshot, then loaded and render using a JS script. The annotations within a given snapshot are NOT expected to change/involve overtime. In order of preference, each annotation object will be identifiable with:<br />
<br />
* API information (eg AuthenticationExtensionsClientOutputs, AuthenticationExtensionsClientOutputs.rawId)<br />
* CSS property name (eg "background-size")<br />
* Markup elements and attributes (eg "use", "use@width")<br />
* section title (eg "Android Key Attestation Statement Format")<br />
* CSS Selector (eg "pre.idl")<br />
* fragment identifiers (eg #preventSilentAccessCredential)<br />
* section numbering<br />
<br />
The same identifier may apply to more than one annotation object.<br />
<br />
Bikeshed and ReSpec, the most currently used spec editing framework, will need proper support to identify annotation object identifiers as well as WPT, caniuse.com, and MDN identifiers. Test files can be identified by providing a list of files in WPT. Test results can be deduced from that list. A test file may contain more than one test and we will need to work with WPT folks to get a method to identify specific tests within a test file. caniuse.com already provide annotations to integrate a feature implementation information.<br />
<br />
Last update information will be generated based on running diffs with the 180 days-ago version and generating resulting JSON annotation objects. We should be able to leverage the [[https://w3c.github.io/issue-metadata.html|GitHub tagging]], on issues and pull requests. We'll need to explore if the result can be refined using commit history information (see [https://github.com/w3c/payment-request/commits/gh-pages payment-request commits]).<br />
<br />
A tool will generate the annotation file using information embedded within the specification. The specification may contain additional annotation objects to be merged as well. A tool should check the resulting annotations to determine if all annotation objects are still relevant.<br />
<br />
The commit hook will be tasked to generate an ES snapshot and the annotations associated with it.<br />
<br />
= Referenceability =<br />
<br />
For all W3C specifications, it is important to know how they are normatively referenced by other specifications - both on the ER track as well as the REC track.<br />
<br />
It is possible to normatively reference a W3C specification, evergreen or working draft, from a W3C Recommendation as long as the [[https://www.w3.org/2013/09/normative-references|Director's consideration]] are applied, in particular:<br />
<br />
* Stability of the referenced part(s)<br />
* Nature of the dependency<br />
* Status of implementations<br />
<br />
<br />
= Charter, Repository, Document, Testing, and Implementation Requirements =<br />
<br />
WG Charters may declare that a document is developed on the Recommendation Track, or on the Continuous Publication track. Changes between tracks, for any document, require a new approved charter unless the changes are already in the charter. <br />
<br />
In order to enable 'harvesting' of the Github repository URLs of Continuous Publications, by both lawyers and the tools that inform reviewers, the Github repositories must be created before the charter is sent to formal AC review, and the URLs to those repositories must be in the charter, in a section clearly listing those documents on the Continuous Publication track.<br />
<br />
Those Github repositories must be in the W3C space and also must document the publication URL (usually Github.io) of the readable document.<br />
<br />
The readable document must list, in its header, the URL that refers to the latest viewable version, and also a permanent URL to the specific revision being viewed. It should also identify the Github repository where issues are filed and revisions made. As noted above, both unresolved (a) Patent Exclusions and (b) Formal Objections must be documented in the header of the specification.<br />
<br />
The charter must identify the implementability, implementation, test suite, and test pass coverage requirements for a feature to be considered not provisional but final. Features that do not meet these requirements should be integrated first as provisional, and a second Pull Request made to change them to non-provisional, when the requirements are met.<br />
<br />
= Implementation expectations =<br />
<br />
Typically speaking an ER specification will consist of different features at different levels of implementation maturity due to the requirement to be "Evergreen", that is, very reflective of current implementation and thinking among implementors. Included in that are features:<br />
<br />
* For which there is sufficient implementation experience and testing that the Director would ordinarily feel that those features could be approved in a W3C Recommendation.<br />
* For which interoperability has not yet been demonstrated, but there are at least commitments from sufficient implementors that there is a strong likelihood that the features will ultimately be accepted as Recommendations.<br />
* (In rare cases) Draft features that the WG is working on that are significant chartered deliverables being developed in the WG which are expected to be implemented but which lack firm implementation commitments at this time.<br />
<br />
While there could be good reasons to have features of various levels of maturity in a specification, it is important to clarify what part of the specification is actually being given support by W3C for developers to implement.<br />
<br />
For all specifications for which W3C is conferring status, the rule is that the status is only being conferred on those features where there has been sufficient implementation experience and testing to demonstrate interoperability. This is true whether the features are in an ER, an ER snapshot, or a W3C Recommendation.<br />
<br />
That does not mean that the other features need to be stripped from the document. They remain in the document but are considered as informative material for the spec, not normative, endorsed features for implementors.<br />
<br />
This characterization of what parts of the spec are considered normative must appear in the status of the document.<br />
<br />
<br />
= Sample Charter Language =<br />
<br />
The Fruit Action Working Group (FAWG) will develop the following on the Recommendation Track:<br />
* Pineapple picking and handling, <br />
and the following on the Continuous Publication Track,<br />
* Olive picking, pitting, curing and bottling; in the Github Repo (URL goes here)<br />
** The ES spec for Olive picking will have an IPR snapshot every 12 months.<br />
** While the Olive picking spec is on the Continuous Publication Track, it is intended that after 4.7 years, a snapshot will be taken to Recommendation.<br />
<br />
For a feature to be considered final by the working group (on either track):<br />
* it must be testable by a test in the Agricultural Products Test (APT) suite at (URL goes here)<br />
* there must be at least 3 complete implementations<br />
* at least 2 of those implementations must pass the applicable APT tests<br />
* at least 1 of those implementations generates packed olives, and at least one uses packed olives, and they interoperate<br />
<br />
Features that do not meet these requirements will be integrated first as provisional, and a second Pull Request made to change them to non-provisional, when the requirements are met.<br />
<br />
= Sample Document Header =<br />
<br />
Olive picking, pitting, curing and bottling.<br />
<br />
W3C Evergreen Standard 15 March 55BCE<br />
<br />
'''Latest version''': (URL to the evergreen standard goes here)<br />
<br />
'''Permanent link to this version''': (URL for this exact version goes here)<br />
<br />
'''Repository''': (URL to the Github repository for issues etc.)<br />
<br />
'''Editors''': (Editors listed by name)<br />
<br />
'''Current unresolved Patent Licensing Exclusions''': none, or a URL to the exclusion plus a URL to the PAG information<br />
<br />
'''Current unresolved Formal Objections''': none, or a URL to the Formal Objection filing<br />
<br />
'''Abstract''': (as usual)<br />
<br />
'''Status of this document''': <br />
<br />
This document is developed by the (link to Working Group). Comments and issues are welcomed and should be filed at the (URL to the issues page of the Github repository). <br />
<br />
This document was produced by a group operating under the W3C [https://www.w3.org/wiki/Living_Standards Continuous Publication] process and policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with [https://www.w3.org/Consortium/Patent-Policy-20170801/#sec-Disclosure section 6 of the W3C Patent Policy].<br />
<br />
The disclosure obligations of the Participants of this group are described in the Working Group charter.<br />
<br />
= Detailed explanation of the Continuous Track Patent policy =<br />
<br />
Looking for input from PSIG.<br />
<br />
= Summaries for various constituencies =<br />
<br />
== Lawyers ==<br />
<br />
(needs editing to match the snapshot model)<br />
<br />
Lawyers will need to take roughly the following steps:<br />
* Review the charters of the working groups that your organization intends to participate in. <br />
* Collect, from the charters, the URLs of the Continuous Publication repositories and add them to your 'watch list'.<br />
* When you join a working group, review the most recent snapshot and file any applicable exclusions, within the deadline.<br />
* When snapshots are made, review it and file any applicable exclusions, within the deadline.<br />
* Watch other exclusion filings, of course; take any steps you think indicated, and consider joining the PAG.<br />
* Optionally, if you want early notification of changes, watch the monthly automated reports of Pull Requests, or get automated immediate notification by GitHub of Pull Requests, for repositories in your watch list.<br />
* When you leave a working group, do a final exclusion check on the working draft that was current as of the time you left the group.<br />
<br />
== Working Groups ==<br />
<br />
Working groups need to do the following:<br />
* Create Github repositories for your documents on the Continuous Publication track before writing your charter.<br />
* Define clearly in your charter the documents on the Continuous Publication track; list the URIs of their repositories.<br />
* Define clearly in your charter what requirements a feature must meet to be considered acceptable (testing, implementation, interop, etc.).<br />
* Watch Pull Requests and make sure:<br />
** that Pull Requests are correctly tagged (editorial, minor, or, by default, substantive);<br />
** that if Pull Requests add to 'core draft' (ie. material that is not an erratum report, provisional, or editor's note) that the addition meets the WG requirements (testing, implementation, interop, etc.).<br />
* Watch issue filings and tag those also.<br />
<br />
== Editors == <br />
<br />
Editors need to make sure that material that is provisional, an erratum report, or an editor's note, is correctly tagged, and that tags are removed when the material becomes final. If a new feature is too complex to be inserted inline as provisional, manage separate "editor's drafts" that the WG can review until such time as they agree to merging. Check that the 'core draft' reads correctly as well as checking the entire document.<br />
<br />
If there have been any technical changes since the last snapshot, make a new snapshot no later than 180 days after the last one.<br />
<br />
== Other Groups ==<br />
<br />
Read the automated reports and review the changes as they happen. File an issue with at most 180 days if there is a problem. Raise a Formal Objection, ideally within 180 days, if impasse is reached so that Chairs can facilitate a discussion and (if necessary) the Director can get involved if needed to resolve disagreement.<br />
<br />
== Team == <br />
<br />
The team:<br />
* makes sure the process is followed, Charters are correctly drafted, etc.<br />
* makes sure that the Pull Requests (and issues) are tagged correctly, and that technical changes meet the charter requirements;<br />
* makes sure that snapshots are made if technical changes have occurred since the last snapshot, and 180 days are about to elapse;<br />
* ensures that the comments from outside the WG are given due and timely consideration by the WG (notably, within the six months tacit acceptance period);<br />
* when an exclusion is filed, the PAG is formed, notifications sent, and the document header updated (and removed when the PAG is completed);<br />
* when a Formal Objection is filed, notifications sent, and the document header updated (and removed when the Formal Objection is resolved).<br />
<br />
<br />
= Use Cases =<br />
<br />
Possible use cases include: <br />
<br />
* Accessibility API Mappings (see https://github.com/w3c/w3process/issues/79)<br />
* Vocabularies. Most vocabulary definitions have little IPR contention, and grow in a natural incremental fashion.<br />
* Registries. Similar reasons to vocabularies<br />
* Profiles of the Web Platform (e.g Web Media). Profiles of the Web Platform involve little spec development, but indicate which portions of the standards are most appropriate for industry segments.<br />
* Maintenance. Maintenance of specification by nature is intended to track evergreen incremental enhancements rather than bold new features; plus have less IPR contention.<br />
* Core infrastructure. Some specs provide core infrastructure for other specs; but may not need to reach a level of Recommendation per se. Web IDL might be an example.<br />
* Incremental guidance. Specification such as WebAppSec seem well suited for an incremental or evergreen approach.<br />
* All specifications. Some feel that an Evergreen approach is a best fit for all specs.<br />
<br />
<br />
= Documents and their status =<br />
<br />
What is W3C recommending in an ER? What should developers do with it? What can developers depend on, and what risks are there? <br />
<br />
== Status of several kinds of W3C documents ==<br />
For each type of document W3C produces, it conveys "status" of the document based on the process used to generate the document.<br />
<br />
* Community Group Specifications. These documents have no particular W3C status, although the individual contributions come with a level of patent protection through the W3C CLA.<br />
<br />
* Community Group Final Specifications. These documents have no particular W3C Status, although the entire specification comes with enhanced patent protection through the FSA agreement that may be signed by participating organizations.<br />
<br />
* Working Group Working Draft. These documents have no particular W3C status, but they are guaranteed to be within the scope of a WG approved by the Director after review by the AC.<br />
<br />
* Working Group Candidate Recommendation. These documents, like Working Drafts are within an approved scope. Additionally, they:<br />
** Have met the requirements of the WG, or explained why the requirements have changed.<br />
** Have addressed issues raised<br />
** Represent the consensus of the WG<br />
** Have a plan to demonstrate implementation experience<br />
** Have received wide review (including horizontal review)<br />
** Have received Director's approval for this status<br />
<br />
* Working Group Recommendation. These documents have all of the status attributes of CR documents. They have the additional status of:<br />
** Have demonstrated implementation experience<br />
** Have W3C Royalty Free licensing commitments associated with the specification.<br />
** Have received AC review of the spec<br />
** Have ensured that all Formal Objections are resolved through Director review<br />
** Have an Appeals process if the AC disagrees with the Director<br />
** Represents a stable reference.<br />
** Has been adopted<br />
<br />
* ''Proposed'' Evergreen Recommendations<br />
** Are within the approved scope of a WG<br />
** Represent the consensus of a WG (driven by the editor with oversight from the WG chair)<br />
** Have demonstrated implementation experience<br />
** Have received incremental wide review (including incremental horizontal review)<br />
** All key horizontal issues have been resolved<br />
** Have ER contribution Patent Commitments associated with the spec<br />
<br />
Thus the ER has achieved much of what the community is looking for and hence W3C confers it with the status of ER which both informs the community of what they can rely on, and also establishes where there is incompleteness.<br />
<br />
The most serious incompleteness is the incompleteness of patent commitments. Accordingly, it is expected that the WG will on a regular basis (e.g. every 12 months) create an ER Snapshot which gets the benefit of full patent commitments for the ER spec.<br />
<br />
* Proposed ER to REC, adds <br />
** Full wide review (including horizontal review)<br />
** Director approval<br />
** Received an AC review of the spec<br />
** Ensured that all Formal Objections are resolved through Director review<br />
** The benefit of an Appeals process if the AC disagrees with the Director<br />
** A stable reference.<br />
<br />
= Different Evergreen Models =<br />
<br />
There is a choice between a âsnapshot' and sliding-window model, for both IPR review and functional review. What we have here is hybrid -- sliding-window for the technical reviewers, snapshot for the IPR.<br />
<br />
This is like the WHATWG [https://whatwg.org/workstream-policy process] which requires a periodic manual "review draft" ('snapshot') approximately every 6 months, and at that time all the legal reviewers have 45 days to respond. WhatWG doesnât have liaisons, cross-functional groups, an Advisory Committee, or Director/team.<br />
<br />
In the sliding-window model, we deem all the technical groups (external, cross-functional, Advisory Committee, and Director/team) to have tacitly accepted features 180 days after they first appear, unless they file an issue. This incremental tacit acceptance is sufficient for W3C to confer status on an ER that there is sufficient review to be reasonably confident that a feature is stable and can be implemented. But it is less than the status associated with a full W3C Recommendation which has had wider and more complete review.<br />
<br />
If an issue has been raised, the editor has the lead role to address the issue and re-establish consensus. This is discussed in: [https://www.w3.org/wiki/Evergreen_Standards#Roles_and_Responsibilities_in_the_Evergreen_Model Roles and Responsibilities]<br />
<br />
There is little '''functional''' difference between âWeâll keep you informed of the grocery list as it builds, and you must do your grocery shopping at least once a weekâ and âYou must do your grocery shopping immediately when the editor issues the weekly shopping listâ â it is the same amount of work, at the same frequency; but the former allows you to choose when, and indeed spread it out if you want to, while the latter says âjump nowâ. But there is a difference of work-mode.<br />
<br />
<br />
<br />
= Comparison of the Continuous and Traditional Recommendation Tracks =<br />
<br />
{| class="wikitable"<br />
|-<br />
! Concept !! Continuous !! Traditional<br />
|-<br />
| wide review || Incremental, by automatic notification and lack of objection || On Transitions<br />
|-<br />
| horizontal review (i18n, a11y, security, privacy, perf, device independence, TAG, etc.) || Incremental, by automatic notification and lack of objection || On Transitions<br />
|-<br />
| Advisory Committee review || Incremental, by automatic notification and lack of objection || On Transitions<br />
|-<br />
| tests || Defined in charter, verified by WG and reviewers incrementally || Defined in charter, verified by WG and reviewers on transitions<br />
|-<br />
| issues addressed || Verified incrementally || Verified on transitions<br />
|-<br />
| IP || Whole spec from all WG members given exclusion opportunity at a snapshot || Whole spec from all WG members at Rec<br />
|-<br />
| consensus || verified continuously || verified at transitions etc.<br />
|-<br />
| errata || In issues and possibly inline || Not well handled; in issues or possible erratum document<br />
|-<br />
| maintenance || Ongoing || Episodic<br />
|-<br />
| use cases || In charter or requirements document (which may also be Continuous) || In charter or Wiki or somewhere<br />
|-<br />
| requirements || In charter or requirements document (which may also be Continuous) || In charter or Wiki or somewhere<br />
|-<br />
| implementation commitments || Requirements defined by charter || Requirements defined by charter<br />
|-<br />
| implementation experience || Requirements defined by charter || Requirements defined by charter<br />
|-<br />
| Director's approval || Incremental, tacit unless objections raised || On transitions<br />
|-<br />
| Appeal process || After Formal Objection || After Formal Objection<br />
|-<br />
| stable reference || By using specific revision references or periodic Rec snapshots || Normal<br />
|-<br />
| adoption || Requirements defined by charter || Requirements defined by charter<br />
|-<br />
| status duration || Indefinite || Indefinite<br />
|}</div>Plehegarhttps://www.w3.org/wiki/index.php?title=Evergreen_Standards&diff=108651Evergreen Standards2018-12-17T21:26:49Z<p>Plehegar: /* Tooling Design */</p>
<hr />
<div>= Introduction =<br />
<br />
== Overview ==<br />
<br />
We are looking at the [https://www.w3.org/2001/tag/doc/evergreen-web/ Evergreen Standards] (also known as living standards) model as a possible alternative way to develop and publish W3C Recommendations. Many Working Groups already publish frequent iterative working drafts, and continuously resolve issues, test, review, and maintain specs at the "top of tree," so we ask what it would take to make those living documents into formal publications of the W3C. In the analysis, we consider various aspects and values embodied in the current W3C Process and Patent Policy to assess how those can be met in an iterative mode. <br />
<br />
This proposed mode is designed for continuous development of specifications. We propose to call this "Continuous Publication" process Evergreen Standards. The suggested name for the product here is Evergreen Recommendation. There are two types of Evergreen Recommendations (ERs). The vanilla form is called an ER. Additionally, snapshots might be taken for IPR purposes and those are called ER Snapshots.<br />
<br />
In particular, this program aims to manage specifications on a continuous basis, with a minimum of manual process steps needed, so that in the specifications<br />
* all material that has been in the specification for six months or more has been '''available''' for review:<br />
** by the community â but particularly the working group, the Advisory Committee, and the Team â that the specification meets the charter requirements (for testing, implementation, and interoperability, for example);<br />
** by the cross-functional groups for acceptability;<br />
** by the liaison groups and the wider public for acceptability.<br />
* all material that has passed a snapshot exclusion opportunity carries a license to the unexcluded essential IPR from those who had the opportunity<br />
<br />
We say that the material has been "available" for review because we envisage "incremental" review by the entire community including cross-functional, horizontal, and liaison groups. We generally believe that a duration of 180 days should be sufficient to catch almost any cross-functional issues. But we also recognize that not all cross-functional review can take place at that time frame. So we provide a level of status to Evergreen Recommendations, and a higher level of status when taken to the Recommendations track for a full review.<br />
<br />
Under the current [https://www.w3.org/2018/Process-20180201/ Process] and [https://www.w3.org/Consortium/Patent-Policy-20170801/ Patent Policy], royalty-free patent commitments attach when a document is published as a Recommendation, after exclusion periods at FPWD (first public working draft) and CR (Candidate Recommendation). We propose that for continuous publication, there be periodic snapshots, after which patents not excluded would be licensed royalty-free.<br />
<br />
This is a close companion to the separately discussed [[Repositories]] question.<br />
<br />
We expect this model to apply in two general cases, but see more about [https://www.w3.org/wiki/Evergreen_Standards#Use_Cases use cases] below.<br />
* Specifications which are, in a sense, built of small independent pieces, where those pieces are added incrementally, for example a document that has a set of independent APIs that map to other features<br />
* Maintenance of Recommendations, where bug fixes and minor missing features can be added with less pain than the 'revised recommendation'.<br />
<br />
== Transitions between the Evergreen and Recommendation Tracks ==<br />
<br />
The following initiations or transitions are envisaged:<br />
* A document may be initiated on either track ("this document will be developed as a Recommendation | Evergreen Standard")<br />
* A document previously on the Recommendation track may switch to the Evergreen track; typically this happens after Recommendation status, for maintenance, but may happen on any re-chartering;<br />
* A document on the Evergreen track may enter the Recommendation track by satisfying the requirements for a WG Working Draft or Candidate Recommendation, and entering as such. This would typically be an ER Snapshot.<br />
** Transition to the REC track does not necessarily mean that specification development as an ES stops because the work is entirely completed. For key parts of the web architecture, the spec is in constant evolution. However moving a snapshot to the REC level provides certain checking and validation for the work (e.g. complete cross-functional and AC review) which adds value in the technology development. There could still be an ES version that is further developed and developers wanting the most up to date version of the specification should use that.<br />
* Although a specification might remain as an ER for many years, there is an expectation that ultimately every spec transitions to the REC track, because it is only at the REC track where full horizontal review and AC review is provide. The Charter for an ES spec must specify the expected point in time for transition to W3C Recommendation, even if that time is beyond the time horizon of a particular charter.<br />
<br />
= Use Cases =<br />
<br />
There is debate in the community whether to apply the Evergreen Standards approach for all standards or only for limited use cases. We don't take a position on this question at the moment in the document, but we list here some of the proposed use cases that have been mentioned:<br />
<br />
* Accessibility API Mappings (see https://github.com/w3c/w3process/issues/79)<br />
* Vocabularies. This is because most vocabulary defintions have little IPR contention, and grow in a natural incremental fashion.<br />
* Registries. Similar reasons to vocabularies<br />
* Profiles of the Web Platform (e.g Web Media). Profiles of the Web Platform involve little spec development, but indicate which portions of the standards are most appropriate for industry segments.<br />
* Maintenance. Maintenance of specification by nature is intended to track evergreen incremental enhancements rather than bold new features; plus have less IPR contention.<br />
* Core infrastructure. Some specs provide core infrastructure for other specs; but may not need to reach a level of Recommendation per se. Web IDL might be an example.<br />
* Incremental guidance. Specification such as WebAppSec seem well suited for an incremental or evergreen approach.<br />
* All specifications. There are those that feel that an Evergreen approach is a best fit for all specs.<br />
<br />
= Roles and Responsibilities in the Evergreen Model =<br />
<br />
As with any W3C Working Group, there are Chairs for the group, Editors for the documents of the group, and participants in the group. However the roles and responsibilities are somewhat different in these groups.<br />
<br />
For an Evergreen Standard, the Editors of the specification have the primary role to ensure that the specification represents the current consensus of the Working Group. This is done by informal means: regular conversations between the editor and participants; participants raising issues about the spec in github; editors addressing issues and pull requests; and editors tracking implementations to ensure that the ER is both reflective of implementation as well as sensitive to the issues raised by the community. The Editor achieves this consensus without issuing formal calls for consensus; instead the Editor is continually in contact with the group to ensure that the ER document represents a consensus.<br />
<br />
As opposed to the REC track, the Chair does not have the responsibility to call for consensus or assess consensus as a result of a poll of participants. But the Chair has an important oversight role to ensure that the group's discussions proceed professionally and in accordance to CEPC, and to be a resource for participants who disagree with the way that the editors are documenting the evolving consensus of the group. If a participant believes that the editor is not behaving fairly, the chair is a resource to facilitate discussion between the chair and editor. If that does not solve the issue, the chair may also issue informative calls for consensus, or engage in other discussions to see whether consensus can be reached or whether the editor can adjust their position. <br />
<br />
Despite this important facilitation role of the chair, they generally do not have the authority to overrule the sense of the editor of where consensus lies during the ER phase of a specification development. However, in an extreme case, the chair can request that the Director look into the situation and possibly remove the chair.<br />
<br />
We discussed in the [https://www.w3.org/wiki/Evergreen_Standards#Overview Overview] that we expect incremental community review of an ER. It is the responsibility of the chair to ensure that there is appropriate notification to review groups about the progress of the ER.<br />
<br />
However, when the ER is ready to make the transition to the REC track, the chairs will have a more significant role assessing consensus in the usual way.<br />
<br />
= Documents and their status =<br />
<br />
We have described the mechanics of how a WG group develops an ER, with the editor assessing consensus and seeking incremental wide review. The next question is, if this is done successfully, then what is W3C recommending in terms of the spec? What should developers do with it? What can developers depend on, and what risks are there? <br />
<br />
We address that in this section, but first we take a broader view of different W3C documents and what W3C is saying about them. After all, W3C provides many types of documents. For each type of document, W3C conveys "status" to the document based on the process used to generate the document.<br />
<br />
* Community Group Specifications. These documents have no particular W3C status, although the individual contributions come with a level of patent protection through the W3C CLA.<br />
<br />
* Community Group Final Specifications. These documents have no particular W3C Status, although the entire specification comes with enhanced patent protection through the FSA agreement that may be signed by participating organizations.<br />
<br />
* Working Group Working Draft. These documents have no particular W3C status, but they are guaranteed to be within the scope of a WG approved by the Director after review by the AC.<br />
<br />
* Working Group Candidate Recommendation. These documents, like Working Drafts are within an approved scope. Additionally, they:<br />
** Have met the requirements of the WG, or explained why the requirements have changed.<br />
** Have addressed issues raised<br />
** Represent the consensus of the WG<br />
** Have a plan to demonstrate implementation experience<br />
** Have received wide review (including horizontal review)<br />
** Have received Director's approval for this status<br />
<br />
* Working Group Recommendation. These documents have all of the "status" as CR documents. They have the additional status of:<br />
** Have demonstrated implementation experience<br />
** Have W3C Royalty Free licensing commitments associated with the specification.<br />
** Have received AC review of the spec<br />
** Have ensured that all Formal Objections are resolved through Director review<br />
** Have an Appeals process if the AC disagrees with the Director<br />
** Represents a stable reference.<br />
** Has been adopted<br />
<br />
That brings us to Evergreen Standards. One the one hand, W3C needs a track for them because W3C's TAG has determined that there is an Evergreen Web [1]. But that puts pressure on the Standards Development Process. Standards must constantly be updated to ensure the Web's usefulness. But it is not possible to achieve all of the "status" features of a W3C Recommendation and be responsive to that time frame.<br />
<br />
That is why W3C is introducing an experimental path called Evergreen Standards to address that. In ES, there is a continuous evolution of the standard and a patent policy which provides continually improving patent commitments. Key features of the W3C process such as document review are done incrementally. This results in a document, the Evergreen Recommendation, that has sufficient review that W3C can provide a ''tentative recommendation'' to implementors that the spec may be implemented - while acknowledging that it does not have the full "status" of a W3C Recommendation. <br />
<br />
So, ''incremental review'' means that the WG operates in a fashion that:<br />
* The regularly announce that their documents should get wide review<br />
* They specifically maintain a relationship with horizontal reviewers to get their review<br />
* But, they may be operating too quickly for a full wide review.<br />
<br />
For that reason, in a charter which specifies that a spec will be developed as an ES, the charter will indicate a time frame for the ES spec to be taken to a Recommendation. There might be several years of development on the ES path, yet there is an expectation that at some point a REC will be achieved as well. There may be circumstances where the Director and AC conclude that the REC path is not necessary.<br />
<br />
* Accordingly, an Evergreen Recommendation has the following "status" associated with it:<br />
** Are within the approved scope of a WG<br />
** Represent the consensus of a WG (driven by the editor with oversight from the WG chair)<br />
** Have demonstrated implementation experience<br />
** Have received incremental wide review (including incremental horizontal review)<br />
** All key horizontal issues have been resolved<br />
** Have ES contribution Patent Commitments associated with the spec<br />
<br />
Thus the ES has achieved much of what the community is looking for and hence W3C confers it with the status of ES which both informs the community of what they can rely on, and also establishes where there is incompleteness.<br />
<br />
The most serious incompleteness is the incompleteness of patent commitments. Accordingly, it is expected that the WG will on a regular basis (e.g. every 12 months) create an ER Snapshot which gets the benefit of full patent commitments for the ER spec.<br />
<br />
That still does not provide all of the value of a complete consensus process with the widest possible review. Accordingly, at an even less frequent review cycle, snapshots are taken through the full REC process.<br />
<br />
* Accordingly, the benefit of ultimately taking an ER spec to a REC as well is to ensure that the spec ultimately has:<br />
** Full wide review (including horizontal review)<br />
** Director approval<br />
** Received an AC review of the spec<br />
** Ensured that all Formal Objections are resolved through Director review<br />
** The benefit of an Appeals process if the AC disagrees with the Director<br />
** A stable reference.<br />
<br />
[1] https://www.w3.org/2001/tag/doc/evergreen-web/<br />
<br />
= Different Evergreen Models =<br />
<br />
There is a choice between a âsnapshot' and sliding-window model, for both IPR review and functional review. What we have here is hybrid -- sliding-window for the technical reviewers, snapshot for the IPR.<br />
<br />
This is like the WHATWG [https://whatwg.org/workstream-policy process] which requires a periodic manual "review draft" ('snapshot') approximately every 6 months, and at that time all the legal reviewers have 45 days to respond. WhatWG doesnât have liaisons, cross-functional groups, an Advisory Committee, or Director/team.<br />
<br />
In the sliding-window model, we deem all the technical groups (external, cross-functional, Advisory Committee, and Director/team) to have tacitly accepted features 180 days after they first appear, unless they file an issue. This incremental tacit acceptance is sufficient for W3C to confer status on an ER that there is sufficient review to be reasonably confident that a feature is stable and can be implemented. But it is less than the status associated with a full W3C Recommendation which has had wider and more complete review.<br />
<br />
If an issue has been raised, the editor has the lead role to address the issue and re-establish consensus. This is discussed in: [https://www.w3.org/wiki/Evergreen_Standards#Roles_and_Responsibilities_in_the_Evergreen_Model Roles and Responsibilities]<br />
<br />
There is little '''functional''' difference between âWeâll keep you informed of the grocery list as it builds, and you must do your grocery shopping at least once a weekâ and âYou must do your grocery shopping immediately when the editor issues the weekly shopping listâ â it is the same amount of work, at the same frequency; but the former allows you to choose when, and indeed spread it out if you want to, while the latter says âjump nowâ. But there is a difference of work-mode.<br />
<br />
= Licensing =<br />
<br />
We require the PSIG to look at spec development in the Evergreen model, the RF licensing requirements of W3C, and the spec review process within a member organization. But the general philosophy around licensing should be:<br />
<br />
Based on the WHATWG [https://whatwg.org/workstream-policy process], perhaps with <br />
* an adjustment of intervals (we probably prefer a longer filing period, say 60 days).<br />
* a provision that WHATWG lacks, for an exclusion opportunity on the current Working Draft, on leaving the WG (to match the Patent Policy, and close a significant gap).<br />
<br />
An exclusion filing must result in:<br />
# A notification to at least the WG general mailing list, the advisory committee, and PSIG, so that the community is immediately aware and can take appropriate steps.<br />
# The formation of a [https://www.w3.org/Consortium/Patent-Policy-20170801/#sec-Exception Patent Advisory Group] (PAG).<br />
# The documentation, in the header of the specification, of the exclusion and the PAG, until the PAG completes its operation and its recommendations implemented.<br />
<br />
<br />
<br />
= Advisory Committee (AC), Director, Cross-functional, and Wide Review =<br />
<br />
The W3C has a value that all substantive changes are subject to these four kinds of review: "horizontal review," "wide review,", Director, and Advisory Committee review. For Continuous Publication, we mandate automated reports to the AC and cross-functional groups on a regular basis, reporting on substantive changes. This is what provides the signal to cross functional groups that they may perform their reviews, but does not guarantee that the reviews will take place. If the WG is rapidly making additions to the spec, it is possible that cross function groups will not have the ability for a full review. But the notification ensures that there will at least be an incremental review.<br />
<br />
In the past, cross-functional groups have been at "arms length", and doing reviews only at major transitions. Now we're asking for more incubation, experimental implementation, and so on, waiting for a transition in the REC process may be too late; there may be implementations, test suites, and designs that follow on from a feature, already in place. For both continuous publications and the traditional rec-track process, cross-functional groups need to be noticing issues and changes as they arise, and reacting as soon as possible when they see problems, ideally by having people 'embedded' in those other working groups, but minimally by watching specification progress.<br />
<br />
External groups should be notified by liaison of the existence of the Continuous Publication, as early as is practical and useful, and agreement reached with them how they will review substantive changes. They may request to be added to the automated report, for example; they may elect to watch the repository manually; or ask to be notified manually by the WG e.g. in liaison or email. Such manual notification should be both archived and also occur no less frequently than every 180 days.<br />
<br />
There is a 180-day period before changes are considered reviewed and accepted. This period starts on the first report that details the change (even if it was later reverted and re-inserted). Note that anyone, including AC, cross-functional groups, public, and members of the WG, are free to comment on anything at any time, of course; the 180-day deadline merely sets a date before which changes ought to be considered by the working group, and after which they might apply more back-pressure.<br />
<br />
This implies a tooling requirement. There must be simple to use automated tools which inform the community when a change has been made so that way they know which changes are about to become accepted. Further, a reviewer who has reviewed the document in the past will want to know the changes since their last review.<br />
<br />
To enable the automated reports, all changes must be made through Pull Requests (no direct commits). Pull Requests are considered '''substantive''' unless tagged as "Editorial" or "Minor technical". Issues are assumed non-substantive '''unless''' tagged explicitly as substantive (to avoid flooding the reports with issues that have not yet been categorized).<br />
<br />
(Note that the tagging for issues is necessarily the opposite to Pull Requests, as we don't want to report untagged, newly filed, issues, that the WG has not yet considered, as automatically substantive.)<br />
<br />
The automated report must detail:<br />
* new substantive changes since the prior report<br />
* substantive changes that will be declared past their 180 day review period in the next automated report (i.e. a kind of 'last call' for comments)<br />
* substantive changes that have just passed their 180 review period<br />
* all other changes (minor, editorial, etc.) performed via Pull Requests<br />
* suitable reporting on issues, noting particularly any tagged "substantive" or "cross-functional" (recently opened, recently closed, tagged substantive but still open, etc.)<br />
<br />
(Note the the WG, cross-functional groups, external bodies, and AC are at liberty to request other tags, e.g. identifying issues or pull requests of particular concern to those communities; we already have a substantial set of [https://w3c.github.io/issue-metadata.html tags].)<br />
<br />
For any issue filed against the document, the WG should consider whether an inline "issue" or âerratumâ notice should be placed in the document.<br />
<br />
For âreviewâ issues filed by the AC, a cross-functional W3C group, or by an external âliaisonâ body, the filing group can request, at any time after filing the issue and until the issue is resolved, any or all of:<br />
# that there be an inline issue/erratum notice, and/or <br />
# that the feature be marked as âprovisionalâ<br />
#that the feature be removed until consensus is reached.<br />
The WG is not automatically obliged to grant any request, but note that such denial may escalate the disagreement.<br />
<br />
If the WG and filer are unable to reach consensus, then the usual recourse to Formal Objections, Appeals, and Director rulings can be followed. As the continuous publication process does not entail formal Transitions, Director review can be triggered by the filer and WG deciding that they are at an impasse and one of them filing a Formal Objection. Formal Objections must be documented in the header of the document until the resolution is implemented. <br />
<br />
Since features that are stable in the specification for 180 days are considered final (there is an implied "acceptance" decision), disagreements should be raised to the editor, and then to the chairs before that 180-day period expires. If an issue is raised to the editor and the chair does not feel that the editor has sufficiently addressed the issue, the chair may appeal to the Director; possibly removing the editor.<br />
<br />
Similarly, if a participant has raised an issue and believes that neither is appropriately addressing their issue, they should Formally Object to the Director prior to a feature being around for 180 days. But they may only do that if they have first raised the issue with the editor and the chair and they have not gotten satisfaction.<br />
<br />
= Charter, Repository, Document, Testing, and Implementation Requirements =<br />
<br />
WG Charters may declare that a document is developed on the Recommendation Track, or on the Continuous Publication track. Changes between tracks, for any document, require a new approved charter. <br />
<br />
In order to enable 'harvesting' of the Github repository URLs of Continuous Publications, by both lawyers and the tools that inform reviewers, the Github repositories must be created before the charter is sent to formal AC review, and the URLs to those repositories must be in the charter, in a section clearly listing those documents on the Continuous Publication track.<br />
<br />
Those Github repositories must be in the W3C space and also must document the publication URL (usually Github.io) of the readable document.<br />
<br />
The readable document must list, in its header, the URL that refers to the latest viewable version, and also a permanent URL to the specific revision being viewed. It should also identify the Github repository where issues are filed and revisions made. As noted above, both unresolved (a) Patent Exclusions and (b) Formal Objections must be documented in the header of the specification.<br />
<br />
The charter must identify the implementability, implementation, test suite, and test pass coverage requirements for a feature to be considered not provisional but final. Features that do not meet these requirements should be integrated first as provisional, and a second Pull Request made to change them to non-provisional, when the requirements are met.<br />
<br />
= Implementation expectations =<br />
<br />
Typically speaking an ES specification will consist of different features at different levels of implementation maturity due to the requirement to be "Evergreen", that is, very reflective of current implementation and thinking among implementors. Included in that are features:<br />
<br />
* For which there is sufficient implementation experience and testing that the Director would ordinarily feel that those features could be approved in a W3C Recommendation.<br />
* For which interoperability has not yet been demonstrated, but there are at least commitments from sufficient implementors that there is a strong likelihood that the features will ultimately be accepted as Recommendations.<br />
* (In rare cases) Draft features that the WG is working on that are significant chartered deliverables being developed in the WG which are expected to be implemented but which lack firm implementation commitments at this time.<br />
<br />
While there could be good reasons to have features of various levels of maturity in a specification, it is important to clarify what part of the specification is actually being given support by W3C for developers to implement.<br />
<br />
For all specifications for which W3C is conferring status, the rule is that the status is only being conferred on those features where there has been sufficient implementation experience and testing to demonstrate interoperability. This is true whether the features are in an ES, an ES snapshot, or a W3C Recommendation.<br />
<br />
That does not mean that the other features need to be stripped from the document. They remain in the document but are considered as informative material for the spec, not normative, endorsed features for implementors.<br />
<br />
This characterization of what parts of the spec are considered normative must appear in the status of the document.<br />
<br />
= Tooling Requirements =<br />
<br />
There are various forms of tooling requirements. Some of them are tooling for the specs, to identify metadata about feature status. Other tooling relates to tagging issues in the Github repository for the spec.<br />
<br />
We have indicated above some of the required tooling for features. Since features achieve greater status by aging (in particular, we assume after 180 days there has been sufficient time for incremental horizontal review), there needs to be tooling so it is easy to determine when a feature was introduced and/or last changed.<br />
<br />
Since features achieve greater status by acquiring implementation experience, testing, and demonstrating interoperability, there needs to be tooling so it is easy to determine that a feature has all of this experience.<br />
<br />
Since a feature is more meaningful to implementors when there are implementation commitments, there must be tooling for that.<br />
<br />
Since a feature is considered normative in an ES when it has 180 days of aging and implementation experience, tooling must make it easy to identify that status as well.<br />
<br />
Tooling related to tagging issues in GH is as follows:<br />
<br />
We need <br />
* to define the standard tags that the report tool will use to work on, for Issues and Pull Requests.<br />
* the report tool to distil Pull Requests by tag (editorial, minor technical, or assumed substantive) and date (first appearance, will hit 180 days in the next 30 days, has passed 180 days, all since merging)<br />
* the report tool to distill Issues by tag also<br />
<br />
Ideally there is a commit hook that generates a "permanent link to this version" header.<br />
<br />
Note that all documents in a Github pages repo can have a unique URL, and are immutable; these come free. Those wanting to reference a specific unchanging version can do that. You can refer to a specific revision in GitHub using htmlpreview or rawgit.com; for example the August 17th version of WebVTT is<br />
<br />
<http://htmlpreview.github.io/?https://github.com/w3c/webvtt/blob/2b24ae60e84e8cbac033c148db2715104e0b9368/index.html><br />
<br />
or rawgit.com<br />
<br />
<https://rawgit.com/w3c/webvtt/2b24ae60e84e8cbac033c148db2715104e0b9368/index.html><br />
<br />
It should be easy to mark a document as under PAG review or under a Formal Objection, while exclusion or FO processing is in progress.<br />
<br />
We might like better support for in-line errata, and provisional material, and the ability to see a document without those (and thus make a snapshot), but this is optional.<br />
<br />
= Tooling Design =<br />
<br />
The tooling is intended to leverage information coming from multiple sources: WPT (tests, results), caniuse.com, specification, github.com, etc.<br />
<br />
For a given section, sub-section, paragraph, we may identify the following:<br />
<br />
# tests<br />
# test results<br />
# feature implementation information<br />
# feature implementation commitment information<br />
# 180 days information<br />
# articles in MDN<br />
<br />
For ES, the annotations will be providing as JSON objects, contained in one file per commit and per specification generated on the day of the ES snapshot, then loaded and render using a JS script. The annotations within a given snapshot are NOT expected to change/involve overtime. In order of preference, each annotation object will be identifiable with:<br />
<br />
* API information (eg AuthenticationExtensionsClientOutputs, AuthenticationExtensionsClientOutputs.rawId)<br />
* CSS property name (eg "background-size")<br />
* Markup elements and attributes (eg "use", "use@width")<br />
* section title (eg "Android Key Attestation Statement Format")<br />
* CSS Selector (eg "pre.idl")<br />
* fragment identifiers (eg #preventSilentAccessCredential)<br />
* section numbering<br />
<br />
The same identifier may apply to more than one annotation object.<br />
<br />
Bikeshed and ReSpec, the most currently used spec editing framework, will need proper support to identify annotation object identifiers as well as WPT, caniuse.com, and MDN identifiers. Test files can be identified by providing a list of files in WPT. Test results can be deduced from that list. A test file may contain more than one test and we will need to work with WPT folks to get a method to identify specific tests within a test file. caniuse.com already provide annotations to integrate a feature implementation information.<br />
<br />
Last update information will be generated based on running diffs with the 180 days-ago version and generating resulting JSON annotation objects. We should be able to leverage the [[https://w3c.github.io/issue-metadata.html|GitHub tagging]], on issues and pull requests. We'll need to explore if the result can be refined using commit history information (see [https://github.com/w3c/payment-request/commits/gh-pages payment-request commits]).<br />
<br />
A tool will generate the annotation file using information embedded within the specification. The specification may contain additional annotation objects to be merged as well. A tool should check the resulting annotations to determine if all annotation objects are still relevant.<br />
<br />
The commit hook will be tasked to generate an ES snapshot and the annotations associated with it.<br />
<br />
= Referenceability =<br />
<br />
For all W3C specifications, it is important to know how they are normatively referenced by other specifications - both on the ES track as well as the REC track.<br />
<br />
It is possible to normatively reference a W3C specification, evergreen or working draft, from a W3C Recommendation as long as the [[https://www.w3.org/2013/09/normative-references|Director's consideration]] are applied, in particular:<br />
<br />
* Stability of the referenced part(s)<br />
* Nature of the dependency<br />
* Status of implementations<br />
<br />
= Sample Charter Language =<br />
<br />
The Fruit Action Working Group (FAWG) will develop the following on the Recommendation Track:<br />
* Pineapple picking and handling, <br />
and the following on the Continuous Publication Track,<br />
* Olive picking, pitting, curing and bottling; in the Github Repo (URL goes here)<br />
** The ES spec for Olive picking will have an IPR snapshot every 12 months.<br />
** While the Olive picking spec is on the Continuous Publication Track, it is intended that after 4.7 years, a snapshot will be taken to Recommendation.<br />
<br />
For a feature to be considered final by the working group (on either track):<br />
* it must be testable by a test in the Agricultural Products Test (APT) suite at (URL goes here)<br />
* there must be at least 3 complete implementations<br />
* at least 2 of those implementations must pass the applicable APT tests<br />
* at least 1 of those implementations generates packed olives, and at least one uses packed olives, and they interoperate<br />
<br />
Features that do not meet these requirements will be integrated first as provisional, and a second Pull Request made to change them to non-provisional, when the requirements are met.<br />
<br />
= Sample Document Header =<br />
<br />
Olive picking, pitting, curing and bottling.<br />
<br />
W3C Evergreen Standard 15 March 55BCE<br />
<br />
'''Latest version''': (URL to the evergreen standard goes here)<br />
<br />
'''Permanent link to this version''': (URL for this exact version goes here)<br />
<br />
'''Repository''': (URL to the Github repository for issues etc.)<br />
<br />
'''Editors''': (Editors listed by name)<br />
<br />
'''Current unresolved Patent Licensing Exclusions''': none, or a URL to the exclusion plus a URL to the PAG information<br />
<br />
'''Current unresolved Formal Objections''': none, or a URL to the Formal Objection filing<br />
<br />
'''Abstract''': (as usual)<br />
<br />
'''Status of this document''': <br />
<br />
This document is developed by the (link to Working Group). Comments and issues are welcomed and should be filed at the (URL to the issues page of the Github repository). <br />
<br />
This document was produced by a group operating under the W3C [https://www.w3.org/wiki/Living_Standards Continuous Publication] process and policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with [https://www.w3.org/Consortium/Patent-Policy-20170801/#sec-Disclosure section 6 of the W3C Patent Policy].<br />
<br />
The disclosure obligations of the Participants of this group are described in the Working Group charter.<br />
<br />
= Detailed explanation of the Continuous Track Patent policy =<br />
<br />
Looking for input from PSIG.<br />
<br />
= Summaries for various constituencies =<br />
<br />
== Lawyers ==<br />
<br />
(needs editing to match the snapshot model)<br />
<br />
Lawyers will need to take roughly the following steps:<br />
* Review the charters of the working groups that your organization intends to participate in. <br />
* Collect, from the charters, the URLs of the Continuous Publication repositories and add them to your 'watch list'.<br />
* When you join a working group, review the most recent snapshot and file any applicable exclusions, within the deadline.<br />
* When snapshots are made, review it and file any applicable exclusions, within the deadline.<br />
* Watch other exclusion filings, of course; take any steps you think indicated, and consider joining the PAG.<br />
* Optionally, if you want early notification of changes, watch the monthly automated reports of Pull Requests, or get automated immediate notification by GitHub of Pull Requests, for repositories in your watch list.<br />
* When you leave a working group, do a final exclusion check on the working draft that was current as of the time you left the group.<br />
<br />
== Working Groups ==<br />
<br />
Working groups need to do the following:<br />
* Create Github repositories for your documents on the Continuous Publication track before writing your charter.<br />
* Define clearly in your charter the documents on the Continuous Publication track; list the URIs of their repositories.<br />
* Define clearly in your charter what requirements a feature must meet to be considered acceptable (testing, implementation, interop, etc.).<br />
* Watch Pull Requests and make sure:<br />
** that Pull Requests are correctly tagged (editorial, minor, or, by default, substantive);<br />
** that if Pull Requests add to 'core draft' (ie. material that is not an erratum report, provisional, or editor's note) that the addition meets the WG requirements (testing, implementation, interop, etc.).<br />
* Watch issue filings and tag those also.<br />
<br />
== Editors == <br />
<br />
Editors need to make sure that material that is provisional, an erratum report, or an editor's note, is correctly tagged, and that tags are removed when the material becomes final. If a new feature is too complex to be inserted inline as provisional, manage separate "editor's drafts" that the WG can review until such time as they agree to merging. Check that the 'core draft' reads correctly as well as checking the entire document.<br />
<br />
If there have been any technical changes since the last snapshot, make a new snapshot no later than 180 days after the last one.<br />
<br />
== Other Groups ==<br />
<br />
Read the automated reports and review the changes as they happen. File an issue with at most 180 days if there is a problem. Raise a Formal Objection, ideally within 180 days, if impasse is reached so that Chairs can facilitate a discussion and (if necessary) the Director can get involved if needed to resolve disagreement.<br />
<br />
== Team == <br />
<br />
The team:<br />
* makes sure the process is followed, Charters are correctly drafted, etc.<br />
* makes sure that the Pull Requests (and issues) are tagged correctly, and that technical changes meet the charter requirements;<br />
* makes sure that snapshots are made if technical changes have occurred since the last snapshot, and 180 days are about to elapse;<br />
* ensures that the comments from outside the WG are given due and timely consideration by the WG (notably, within the six months tacit acceptance period);<br />
* when an exclusion is filed, the PAG is formed, notifications sent, and the document header updated (and removed when the PAG is completed);<br />
* when a Formal Objection is filed, notifications sent, and the document header updated (and removed when the Formal Objection is resolved).<br />
<br />
= Comparison of the Continuous and Traditional Recommendation Tracks =<br />
<br />
{| class="wikitable"<br />
|-<br />
! Concept !! Continuous !! Traditional<br />
|-<br />
| wide review || Incremental, by automatic notification and lack of objection || On Transitions<br />
|-<br />
| horizontal review (i18n, a11y, security, privacy, perf, device independence, TAG, etc.) || Incremental, by automatic notification and lack of objection || On Transitions<br />
|-<br />
| Advisory Committee review || Incremental, by automatic notification and lack of objection || On Transitions<br />
|-<br />
| tests || Defined in charter, verified by WG and reviewers incrementally || Defined in charter, verified by WG and reviewers on transitions<br />
|-<br />
| issues addressed || Verified incrementally || Verified on transitions<br />
|-<br />
| IP || Whole spec from all WG members given exclusion opportunity at a snapshot || Whole spec from all WG members at Rec<br />
|-<br />
| consensus || verified continuously || verified at transitions etc.<br />
|-<br />
| errata || In issues and possibly inline || Not well handled; in issues or possible erratum document<br />
|-<br />
| maintenance || Ongoing || Episodic<br />
|-<br />
| use cases || In charter or requirements document (which may also be Continuous) || In charter or Wiki or somewhere<br />
|-<br />
| requirements || In charter or requirements document (which may also be Continuous) || In charter or Wiki or somewhere<br />
|-<br />
| implementation commitments || Requirements defined by charter || Requirements defined by charter<br />
|-<br />
| implementation experience || Requirements defined by charter || Requirements defined by charter<br />
|-<br />
| Director's approval || Incremental, tacit unless objections raised || On transitions<br />
|-<br />
| Appeal process || After Formal Objection || After Formal Objection<br />
|-<br />
| stable reference || By using specific revision references or periodic Rec snapshots || Normal<br />
|-<br />
| adoption || Requirements defined by charter || Requirements defined by charter<br />
|-<br />
| status duration || Indefinite || Indefinite<br />
|}</div>Plehegarhttps://www.w3.org/wiki/index.php?title=Evergreen_Standards&diff=108650Evergreen Standards2018-12-17T20:50:38Z<p>Plehegar: Added title back</p>
<hr />
<div>= Introduction =<br />
<br />
== Overview ==<br />
<br />
We are looking at the [https://www.w3.org/2001/tag/doc/evergreen-web/ Evergreen Standards] (also known as living standards) model as a possible alternative way to develop and publish W3C Recommendations. Many Working Groups already publish frequent iterative working drafts, and continuously resolve issues, test, review, and maintain specs at the "top of tree," so we ask what it would take to make those living documents into formal publications of the W3C. In the analysis, we consider various aspects and values embodied in the current W3C Process and Patent Policy to assess how those can be met in an iterative mode. <br />
<br />
This proposed mode is designed for continuous development of specifications. We propose to call this "Continuous Publication" process Evergreen Standards. The suggested name for the product here is Evergreen Recommendation. There are two types of Evergreen Recommendations (ERs). The vanilla form is called an ER. Additionally, snapshots might be taken for IPR purposes and those are called ER Snapshots.<br />
<br />
In particular, this program aims to manage specifications on a continuous basis, with a minimum of manual process steps needed, so that in the specifications<br />
* all material that has been in the specification for six months or more has been '''available''' for review:<br />
** by the community â but particularly the working group, the Advisory Committee, and the Team â that the specification meets the charter requirements (for testing, implementation, and interoperability, for example);<br />
** by the cross-functional groups for acceptability;<br />
** by the liaison groups and the wider public for acceptability.<br />
* all material that has passed a snapshot exclusion opportunity carries a license to the unexcluded essential IPR from those who had the opportunity<br />
<br />
We say that the material has been "available" for review because we envisage "incremental" review by the entire community including cross-functional, horizontal, and liaison groups. We generally believe that a duration of 180 days should be sufficient to catch almost any cross-functional issues. But we also recognize that not all cross-functional review can take place at that time frame. So we provide a level of status to Evergreen Recommendations, and a higher level of status when taken to the Recommendations track for a full review.<br />
<br />
Under the current [https://www.w3.org/2018/Process-20180201/ Process] and [https://www.w3.org/Consortium/Patent-Policy-20170801/ Patent Policy], royalty-free patent commitments attach when a document is published as a Recommendation, after exclusion periods at FPWD (first public working draft) and CR (Candidate Recommendation). We propose that for continuous publication, there be periodic snapshots, after which patents not excluded would be licensed royalty-free.<br />
<br />
This is a close companion to the separately discussed [[Repositories]] question.<br />
<br />
We expect this model to apply in two general cases, but see more about [https://www.w3.org/wiki/Evergreen_Standards#Use_Cases use cases] below.<br />
* Specifications which are, in a sense, built of small independent pieces, where those pieces are added incrementally, for example a document that has a set of independent APIs that map to other features<br />
* Maintenance of Recommendations, where bug fixes and minor missing features can be added with less pain than the 'revised recommendation'.<br />
<br />
== Transitions between the Evergreen and Recommendation Tracks ==<br />
<br />
The following initiations or transitions are envisaged:<br />
* A document may be initiated on either track ("this document will be developed as a Recommendation | Evergreen Standard")<br />
* A document previously on the Recommendation track may switch to the Evergreen track; typically this happens after Recommendation status, for maintenance, but may happen on any re-chartering;<br />
* A document on the Evergreen track may enter the Recommendation track by satisfying the requirements for a WG Working Draft or Candidate Recommendation, and entering as such. This would typically be an ER Snapshot.<br />
** Transition to the REC track does not necessarily mean that specification development as an ES stops because the work is entirely completed. For key parts of the web architecture, the spec is in constant evolution. However moving a snapshot to the REC level provides certain checking and validation for the work (e.g. complete cross-functional and AC review) which adds value in the technology development. There could still be an ES version that is further developed and developers wanting the most up to date version of the specification should use that.<br />
* Although a specification might remain as an ER for many years, there is an expectation that ultimately every spec transitions to the REC track, because it is only at the REC track where full horizontal review and AC review is provide. The Charter for an ES spec must specify the expected point in time for transition to W3C Recommendation, even if that time is beyond the time horizon of a particular charter.<br />
<br />
= Use Cases =<br />
<br />
There is debate in the community whether to apply the Evergreen Standards approach for all standards or only for limited use cases. We don't take a position on this question at the moment in the document, but we list here some of the proposed use cases that have been mentioned:<br />
<br />
* Accessibility API Mappings (see https://github.com/w3c/w3process/issues/79)<br />
* Vocabularies. This is because most vocabulary defintions have little IPR contention, and grow in a natural incremental fashion.<br />
* Registries. Similar reasons to vocabularies<br />
* Profiles of the Web Platform (e.g Web Media). Profiles of the Web Platform involve little spec development, but indicate which portions of the standards are most appropriate for industry segments.<br />
* Maintenance. Maintenance of specification by nature is intended to track evergreen incremental enhancements rather than bold new features; plus have less IPR contention.<br />
* Core infrastructure. Some specs provide core infrastructure for other specs; but may not need to reach a level of Recommendation per se. Web IDL might be an example.<br />
* Incremental guidance. Specification such as WebAppSec seem well suited for an incremental or evergreen approach.<br />
* All specifications. There are those that feel that an Evergreen approach is a best fit for all specs.<br />
<br />
= Roles and Responsibilities in the Evergreen Model =<br />
<br />
As with any W3C Working Group, there are Chairs for the group, Editors for the documents of the group, and participants in the group. However the roles and responsibilities are somewhat different in these groups.<br />
<br />
For an Evergreen Standard, the Editors of the specification have the primary role to ensure that the specification represents the current consensus of the Working Group. This is done by informal means: regular conversations between the editor and participants; participants raising issues about the spec in github; editors addressing issues and pull requests; and editors tracking implementations to ensure that the ER is both reflective of implementation as well as sensitive to the issues raised by the community. The Editor achieves this consensus without issuing formal calls for consensus; instead the Editor is continually in contact with the group to ensure that the ER document represents a consensus.<br />
<br />
As opposed to the REC track, the Chair does not have the responsibility to call for consensus or assess consensus as a result of a poll of participants. But the Chair has an important oversight role to ensure that the group's discussions proceed professionally and in accordance to CEPC, and to be a resource for participants who disagree with the way that the editors are documenting the evolving consensus of the group. If a participant believes that the editor is not behaving fairly, the chair is a resource to facilitate discussion between the chair and editor. If that does not solve the issue, the chair may also issue informative calls for consensus, or engage in other discussions to see whether consensus can be reached or whether the editor can adjust their position. <br />
<br />
Despite this important facilitation role of the chair, they generally do not have the authority to overrule the sense of the editor of where consensus lies during the ER phase of a specification development. However, in an extreme case, the chair can request that the Director look into the situation and possibly remove the chair.<br />
<br />
We discussed in the [https://www.w3.org/wiki/Evergreen_Standards#Overview Overview] that we expect incremental community review of an ER. It is the responsibility of the chair to ensure that there is appropriate notification to review groups about the progress of the ER.<br />
<br />
However, when the ER is ready to make the transition to the REC track, the chairs will have a more significant role assessing consensus in the usual way.<br />
<br />
= Documents and their status =<br />
<br />
We have described the mechanics of how a WG group develops an ER, with the editor assessing consensus and seeking incremental wide review. The next question is, if this is done successfully, then what is W3C recommending in terms of the spec? What should developers do with it? What can developers depend on, and what risks are there? <br />
<br />
We address that in this section, but first we take a broader view of different W3C documents and what W3C is saying about them. After all, W3C provides many types of documents. For each type of document, W3C conveys "status" to the document based on the process used to generate the document.<br />
<br />
* Community Group Specifications. These documents have no particular W3C status, although the individual contributions come with a level of patent protection through the W3C CLA.<br />
<br />
* Community Group Final Specifications. These documents have no particular W3C Status, although the entire specification comes with enhanced patent protection through the FSA agreement that may be signed by participating organizations.<br />
<br />
* Working Group Working Draft. These documents have no particular W3C status, but they are guaranteed to be within the scope of a WG approved by the Director after review by the AC.<br />
<br />
* Working Group Candidate Recommendation. These documents, like Working Drafts are within an approved scope. Additionally, they:<br />
** Have met the requirements of the WG, or explained why the requirements have changed.<br />
** Have addressed issues raised<br />
** Represent the consensus of the WG<br />
** Have a plan to demonstrate implementation experience<br />
** Have received wide review (including horizontal review)<br />
** Have received Director's approval for this status<br />
<br />
* Working Group Recommendation. These documents have all of the "status" as CR documents. They have the additional status of:<br />
** Have demonstrated implementation experience<br />
** Have W3C Royalty Free licensing commitments associated with the specification.<br />
** Have received AC review of the spec<br />
** Have ensured that all Formal Objections are resolved through Director review<br />
** Have an Appeals process if the AC disagrees with the Director<br />
** Represents a stable reference.<br />
** Has been adopted<br />
<br />
That brings us to Evergreen Standards. One the one hand, W3C needs a track for them because W3C's TAG has determined that there is an Evergreen Web [1]. But that puts pressure on the Standards Development Process. Standards must constantly be updated to ensure the Web's usefulness. But it is not possible to achieve all of the "status" features of a W3C Recommendation and be responsive to that time frame.<br />
<br />
That is why W3C is introducing an experimental path called Evergreen Standards to address that. In ES, there is a continuous evolution of the standard and a patent policy which provides continually improving patent commitments. Key features of the W3C process such as document review are done incrementally. This results in a document, the Evergreen Recommendation, that has sufficient review that W3C can provide a ''tentative recommendation'' to implementors that the spec may be implemented - while acknowledging that it does not have the full "status" of a W3C Recommendation. <br />
<br />
So, ''incremental review'' means that the WG operates in a fashion that:<br />
* The regularly announce that their documents should get wide review<br />
* They specifically maintain a relationship with horizontal reviewers to get their review<br />
* But, they may be operating too quickly for a full wide review.<br />
<br />
For that reason, in a charter which specifies that a spec will be developed as an ES, the charter will indicate a time frame for the ES spec to be taken to a Recommendation. There might be several years of development on the ES path, yet there is an expectation that at some point a REC will be achieved as well. There may be circumstances where the Director and AC conclude that the REC path is not necessary.<br />
<br />
* Accordingly, an Evergreen Recommendation has the following "status" associated with it:<br />
** Are within the approved scope of a WG<br />
** Represent the consensus of a WG (driven by the editor with oversight from the WG chair)<br />
** Have demonstrated implementation experience<br />
** Have received incremental wide review (including incremental horizontal review)<br />
** All key horizontal issues have been resolved<br />
** Have ES contribution Patent Commitments associated with the spec<br />
<br />
Thus the ES has achieved much of what the community is looking for and hence W3C confers it with the status of ES which both informs the community of what they can rely on, and also establishes where there is incompleteness.<br />
<br />
The most serious incompleteness is the incompleteness of patent commitments. Accordingly, it is expected that the WG will on a regular basis (e.g. every 12 months) create an ER Snapshot which gets the benefit of full patent commitments for the ER spec.<br />
<br />
That still does not provide all of the value of a complete consensus process with the widest possible review. Accordingly, at an even less frequent review cycle, snapshots are taken through the full REC process.<br />
<br />
* Accordingly, the benefit of ultimately taking an ER spec to a REC as well is to ensure that the spec ultimately has:<br />
** Full wide review (including horizontal review)<br />
** Director approval<br />
** Received an AC review of the spec<br />
** Ensured that all Formal Objections are resolved through Director review<br />
** The benefit of an Appeals process if the AC disagrees with the Director<br />
** A stable reference.<br />
<br />
[1] https://www.w3.org/2001/tag/doc/evergreen-web/<br />
<br />
= Different Evergreen Models =<br />
<br />
There is a choice between a âsnapshot' and sliding-window model, for both IPR review and functional review. What we have here is hybrid -- sliding-window for the technical reviewers, snapshot for the IPR.<br />
<br />
This is like the WHATWG [https://whatwg.org/workstream-policy process] which requires a periodic manual "review draft" ('snapshot') approximately every 6 months, and at that time all the legal reviewers have 45 days to respond. WhatWG doesnât have liaisons, cross-functional groups, an Advisory Committee, or Director/team.<br />
<br />
In the sliding-window model, we deem all the technical groups (external, cross-functional, Advisory Committee, and Director/team) to have tacitly accepted features 180 days after they first appear, unless they file an issue. This incremental tacit acceptance is sufficient for W3C to confer status on an ER that there is sufficient review to be reasonably confident that a feature is stable and can be implemented. But it is less than the status associated with a full W3C Recommendation which has had wider and more complete review.<br />
<br />
If an issue has been raised, the editor has the lead role to address the issue and re-establish consensus. This is discussed in: [https://www.w3.org/wiki/Evergreen_Standards#Roles_and_Responsibilities_in_the_Evergreen_Model Roles and Responsibilities]<br />
<br />
There is little '''functional''' difference between âWeâll keep you informed of the grocery list as it builds, and you must do your grocery shopping at least once a weekâ and âYou must do your grocery shopping immediately when the editor issues the weekly shopping listâ â it is the same amount of work, at the same frequency; but the former allows you to choose when, and indeed spread it out if you want to, while the latter says âjump nowâ. But there is a difference of work-mode.<br />
<br />
= Licensing =<br />
<br />
We require the PSIG to look at spec development in the Evergreen model, the RF licensing requirements of W3C, and the spec review process within a member organization. But the general philosophy around licensing should be:<br />
<br />
Based on the WHATWG [https://whatwg.org/workstream-policy process], perhaps with <br />
* an adjustment of intervals (we probably prefer a longer filing period, say 60 days).<br />
* a provision that WHATWG lacks, for an exclusion opportunity on the current Working Draft, on leaving the WG (to match the Patent Policy, and close a significant gap).<br />
<br />
An exclusion filing must result in:<br />
# A notification to at least the WG general mailing list, the advisory committee, and PSIG, so that the community is immediately aware and can take appropriate steps.<br />
# The formation of a [https://www.w3.org/Consortium/Patent-Policy-20170801/#sec-Exception Patent Advisory Group] (PAG).<br />
# The documentation, in the header of the specification, of the exclusion and the PAG, until the PAG completes its operation and its recommendations implemented.<br />
<br />
<br />
<br />
= Advisory Committee (AC), Director, Cross-functional, and Wide Review =<br />
<br />
The W3C has a value that all substantive changes are subject to these four kinds of review: "horizontal review," "wide review,", Director, and Advisory Committee review. For Continuous Publication, we mandate automated reports to the AC and cross-functional groups on a regular basis, reporting on substantive changes. This is what provides the signal to cross functional groups that they may perform their reviews, but does not guarantee that the reviews will take place. If the WG is rapidly making additions to the spec, it is possible that cross function groups will not have the ability for a full review. But the notification ensures that there will at least be an incremental review.<br />
<br />
In the past, cross-functional groups have been at "arms length", and doing reviews only at major transitions. Now we're asking for more incubation, experimental implementation, and so on, waiting for a transition in the REC process may be too late; there may be implementations, test suites, and designs that follow on from a feature, already in place. For both continuous publications and the traditional rec-track process, cross-functional groups need to be noticing issues and changes as they arise, and reacting as soon as possible when they see problems, ideally by having people 'embedded' in those other working groups, but minimally by watching specification progress.<br />
<br />
External groups should be notified by liaison of the existence of the Continuous Publication, as early as is practical and useful, and agreement reached with them how they will review substantive changes. They may request to be added to the automated report, for example; they may elect to watch the repository manually; or ask to be notified manually by the WG e.g. in liaison or email. Such manual notification should be both archived and also occur no less frequently than every 180 days.<br />
<br />
There is a 180-day period before changes are considered reviewed and accepted. This period starts on the first report that details the change (even if it was later reverted and re-inserted). Note that anyone, including AC, cross-functional groups, public, and members of the WG, are free to comment on anything at any time, of course; the 180-day deadline merely sets a date before which changes ought to be considered by the working group, and after which they might apply more back-pressure.<br />
<br />
This implies a tooling requirement. There must be simple to use automated tools which inform the community when a change has been made so that way they know which changes are about to become accepted. Further, a reviewer who has reviewed the document in the past will want to know the changes since their last review.<br />
<br />
To enable the automated reports, all changes must be made through Pull Requests (no direct commits). Pull Requests are considered '''substantive''' unless tagged as "Editorial" or "Minor technical". Issues are assumed non-substantive '''unless''' tagged explicitly as substantive (to avoid flooding the reports with issues that have not yet been categorized).<br />
<br />
(Note that the tagging for issues is necessarily the opposite to Pull Requests, as we don't want to report untagged, newly filed, issues, that the WG has not yet considered, as automatically substantive.)<br />
<br />
The automated report must detail:<br />
* new substantive changes since the prior report<br />
* substantive changes that will be declared past their 180 day review period in the next automated report (i.e. a kind of 'last call' for comments)<br />
* substantive changes that have just passed their 180 review period<br />
* all other changes (minor, editorial, etc.) performed via Pull Requests<br />
* suitable reporting on issues, noting particularly any tagged "substantive" or "cross-functional" (recently opened, recently closed, tagged substantive but still open, etc.)<br />
<br />
(Note the the WG, cross-functional groups, external bodies, and AC are at liberty to request other tags, e.g. identifying issues or pull requests of particular concern to those communities; we already have a substantial set of [https://w3c.github.io/issue-metadata.html tags].)<br />
<br />
For any issue filed against the document, the WG should consider whether an inline "issue" or âerratumâ notice should be placed in the document.<br />
<br />
For âreviewâ issues filed by the AC, a cross-functional W3C group, or by an external âliaisonâ body, the filing group can request, at any time after filing the issue and until the issue is resolved, any or all of:<br />
# that there be an inline issue/erratum notice, and/or <br />
# that the feature be marked as âprovisionalâ<br />
#that the feature be removed until consensus is reached.<br />
The WG is not automatically obliged to grant any request, but note that such denial may escalate the disagreement.<br />
<br />
If the WG and filer are unable to reach consensus, then the usual recourse to Formal Objections, Appeals, and Director rulings can be followed. As the continuous publication process does not entail formal Transitions, Director review can be triggered by the filer and WG deciding that they are at an impasse and one of them filing a Formal Objection. Formal Objections must be documented in the header of the document until the resolution is implemented. <br />
<br />
Since features that are stable in the specification for 180 days are considered final (there is an implied "acceptance" decision), disagreements should be raised to the editor, and then to the chairs before that 180-day period expires. If an issue is raised to the editor and the chair does not feel that the editor has sufficiently addressed the issue, the chair may appeal to the Director; possibly removing the editor.<br />
<br />
Similarly, if a participant has raised an issue and believes that neither is appropriately addressing their issue, they should Formally Object to the Director prior to a feature being around for 180 days. But they may only do that if they have first raised the issue with the editor and the chair and they have not gotten satisfaction.<br />
<br />
= Charter, Repository, Document, Testing, and Implementation Requirements =<br />
<br />
WG Charters may declare that a document is developed on the Recommendation Track, or on the Continuous Publication track. Changes between tracks, for any document, require a new approved charter. <br />
<br />
In order to enable 'harvesting' of the Github repository URLs of Continuous Publications, by both lawyers and the tools that inform reviewers, the Github repositories must be created before the charter is sent to formal AC review, and the URLs to those repositories must be in the charter, in a section clearly listing those documents on the Continuous Publication track.<br />
<br />
Those Github repositories must be in the W3C space and also must document the publication URL (usually Github.io) of the readable document.<br />
<br />
The readable document must list, in its header, the URL that refers to the latest viewable version, and also a permanent URL to the specific revision being viewed. It should also identify the Github repository where issues are filed and revisions made. As noted above, both unresolved (a) Patent Exclusions and (b) Formal Objections must be documented in the header of the specification.<br />
<br />
The charter must identify the implementability, implementation, test suite, and test pass coverage requirements for a feature to be considered not provisional but final. Features that do not meet these requirements should be integrated first as provisional, and a second Pull Request made to change them to non-provisional, when the requirements are met.<br />
<br />
= Implementation expectations =<br />
<br />
Typically speaking an ES specification will consist of different features at different levels of implementation maturity due to the requirement to be "Evergreen", that is, very reflective of current implementation and thinking among implementors. Included in that are features:<br />
<br />
* For which there is sufficient implementation experience and testing that the Director would ordinarily feel that those features could be approved in a W3C Recommendation.<br />
* For which interoperability has not yet been demonstrated, but there are at least commitments from sufficient implementors that there is a strong likelihood that the features will ultimately be accepted as Recommendations.<br />
* (In rare cases) Draft features that the WG is working on that are significant chartered deliverables being developed in the WG which are expected to be implemented but which lack firm implementation commitments at this time.<br />
<br />
While there could be good reasons to have features of various levels of maturity in a specification, it is important to clarify what part of the specification is actually being given support by W3C for developers to implement.<br />
<br />
For all specifications for which W3C is conferring status, the rule is that the status is only being conferred on those features where there has been sufficient implementation experience and testing to demonstrate interoperability. This is true whether the features are in an ES, an ES snapshot, or a W3C Recommendation.<br />
<br />
That does not mean that the other features need to be stripped from the document. They remain in the document but are considered as informative material for the spec, not normative, endorsed features for implementors.<br />
<br />
This characterization of what parts of the spec are considered normative must appear in the status of the document.<br />
<br />
= Tooling Requirements =<br />
<br />
There are various forms of tooling requirements. Some of them are tooling for the specs, to identify metadata about feature status. Other tooling relates to tagging issues in the Github repository for the spec.<br />
<br />
We have indicated above some of the required tooling for features. Since features achieve greater status by aging (in particular, we assume after 180 days there has been sufficient time for incremental horizontal review), there needs to be tooling so it is easy to determine when a feature was introduced and/or last changed.<br />
<br />
Since features achieve greater status by acquiring implementation experience, testing, and demonstrating interoperability, there needs to be tooling so it is easy to determine that a feature has all of this experience.<br />
<br />
Since a feature is more meaningful to implementors when there are implementation commitments, there must be tooling for that.<br />
<br />
Since a feature is considered normative in an ES when it has 180 days of aging and implementation experience, tooling must make it easy to identify that status as well.<br />
<br />
Tooling related to tagging issues in GH is as follows:<br />
<br />
We need <br />
* to define the standard tags that the report tool will use to work on, for Issues and Pull Requests.<br />
* the report tool to distil Pull Requests by tag (editorial, minor technical, or assumed substantive) and date (first appearance, will hit 180 days in the next 30 days, has passed 180 days, all since merging)<br />
* the report tool to distill Issues by tag also<br />
<br />
Ideally there is a commit hook that generates a "permanent link to this version" header.<br />
<br />
Note that all documents in a Github pages repo can have a unique URL, and are immutable; these come free. Those wanting to reference a specific unchanging version can do that. You can refer to a specific revision in GitHub using htmlpreview or rawgit.com; for example the August 17th version of WebVTT is<br />
<br />
<http://htmlpreview.github.io/?https://github.com/w3c/webvtt/blob/2b24ae60e84e8cbac033c148db2715104e0b9368/index.html><br />
<br />
or rawgit.com<br />
<br />
<https://rawgit.com/w3c/webvtt/2b24ae60e84e8cbac033c148db2715104e0b9368/index.html><br />
<br />
It should be easy to mark a document as under PAG review or under a Formal Objection, while exclusion or FO processing is in progress.<br />
<br />
We might like better support for in-line errata, and provisional material, and the ability to see a document without those (and thus make a snapshot), but this is optional.<br />
<br />
= Tooling Design =<br />
<br />
For a given section, sub-section, paragraph, or API of a specification, we may identify the following:<br />
<br />
# tests in WPT<br />
# test results from WPT<br />
# feature implementation information from caniuse.com<br />
# 180 days information<br />
# articles in MDN<br />
<br />
For snapshots, the annotations will be providing as JSON objects, contained in one file per specification generated on the day of the snapshot, then loaded and render using a JS script. The annotations within a given snapshot are NOT expected to change/involve overtime. In order of preference, each annotation object will be identifiable with:<br />
<br />
* API information (eg AuthenticationExtensionsClientOutputs, AuthenticationExtensionsClientOutputs.rawId)<br />
* CSS property name (eg "background-size")<br />
* Markup elements and attributes (eg "use", "use@width")<br />
* section title (eg "Android Key Attestation Statement Format")<br />
* CSS Selector (eg "pre.idl")<br />
* fragment identifiers (eg #preventSilentAccessCredential)<br />
* section numbering<br />
<br />
The same identifier may apply to more than on annotation object.<br />
<br />
Bikeshed and ReSpec, the most currently used spec editing framework, will need proper support to identify annotation object identifiers as well as WPT, caniuse.com, and MDN identifiers. Test files can be identified by providing a list of files in WPT. Test results can be deduced from that list. A test file may contain more than one test and we will need to work with WPT folks to get a method to identify specific tests within a test file. caniuse.com already provide annotations to integrate a feature implementation information.<br />
<br />
A tool will generate the annotation file using information embedded within the specification. The specification may contain additional annotation objects to be merged as well. A tool should check the resulting annotations to determine if all annotation objects are still relevant.<br />
<br />
Last update information will be generated based on running diffs with the 180 days-ago version and generating resulting JSON annotation objects. We'll need to explore if the result can be refined using commit history information (see [https://github.com/w3c/payment-request/commits/gh-pages payment-request commits]).<br />
<br />
= Referenceability =<br />
<br />
For all W3C specifications, it is important to know how they are normatively referenced by other specifications - both on the ES track as well as the REC track.<br />
<br />
It is possible to normatively reference a W3C specification, evergreen or working draft, from a W3C Recommendation as long as the [[https://www.w3.org/2013/09/normative-references|Director's consideration]] are applied, in particular:<br />
<br />
* Stability of the referenced part(s)<br />
* Nature of the dependency<br />
* Status of implementations<br />
<br />
= Sample Charter Language =<br />
<br />
The Fruit Action Working Group (FAWG) will develop the following on the Recommendation Track:<br />
* Pineapple picking and handling, <br />
and the following on the Continuous Publication Track,<br />
* Olive picking, pitting, curing and bottling; in the Github Repo (URL goes here)<br />
** The ES spec for Olive picking will have an IPR snapshot every 12 months.<br />
** While the Olive picking spec is on the Continuous Publication Track, it is intended that after 4.7 years, a snapshot will be taken to Recommendation.<br />
<br />
For a feature to be considered final by the working group (on either track):<br />
* it must be testable by a test in the Agricultural Products Test (APT) suite at (URL goes here)<br />
* there must be at least 3 complete implementations<br />
* at least 2 of those implementations must pass the applicable APT tests<br />
* at least 1 of those implementations generates packed olives, and at least one uses packed olives, and they interoperate<br />
<br />
Features that do not meet these requirements will be integrated first as provisional, and a second Pull Request made to change them to non-provisional, when the requirements are met.<br />
<br />
= Sample Document Header =<br />
<br />
Olive picking, pitting, curing and bottling.<br />
<br />
W3C Evergreen Standard 15 March 55BCE<br />
<br />
'''Latest version''': (URL to the evergreen standard goes here)<br />
<br />
'''Permanent link to this version''': (URL for this exact version goes here)<br />
<br />
'''Repository''': (URL to the Github repository for issues etc.)<br />
<br />
'''Editors''': (Editors listed by name)<br />
<br />
'''Current unresolved Patent Licensing Exclusions''': none, or a URL to the exclusion plus a URL to the PAG information<br />
<br />
'''Current unresolved Formal Objections''': none, or a URL to the Formal Objection filing<br />
<br />
'''Abstract''': (as usual)<br />
<br />
'''Status of this document''': <br />
<br />
This document is developed by the (link to Working Group). Comments and issues are welcomed and should be filed at the (URL to the issues page of the Github repository). <br />
<br />
This document was produced by a group operating under the W3C [https://www.w3.org/wiki/Living_Standards Continuous Publication] process and policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with [https://www.w3.org/Consortium/Patent-Policy-20170801/#sec-Disclosure section 6 of the W3C Patent Policy].<br />
<br />
The disclosure obligations of the Participants of this group are described in the Working Group charter.<br />
<br />
= Detailed explanation of the Continuous Track Patent policy =<br />
<br />
Looking for input from PSIG.<br />
<br />
= Summaries for various constituencies =<br />
<br />
== Lawyers ==<br />
<br />
(needs editing to match the snapshot model)<br />
<br />
Lawyers will need to take roughly the following steps:<br />
* Review the charters of the working groups that your organization intends to participate in. <br />
* Collect, from the charters, the URLs of the Continuous Publication repositories and add them to your 'watch list'.<br />
* When you join a working group, review the most recent snapshot and file any applicable exclusions, within the deadline.<br />
* When snapshots are made, review it and file any applicable exclusions, within the deadline.<br />
* Watch other exclusion filings, of course; take any steps you think indicated, and consider joining the PAG.<br />
* Optionally, if you want early notification of changes, watch the monthly automated reports of Pull Requests, or get automated immediate notification by GitHub of Pull Requests, for repositories in your watch list.<br />
* When you leave a working group, do a final exclusion check on the working draft that was current as of the time you left the group.<br />
<br />
== Working Groups ==<br />
<br />
Working groups need to do the following:<br />
* Create Github repositories for your documents on the Continuous Publication track before writing your charter.<br />
* Define clearly in your charter the documents on the Continuous Publication track; list the URIs of their repositories.<br />
* Define clearly in your charter what requirements a feature must meet to be considered acceptable (testing, implementation, interop, etc.).<br />
* Watch Pull Requests and make sure:<br />
** that Pull Requests are correctly tagged (editorial, minor, or, by default, substantive);<br />
** that if Pull Requests add to 'core draft' (ie. material that is not an erratum report, provisional, or editor's note) that the addition meets the WG requirements (testing, implementation, interop, etc.).<br />
* Watch issue filings and tag those also.<br />
<br />
== Editors == <br />
<br />
Editors need to make sure that material that is provisional, an erratum report, or an editor's note, is correctly tagged, and that tags are removed when the material becomes final. If a new feature is too complex to be inserted inline as provisional, manage separate "editor's drafts" that the WG can review until such time as they agree to merging. Check that the 'core draft' reads correctly as well as checking the entire document.<br />
<br />
If there have been any technical changes since the last snapshot, make a new snapshot no later than 180 days after the last one.<br />
<br />
== Other Groups ==<br />
<br />
Read the automated reports and review the changes as they happen. File an issue with at most 180 days if there is a problem. Raise a Formal Objection, ideally within 180 days, if impasse is reached so that Chairs can facilitate a discussion and (if necessary) the Director can get involved if needed to resolve disagreement.<br />
<br />
== Team == <br />
<br />
The team:<br />
* makes sure the process is followed, Charters are correctly drafted, etc.<br />
* makes sure that the Pull Requests (and issues) are tagged correctly, and that technical changes meet the charter requirements;<br />
* makes sure that snapshots are made if technical changes have occurred since the last snapshot, and 180 days are about to elapse;<br />
* ensures that the comments from outside the WG are given due and timely consideration by the WG (notably, within the six months tacit acceptance period);<br />
* when an exclusion is filed, the PAG is formed, notifications sent, and the document header updated (and removed when the PAG is completed);<br />
* when a Formal Objection is filed, notifications sent, and the document header updated (and removed when the Formal Objection is resolved).<br />
<br />
= Comparison of the Continuous and Traditional Recommendation Tracks =<br />
<br />
{| class="wikitable"<br />
|-<br />
! Concept !! Continuous !! Traditional<br />
|-<br />
| wide review || Incremental, by automatic notification and lack of objection || On Transitions<br />
|-<br />
| horizontal review (i18n, a11y, security, privacy, perf, device independence, TAG, etc.) || Incremental, by automatic notification and lack of objection || On Transitions<br />
|-<br />
| Advisory Committee review || Incremental, by automatic notification and lack of objection || On Transitions<br />
|-<br />
| tests || Defined in charter, verified by WG and reviewers incrementally || Defined in charter, verified by WG and reviewers on transitions<br />
|-<br />
| issues addressed || Verified incrementally || Verified on transitions<br />
|-<br />
| IP || Whole spec from all WG members given exclusion opportunity at a snapshot || Whole spec from all WG members at Rec<br />
|-<br />
| consensus || verified continuously || verified at transitions etc.<br />
|-<br />
| errata || In issues and possibly inline || Not well handled; in issues or possible erratum document<br />
|-<br />
| maintenance || Ongoing || Episodic<br />
|-<br />
| use cases || In charter or requirements document (which may also be Continuous) || In charter or Wiki or somewhere<br />
|-<br />
| requirements || In charter or requirements document (which may also be Continuous) || In charter or Wiki or somewhere<br />
|-<br />
| implementation commitments || Requirements defined by charter || Requirements defined by charter<br />
|-<br />
| implementation experience || Requirements defined by charter || Requirements defined by charter<br />
|-<br />
| Director's approval || Incremental, tacit unless objections raised || On transitions<br />
|-<br />
| Appeal process || After Formal Objection || After Formal Objection<br />
|-<br />
| stable reference || By using specific revision references or periodic Rec snapshots || Normal<br />
|-<br />
| adoption || Requirements defined by charter || Requirements defined by charter<br />
|-<br />
| status duration || Indefinite || Indefinite<br />
|}</div>Plehegarhttps://www.w3.org/wiki/index.php?title=Evergreen_Standards&diff=108649Evergreen Standards2018-12-17T20:48:36Z<p>Plehegar: /* Referenceability */</p>
<hr />
<div>= Introduction =<br />
<br />
== Overview ==<br />
<br />
We are looking at the [https://www.w3.org/2001/tag/doc/evergreen-web/ Evergreen Standards] (also known as living standards) model as a possible alternative way to develop and publish W3C Recommendations. Many Working Groups already publish frequent iterative working drafts, and continuously resolve issues, test, review, and maintain specs at the "top of tree," so we ask what it would take to make those living documents into formal publications of the W3C. In the analysis, we consider various aspects and values embodied in the current W3C Process and Patent Policy to assess how those can be met in an iterative mode. <br />
<br />
This proposed mode is designed for continuous development of specifications. We propose to call this "Continuous Publication" process Evergreen Standards. The suggested name for the product here is Evergreen Recommendation. There are two types of Evergreen Recommendations (ERs). The vanilla form is called an ER. Additionally, snapshots might be taken for IPR purposes and those are called ER Snapshots.<br />
<br />
In particular, this program aims to manage specifications on a continuous basis, with a minimum of manual process steps needed, so that in the specifications<br />
* all material that has been in the specification for six months or more has been '''available''' for review:<br />
** by the community â but particularly the working group, the Advisory Committee, and the Team â that the specification meets the charter requirements (for testing, implementation, and interoperability, for example);<br />
** by the cross-functional groups for acceptability;<br />
** by the liaison groups and the wider public for acceptability.<br />
* all material that has passed a snapshot exclusion opportunity carries a license to the unexcluded essential IPR from those who had the opportunity<br />
<br />
We say that the material has been "available" for review because we envisage "incremental" review by the entire community including cross-functional, horizontal, and liaison groups. We generally believe that a duration of 180 days should be sufficient to catch almost any cross-functional issues. But we also recognize that not all cross-functional review can take place at that time frame. So we provide a level of status to Evergreen Recommendations, and a higher level of status when taken to the Recommendations track for a full review.<br />
<br />
Under the current [https://www.w3.org/2018/Process-20180201/ Process] and [https://www.w3.org/Consortium/Patent-Policy-20170801/ Patent Policy], royalty-free patent commitments attach when a document is published as a Recommendation, after exclusion periods at FPWD (first public working draft) and CR (Candidate Recommendation). We propose that for continuous publication, there be periodic snapshots, after which patents not excluded would be licensed royalty-free.<br />
<br />
This is a close companion to the separately discussed [[Repositories]] question.<br />
<br />
We expect this model to apply in two general cases, but see more about [https://www.w3.org/wiki/Evergreen_Standards#Use_Cases use cases] below.<br />
* Specifications which are, in a sense, built of small independent pieces, where those pieces are added incrementally, for example a document that has a set of independent APIs that map to other features<br />
* Maintenance of Recommendations, where bug fixes and minor missing features can be added with less pain than the 'revised recommendation'.<br />
<br />
== Transitions between the Evergreen and Recommendation Tracks ==<br />
<br />
The following initiations or transitions are envisaged:<br />
* A document may be initiated on either track ("this document will be developed as a Recommendation | Evergreen Standard")<br />
* A document previously on the Recommendation track may switch to the Evergreen track; typically this happens after Recommendation status, for maintenance, but may happen on any re-chartering;<br />
* A document on the Evergreen track may enter the Recommendation track by satisfying the requirements for a WG Working Draft or Candidate Recommendation, and entering as such. This would typically be an ER Snapshot.<br />
** Transition to the REC track does not necessarily mean that specification development as an ES stops because the work is entirely completed. For key parts of the web architecture, the spec is in constant evolution. However moving a snapshot to the REC level provides certain checking and validation for the work (e.g. complete cross-functional and AC review) which adds value in the technology development. There could still be an ES version that is further developed and developers wanting the most up to date version of the specification should use that.<br />
* Although a specification might remain as an ER for many years, there is an expectation that ultimately every spec transitions to the REC track, because it is only at the REC track where full horizontal review and AC review is provide. The Charter for an ES spec must specify the expected point in time for transition to W3C Recommendation, even if that time is beyond the time horizon of a particular charter.<br />
<br />
= Use Cases =<br />
<br />
There is debate in the community whether to apply the Evergreen Standards approach for all standards or only for limited use cases. We don't take a position on this question at the moment in the document, but we list here some of the proposed use cases that have been mentioned:<br />
<br />
* Accessibility API Mappings (see https://github.com/w3c/w3process/issues/79)<br />
* Vocabularies. This is because most vocabulary defintions have little IPR contention, and grow in a natural incremental fashion.<br />
* Registries. Similar reasons to vocabularies<br />
* Profiles of the Web Platform (e.g Web Media). Profiles of the Web Platform involve little spec development, but indicate which portions of the standards are most appropriate for industry segments.<br />
* Maintenance. Maintenance of specification by nature is intended to track evergreen incremental enhancements rather than bold new features; plus have less IPR contention.<br />
* Core infrastructure. Some specs provide core infrastructure for other specs; but may not need to reach a level of Recommendation per se. Web IDL might be an example.<br />
* Incremental guidance. Specification such as WebAppSec seem well suited for an incremental or evergreen approach.<br />
* All specifications. There are those that feel that an Evergreen approach is a best fit for all specs.<br />
<br />
= Roles and Responsibilities in the Evergreen Model =<br />
<br />
As with any W3C Working Group, there are Chairs for the group, Editors for the documents of the group, and participants in the group. However the roles and responsibilities are somewhat different in these groups.<br />
<br />
For an Evergreen Standard, the Editors of the specification have the primary role to ensure that the specification represents the current consensus of the Working Group. This is done by informal means: regular conversations between the editor and participants; participants raising issues about the spec in github; editors addressing issues and pull requests; and editors tracking implementations to ensure that the ER is both reflective of implementation as well as sensitive to the issues raised by the community. The Editor achieves this consensus without issuing formal calls for consensus; instead the Editor is continually in contact with the group to ensure that the ER document represents a consensus.<br />
<br />
As opposed to the REC track, the Chair does not have the responsibility to call for consensus or assess consensus as a result of a poll of participants. But the Chair has an important oversight role to ensure that the group's discussions proceed professionally and in accordance to CEPC, and to be a resource for participants who disagree with the way that the editors are documenting the evolving consensus of the group. If a participant believes that the editor is not behaving fairly, the chair is a resource to facilitate discussion between the chair and editor. If that does not solve the issue, the chair may also issue informative calls for consensus, or engage in other discussions to see whether consensus can be reached or whether the editor can adjust their position. <br />
<br />
Despite this important facilitation role of the chair, they generally do not have the authority to overrule the sense of the editor of where consensus lies during the ER phase of a specification development. However, in an extreme case, the chair can request that the Director look into the situation and possibly remove the chair.<br />
<br />
We discussed in the [https://www.w3.org/wiki/Evergreen_Standards#Overview Overview] that we expect incremental community review of an ER. It is the responsibility of the chair to ensure that there is appropriate notification to review groups about the progress of the ER.<br />
<br />
However, when the ER is ready to make the transition to the REC track, the chairs will have a more significant role assessing consensus in the usual way.<br />
<br />
= Documents and their status =<br />
<br />
We have described the mechanics of how a WG group develops an ER, with the editor assessing consensus and seeking incremental wide review. The next question is, if this is done successfully, then what is W3C recommending in terms of the spec? What should developers do with it? What can developers depend on, and what risks are there? <br />
<br />
We address that in this section, but first we take a broader view of different W3C documents and what W3C is saying about them. After all, W3C provides many types of documents. For each type of document, W3C conveys "status" to the document based on the process used to generate the document.<br />
<br />
* Community Group Specifications. These documents have no particular W3C status, although the individual contributions come with a level of patent protection through the W3C CLA.<br />
<br />
* Community Group Final Specifications. These documents have no particular W3C Status, although the entire specification comes with enhanced patent protection through the FSA agreement that may be signed by participating organizations.<br />
<br />
* Working Group Working Draft. These documents have no particular W3C status, but they are guaranteed to be within the scope of a WG approved by the Director after review by the AC.<br />
<br />
* Working Group Candidate Recommendation. These documents, like Working Drafts are within an approved scope. Additionally, they:<br />
** Have met the requirements of the WG, or explained why the requirements have changed.<br />
** Have addressed issues raised<br />
** Represent the consensus of the WG<br />
** Have a plan to demonstrate implementation experience<br />
** Have received wide review (including horizontal review)<br />
** Have received Director's approval for this status<br />
<br />
* Working Group Recommendation. These documents have all of the "status" as CR documents. They have the additional status of:<br />
** Have demonstrated implementation experience<br />
** Have W3C Royalty Free licensing commitments associated with the specification.<br />
** Have received AC review of the spec<br />
** Have ensured that all Formal Objections are resolved through Director review<br />
** Have an Appeals process if the AC disagrees with the Director<br />
** Represents a stable reference.<br />
** Has been adopted<br />
<br />
That brings us to Evergreen Standards. One the one hand, W3C needs a track for them because W3C's TAG has determined that there is an Evergreen Web [1]. But that puts pressure on the Standards Development Process. Standards must constantly be updated to ensure the Web's usefulness. But it is not possible to achieve all of the "status" features of a W3C Recommendation and be responsive to that time frame.<br />
<br />
That is why W3C is introducing an experimental path called Evergreen Standards to address that. In ES, there is a continuous evolution of the standard and a patent policy which provides continually improving patent commitments. Key features of the W3C process such as document review are done incrementally. This results in a document, the Evergreen Recommendation, that has sufficient review that W3C can provide a ''tentative recommendation'' to implementors that the spec may be implemented - while acknowledging that it does not have the full "status" of a W3C Recommendation. <br />
<br />
So, ''incremental review'' means that the WG operates in a fashion that:<br />
* The regularly announce that their documents should get wide review<br />
* They specifically maintain a relationship with horizontal reviewers to get their review<br />
* But, they may be operating too quickly for a full wide review.<br />
<br />
For that reason, in a charter which specifies that a spec will be developed as an ES, the charter will indicate a time frame for the ES spec to be taken to a Recommendation. There might be several years of development on the ES path, yet there is an expectation that at some point a REC will be achieved as well. There may be circumstances where the Director and AC conclude that the REC path is not necessary.<br />
<br />
* Accordingly, an Evergreen Recommendation has the following "status" associated with it:<br />
** Are within the approved scope of a WG<br />
** Represent the consensus of a WG (driven by the editor with oversight from the WG chair)<br />
** Have demonstrated implementation experience<br />
** Have received incremental wide review (including incremental horizontal review)<br />
** All key horizontal issues have been resolved<br />
** Have ES contribution Patent Commitments associated with the spec<br />
<br />
Thus the ES has achieved much of what the community is looking for and hence W3C confers it with the status of ES which both informs the community of what they can rely on, and also establishes where there is incompleteness.<br />
<br />
The most serious incompleteness is the incompleteness of patent commitments. Accordingly, it is expected that the WG will on a regular basis (e.g. every 12 months) create an ER Snapshot which gets the benefit of full patent commitments for the ER spec.<br />
<br />
That still does not provide all of the value of a complete consensus process with the widest possible review. Accordingly, at an even less frequent review cycle, snapshots are taken through the full REC process.<br />
<br />
* Accordingly, the benefit of ultimately taking an ER spec to a REC as well is to ensure that the spec ultimately has:<br />
** Full wide review (including horizontal review)<br />
** Director approval<br />
** Received an AC review of the spec<br />
** Ensured that all Formal Objections are resolved through Director review<br />
** The benefit of an Appeals process if the AC disagrees with the Director<br />
** A stable reference.<br />
<br />
[1] https://www.w3.org/2001/tag/doc/evergreen-web/<br />
<br />
= Different Evergreen Models =<br />
<br />
There is a choice between a âsnapshot' and sliding-window model, for both IPR review and functional review. What we have here is hybrid -- sliding-window for the technical reviewers, snapshot for the IPR.<br />
<br />
This is like the WHATWG [https://whatwg.org/workstream-policy process] which requires a periodic manual "review draft" ('snapshot') approximately every 6 months, and at that time all the legal reviewers have 45 days to respond. WhatWG doesnât have liaisons, cross-functional groups, an Advisory Committee, or Director/team.<br />
<br />
In the sliding-window model, we deem all the technical groups (external, cross-functional, Advisory Committee, and Director/team) to have tacitly accepted features 180 days after they first appear, unless they file an issue. This incremental tacit acceptance is sufficient for W3C to confer status on an ER that there is sufficient review to be reasonably confident that a feature is stable and can be implemented. But it is less than the status associated with a full W3C Recommendation which has had wider and more complete review.<br />
<br />
If an issue has been raised, the editor has the lead role to address the issue and re-establish consensus. This is discussed in: [https://www.w3.org/wiki/Evergreen_Standards#Roles_and_Responsibilities_in_the_Evergreen_Model Roles and Responsibilities]<br />
<br />
There is little '''functional''' difference between âWeâll keep you informed of the grocery list as it builds, and you must do your grocery shopping at least once a weekâ and âYou must do your grocery shopping immediately when the editor issues the weekly shopping listâ â it is the same amount of work, at the same frequency; but the former allows you to choose when, and indeed spread it out if you want to, while the latter says âjump nowâ. But there is a difference of work-mode.<br />
<br />
= Licensing =<br />
<br />
We require the PSIG to look at spec development in the Evergreen model, the RF licensing requirements of W3C, and the spec review process within a member organization. But the general philosophy around licensing should be:<br />
<br />
Based on the WHATWG [https://whatwg.org/workstream-policy process], perhaps with <br />
* an adjustment of intervals (we probably prefer a longer filing period, say 60 days).<br />
* a provision that WHATWG lacks, for an exclusion opportunity on the current Working Draft, on leaving the WG (to match the Patent Policy, and close a significant gap).<br />
<br />
An exclusion filing must result in:<br />
# A notification to at least the WG general mailing list, the advisory committee, and PSIG, so that the community is immediately aware and can take appropriate steps.<br />
# The formation of a [https://www.w3.org/Consortium/Patent-Policy-20170801/#sec-Exception Patent Advisory Group] (PAG).<br />
# The documentation, in the header of the specification, of the exclusion and the PAG, until the PAG completes its operation and its recommendations implemented.<br />
<br />
<br />
<br />
= Advisory Committee (AC), Director, Cross-functional, and Wide Review =<br />
<br />
The W3C has a value that all substantive changes are subject to these four kinds of review: "horizontal review," "wide review,", Director, and Advisory Committee review. For Continuous Publication, we mandate automated reports to the AC and cross-functional groups on a regular basis, reporting on substantive changes. This is what provides the signal to cross functional groups that they may perform their reviews, but does not guarantee that the reviews will take place. If the WG is rapidly making additions to the spec, it is possible that cross function groups will not have the ability for a full review. But the notification ensures that there will at least be an incremental review.<br />
<br />
In the past, cross-functional groups have been at "arms length", and doing reviews only at major transitions. Now we're asking for more incubation, experimental implementation, and so on, waiting for a transition in the REC process may be too late; there may be implementations, test suites, and designs that follow on from a feature, already in place. For both continuous publications and the traditional rec-track process, cross-functional groups need to be noticing issues and changes as they arise, and reacting as soon as possible when they see problems, ideally by having people 'embedded' in those other working groups, but minimally by watching specification progress.<br />
<br />
External groups should be notified by liaison of the existence of the Continuous Publication, as early as is practical and useful, and agreement reached with them how they will review substantive changes. They may request to be added to the automated report, for example; they may elect to watch the repository manually; or ask to be notified manually by the WG e.g. in liaison or email. Such manual notification should be both archived and also occur no less frequently than every 180 days.<br />
<br />
There is a 180-day period before changes are considered reviewed and accepted. This period starts on the first report that details the change (even if it was later reverted and re-inserted). Note that anyone, including AC, cross-functional groups, public, and members of the WG, are free to comment on anything at any time, of course; the 180-day deadline merely sets a date before which changes ought to be considered by the working group, and after which they might apply more back-pressure.<br />
<br />
This implies a tooling requirement. There must be simple to use automated tools which inform the community when a change has been made so that way they know which changes are about to become accepted. Further, a reviewer who has reviewed the document in the past will want to know the changes since their last review.<br />
<br />
To enable the automated reports, all changes must be made through Pull Requests (no direct commits). Pull Requests are considered '''substantive''' unless tagged as "Editorial" or "Minor technical". Issues are assumed non-substantive '''unless''' tagged explicitly as substantive (to avoid flooding the reports with issues that have not yet been categorized).<br />
<br />
(Note that the tagging for issues is necessarily the opposite to Pull Requests, as we don't want to report untagged, newly filed, issues, that the WG has not yet considered, as automatically substantive.)<br />
<br />
The automated report must detail:<br />
* new substantive changes since the prior report<br />
* substantive changes that will be declared past their 180 day review period in the next automated report (i.e. a kind of 'last call' for comments)<br />
* substantive changes that have just passed their 180 review period<br />
* all other changes (minor, editorial, etc.) performed via Pull Requests<br />
* suitable reporting on issues, noting particularly any tagged "substantive" or "cross-functional" (recently opened, recently closed, tagged substantive but still open, etc.)<br />
<br />
(Note the the WG, cross-functional groups, external bodies, and AC are at liberty to request other tags, e.g. identifying issues or pull requests of particular concern to those communities; we already have a substantial set of [https://w3c.github.io/issue-metadata.html tags].)<br />
<br />
For any issue filed against the document, the WG should consider whether an inline "issue" or âerratumâ notice should be placed in the document.<br />
<br />
For âreviewâ issues filed by the AC, a cross-functional W3C group, or by an external âliaisonâ body, the filing group can request, at any time after filing the issue and until the issue is resolved, any or all of:<br />
# that there be an inline issue/erratum notice, and/or <br />
# that the feature be marked as âprovisionalâ<br />
#that the feature be removed until consensus is reached.<br />
The WG is not automatically obliged to grant any request, but note that such denial may escalate the disagreement.<br />
<br />
If the WG and filer are unable to reach consensus, then the usual recourse to Formal Objections, Appeals, and Director rulings can be followed. As the continuous publication process does not entail formal Transitions, Director review can be triggered by the filer and WG deciding that they are at an impasse and one of them filing a Formal Objection. Formal Objections must be documented in the header of the document until the resolution is implemented. <br />
<br />
Since features that are stable in the specification for 180 days are considered final (there is an implied "acceptance" decision), disagreements should be raised to the editor, and then to the chairs before that 180-day period expires. If an issue is raised to the editor and the chair does not feel that the editor has sufficiently addressed the issue, the chair may appeal to the Director; possibly removing the editor.<br />
<br />
Similarly, if a participant has raised an issue and believes that neither is appropriately addressing their issue, they should Formally Object to the Director prior to a feature being around for 180 days. But they may only do that if they have first raised the issue with the editor and the chair and they have not gotten satisfaction.<br />
<br />
= Charter, Repository, Document, Testing, and Implementation Requirements =<br />
<br />
WG Charters may declare that a document is developed on the Recommendation Track, or on the Continuous Publication track. Changes between tracks, for any document, require a new approved charter. <br />
<br />
In order to enable 'harvesting' of the Github repository URLs of Continuous Publications, by both lawyers and the tools that inform reviewers, the Github repositories must be created before the charter is sent to formal AC review, and the URLs to those repositories must be in the charter, in a section clearly listing those documents on the Continuous Publication track.<br />
<br />
Those Github repositories must be in the W3C space and also must document the publication URL (usually Github.io) of the readable document.<br />
<br />
The readable document must list, in its header, the URL that refers to the latest viewable version, and also a permanent URL to the specific revision being viewed. It should also identify the Github repository where issues are filed and revisions made. As noted above, both unresolved (a) Patent Exclusions and (b) Formal Objections must be documented in the header of the specification.<br />
<br />
The charter must identify the implementability, implementation, test suite, and test pass coverage requirements for a feature to be considered not provisional but final. Features that do not meet these requirements should be integrated first as provisional, and a second Pull Request made to change them to non-provisional, when the requirements are met.<br />
<br />
= Implementation expectations =<br />
<br />
Typically speaking an ES specification will consist of different features at different levels of implementation maturity due to the requirement to be "Evergreen", that is, very reflective of current implementation and thinking among implementors. Included in that are features:<br />
<br />
* For which there is sufficient implementation experience and testing that the Director would ordinarily feel that those features could be approved in a W3C Recommendation.<br />
* For which interoperability has not yet been demonstrated, but there are at least commitments from sufficient implementors that there is a strong likelihood that the features will ultimately be accepted as Recommendations.<br />
* (In rare cases) Draft features that the WG is working on that are significant chartered deliverables being developed in the WG which are expected to be implemented but which lack firm implementation commitments at this time.<br />
<br />
While there could be good reasons to have features of various levels of maturity in a specification, it is important to clarify what part of the specification is actually being given support by W3C for developers to implement.<br />
<br />
For all specifications for which W3C is conferring status, the rule is that the status is only being conferred on those features where there has been sufficient implementation experience and testing to demonstrate interoperability. This is true whether the features are in an ES, an ES snapshot, or a W3C Recommendation.<br />
<br />
That does not mean that the other features need to be stripped from the document. They remain in the document but are considered as informative material for the spec, not normative, endorsed features for implementors.<br />
<br />
This characterization of what parts of the spec are considered normative must appear in the status of the document.<br />
<br />
= Tooling Requirements =<br />
<br />
There are various forms of tooling requirements. Some of them are tooling for the specs, to identify metadata about feature status. Other tooling relates to tagging issues in the Github repository for the spec.<br />
<br />
We have indicated above some of the required tooling for features. Since features achieve greater status by aging (in particular, we assume after 180 days there has been sufficient time for incremental horizontal review), there needs to be tooling so it is easy to determine when a feature was introduced and/or last changed.<br />
<br />
Since features achieve greater status by acquiring implementation experience, testing, and demonstrating interoperability, there needs to be tooling so it is easy to determine that a feature has all of this experience.<br />
<br />
Since a feature is more meaningful to implementors when there are implementation commitments, there must be tooling for that.<br />
<br />
Since a feature is considered normative in an ES when it has 180 days of aging and implementation experience, tooling must make it easy to identify that status as well.<br />
<br />
Tooling related to tagging issues in GH is as follows:<br />
<br />
We need <br />
* to define the standard tags that the report tool will use to work on, for Issues and Pull Requests.<br />
* the report tool to distil Pull Requests by tag (editorial, minor technical, or assumed substantive) and date (first appearance, will hit 180 days in the next 30 days, has passed 180 days, all since merging)<br />
* the report tool to distill Issues by tag also<br />
<br />
Ideally there is a commit hook that generates a "permanent link to this version" header.<br />
<br />
Note that all documents in a Github pages repo can have a unique URL, and are immutable; these come free. Those wanting to reference a specific unchanging version can do that. You can refer to a specific revision in GitHub using htmlpreview or rawgit.com; for example the August 17th version of WebVTT is<br />
<br />
<http://htmlpreview.github.io/?https://github.com/w3c/webvtt/blob/2b24ae60e84e8cbac033c148db2715104e0b9368/index.html><br />
<br />
or rawgit.com<br />
<br />
<https://rawgit.com/w3c/webvtt/2b24ae60e84e8cbac033c148db2715104e0b9368/index.html><br />
<br />
It should be easy to mark a document as under PAG review or under a Formal Objection, while exclusion or FO processing is in progress.<br />
<br />
We might like better support for in-line errata, and provisional material, and the ability to see a document without those (and thus make a snapshot), but this is optional.<br />
<br />
= Tooling Design =<br />
<br />
For a given section, sub-section, paragraph, or API of a specification, we may identify the following:<br />
<br />
# tests in WPT<br />
# test results from WPT<br />
# feature implementation information from caniuse.com<br />
# 180 days information<br />
# articles in MDN<br />
<br />
For snapshots, the annotations will be providing as JSON objects, contained in one file per specification generated on the day of the snapshot, then loaded and render using a JS script. The annotations within a given snapshot are NOT expected to change/involve overtime. In order of preference, each annotation object will be identifiable with:<br />
<br />
* API information (eg AuthenticationExtensionsClientOutputs, AuthenticationExtensionsClientOutputs.rawId)<br />
* CSS property name (eg "background-size")<br />
* Markup elements and attributes (eg "use", "use@width")<br />
* section title (eg "Android Key Attestation Statement Format")<br />
* CSS Selector (eg "pre.idl")<br />
* fragment identifiers (eg #preventSilentAccessCredential)<br />
* section numbering<br />
<br />
The same identifier may apply to more than on annotation object.<br />
<br />
Bikeshed and ReSpec, the most currently used spec editing framework, will need proper support to identify annotation object identifiers as well as WPT, caniuse.com, and MDN identifiers. Test files can be identified by providing a list of files in WPT. Test results can be deduced from that list. A test file may contain more than one test and we will need to work with WPT folks to get a method to identify specific tests within a test file. caniuse.com already provide annotations to integrate a feature implementation information.<br />
<br />
A tool will generate the annotation file using information embedded within the specification. The specification may contain additional annotation objects to be merged as well. A tool should check the resulting annotations to determine if all annotation objects are still relevant.<br />
<br />
Last update information will be generated based on running diffs with the 180 days-ago version and generating resulting JSON annotation objects. We'll need to explore if the result can be refined using commit history information (see [https://github.com/w3c/payment-request/commits/gh-pages payment-request commits]).<br />
<br />
For all W3C specifications, it is important to know how they are normatively referenced by other specifications - both on the ES track as well as the REC track.<br />
<br />
It is possible to normatively reference a W3C specification, evergreen or working draft, from a W3C Recommendation as long as the [[https://www.w3.org/2013/09/normative-references|Director's consideration]] are applied, in particular:<br />
<br />
* Stability of the referenced part(s)<br />
* Nature of the dependency<br />
* Status of implementations<br />
<br />
= Sample Charter Language =<br />
<br />
The Fruit Action Working Group (FAWG) will develop the following on the Recommendation Track:<br />
* Pineapple picking and handling, <br />
and the following on the Continuous Publication Track,<br />
* Olive picking, pitting, curing and bottling; in the Github Repo (URL goes here)<br />
** The ES spec for Olive picking will have an IPR snapshot every 12 months.<br />
** While the Olive picking spec is on the Continuous Publication Track, it is intended that after 4.7 years, a snapshot will be taken to Recommendation.<br />
<br />
For a feature to be considered final by the working group (on either track):<br />
* it must be testable by a test in the Agricultural Products Test (APT) suite at (URL goes here)<br />
* there must be at least 3 complete implementations<br />
* at least 2 of those implementations must pass the applicable APT tests<br />
* at least 1 of those implementations generates packed olives, and at least one uses packed olives, and they interoperate<br />
<br />
Features that do not meet these requirements will be integrated first as provisional, and a second Pull Request made to change them to non-provisional, when the requirements are met.<br />
<br />
= Sample Document Header =<br />
<br />
Olive picking, pitting, curing and bottling.<br />
<br />
W3C Evergreen Standard 15 March 55BCE<br />
<br />
'''Latest version''': (URL to the evergreen standard goes here)<br />
<br />
'''Permanent link to this version''': (URL for this exact version goes here)<br />
<br />
'''Repository''': (URL to the Github repository for issues etc.)<br />
<br />
'''Editors''': (Editors listed by name)<br />
<br />
'''Current unresolved Patent Licensing Exclusions''': none, or a URL to the exclusion plus a URL to the PAG information<br />
<br />
'''Current unresolved Formal Objections''': none, or a URL to the Formal Objection filing<br />
<br />
'''Abstract''': (as usual)<br />
<br />
'''Status of this document''': <br />
<br />
This document is developed by the (link to Working Group). Comments and issues are welcomed and should be filed at the (URL to the issues page of the Github repository). <br />
<br />
This document was produced by a group operating under the W3C [https://www.w3.org/wiki/Living_Standards Continuous Publication] process and policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with [https://www.w3.org/Consortium/Patent-Policy-20170801/#sec-Disclosure section 6 of the W3C Patent Policy].<br />
<br />
The disclosure obligations of the Participants of this group are described in the Working Group charter.<br />
<br />
= Detailed explanation of the Continuous Track Patent policy =<br />
<br />
Looking for input from PSIG.<br />
<br />
= Summaries for various constituencies =<br />
<br />
== Lawyers ==<br />
<br />
(needs editing to match the snapshot model)<br />
<br />
Lawyers will need to take roughly the following steps:<br />
* Review the charters of the working groups that your organization intends to participate in. <br />
* Collect, from the charters, the URLs of the Continuous Publication repositories and add them to your 'watch list'.<br />
* When you join a working group, review the most recent snapshot and file any applicable exclusions, within the deadline.<br />
* When snapshots are made, review it and file any applicable exclusions, within the deadline.<br />
* Watch other exclusion filings, of course; take any steps you think indicated, and consider joining the PAG.<br />
* Optionally, if you want early notification of changes, watch the monthly automated reports of Pull Requests, or get automated immediate notification by GitHub of Pull Requests, for repositories in your watch list.<br />
* When you leave a working group, do a final exclusion check on the working draft that was current as of the time you left the group.<br />
<br />
== Working Groups ==<br />
<br />
Working groups need to do the following:<br />
* Create Github repositories for your documents on the Continuous Publication track before writing your charter.<br />
* Define clearly in your charter the documents on the Continuous Publication track; list the URIs of their repositories.<br />
* Define clearly in your charter what requirements a feature must meet to be considered acceptable (testing, implementation, interop, etc.).<br />
* Watch Pull Requests and make sure:<br />
** that Pull Requests are correctly tagged (editorial, minor, or, by default, substantive);<br />
** that if Pull Requests add to 'core draft' (ie. material that is not an erratum report, provisional, or editor's note) that the addition meets the WG requirements (testing, implementation, interop, etc.).<br />
* Watch issue filings and tag those also.<br />
<br />
== Editors == <br />
<br />
Editors need to make sure that material that is provisional, an erratum report, or an editor's note, is correctly tagged, and that tags are removed when the material becomes final. If a new feature is too complex to be inserted inline as provisional, manage separate "editor's drafts" that the WG can review until such time as they agree to merging. Check that the 'core draft' reads correctly as well as checking the entire document.<br />
<br />
If there have been any technical changes since the last snapshot, make a new snapshot no later than 180 days after the last one.<br />
<br />
== Other Groups ==<br />
<br />
Read the automated reports and review the changes as they happen. File an issue with at most 180 days if there is a problem. Raise a Formal Objection, ideally within 180 days, if impasse is reached so that Chairs can facilitate a discussion and (if necessary) the Director can get involved if needed to resolve disagreement.<br />
<br />
== Team == <br />
<br />
The team:<br />
* makes sure the process is followed, Charters are correctly drafted, etc.<br />
* makes sure that the Pull Requests (and issues) are tagged correctly, and that technical changes meet the charter requirements;<br />
* makes sure that snapshots are made if technical changes have occurred since the last snapshot, and 180 days are about to elapse;<br />
* ensures that the comments from outside the WG are given due and timely consideration by the WG (notably, within the six months tacit acceptance period);<br />
* when an exclusion is filed, the PAG is formed, notifications sent, and the document header updated (and removed when the PAG is completed);<br />
* when a Formal Objection is filed, notifications sent, and the document header updated (and removed when the Formal Objection is resolved).<br />
<br />
= Comparison of the Continuous and Traditional Recommendation Tracks =<br />
<br />
{| class="wikitable"<br />
|-<br />
! Concept !! Continuous !! Traditional<br />
|-<br />
| wide review || Incremental, by automatic notification and lack of objection || On Transitions<br />
|-<br />
| horizontal review (i18n, a11y, security, privacy, perf, device independence, TAG, etc.) || Incremental, by automatic notification and lack of objection || On Transitions<br />
|-<br />
| Advisory Committee review || Incremental, by automatic notification and lack of objection || On Transitions<br />
|-<br />
| tests || Defined in charter, verified by WG and reviewers incrementally || Defined in charter, verified by WG and reviewers on transitions<br />
|-<br />
| issues addressed || Verified incrementally || Verified on transitions<br />
|-<br />
| IP || Whole spec from all WG members given exclusion opportunity at a snapshot || Whole spec from all WG members at Rec<br />
|-<br />
| consensus || verified continuously || verified at transitions etc.<br />
|-<br />
| errata || In issues and possibly inline || Not well handled; in issues or possible erratum document<br />
|-<br />
| maintenance || Ongoing || Episodic<br />
|-<br />
| use cases || In charter or requirements document (which may also be Continuous) || In charter or Wiki or somewhere<br />
|-<br />
| requirements || In charter or requirements document (which may also be Continuous) || In charter or Wiki or somewhere<br />
|-<br />
| implementation commitments || Requirements defined by charter || Requirements defined by charter<br />
|-<br />
| implementation experience || Requirements defined by charter || Requirements defined by charter<br />
|-<br />
| Director's approval || Incremental, tacit unless objections raised || On transitions<br />
|-<br />
| Appeal process || After Formal Objection || After Formal Objection<br />
|-<br />
| stable reference || By using specific revision references or periodic Rec snapshots || Normal<br />
|-<br />
| adoption || Requirements defined by charter || Requirements defined by charter<br />
|-<br />
| status duration || Indefinite || Indefinite<br />
|}</div>Plehegarhttps://www.w3.org/wiki/index.php?title=Evergreen_Standards&diff=108648Evergreen Standards2018-12-17T20:09:08Z<p>Plehegar: minor</p>
<hr />
<div>= Introduction =<br />
<br />
== Overview ==<br />
<br />
We are looking at the [https://www.w3.org/2001/tag/doc/evergreen-web/ Evergreen Standards] (also known as living standards) model as a possible alternative way to develop and publish W3C Recommendations. Many Working Groups already publish frequent iterative working drafts, and continuously resolve issues, test, review, and maintain specs at the "top of tree," so we ask what it would take to make those living documents into formal publications of the W3C. In the analysis, we consider various aspects and values embodied in the current W3C Process and Patent Policy to assess how those can be met in an iterative mode. <br />
<br />
This proposed mode is designed for continuous development of specifications. We propose to call this "Continuous Publication" process Evergreen Standards. The suggested name for the product here is Evergreen Recommendation. There are two types of Evergreen Recommendations (ERs). The vanilla form is called an ER. Additionally, snapshots might be taken for IPR purposes and those are called ER Snapshots.<br />
<br />
In particular, this program aims to manage specifications on a continuous basis, with a minimum of manual process steps needed, so that in the specifications<br />
* all material that has been in the specification for six months or more has been '''available''' for review:<br />
** by the community â but particularly the working group, the Advisory Committee, and the Team â that the specification meets the charter requirements (for testing, implementation, and interoperability, for example);<br />
** by the cross-functional groups for acceptability;<br />
** by the liaison groups and the wider public for acceptability.<br />
* all material that has passed a snapshot exclusion opportunity carries a license to the unexcluded essential IPR from those who had the opportunity<br />
<br />
We say that the material has been "available" for review because we envisage "incremental" review by the entire community including cross-functional, horizontal, and liaison groups. We generally believe that a duration of 180 days should be sufficient to catch almost any cross-functional issues. But we also recognize that not all cross-functional review can take place at that time frame. So we provide a level of status to Evergreen Recommendations, and a higher level of status when taken to the Recommendations track for a full review.<br />
<br />
Under the current [https://www.w3.org/2018/Process-20180201/ Process] and [https://www.w3.org/Consortium/Patent-Policy-20170801/ Patent Policy], royalty-free patent commitments attach when a document is published as a Recommendation, after exclusion periods at FPWD (first public working draft) and CR (Candidate Recommendation). We propose that for continuous publication, there be periodic snapshots, after which patents not excluded would be licensed royalty-free.<br />
<br />
This is a close companion to the separately discussed [[Repositories]] question.<br />
<br />
We expect this model to apply in two general cases, but see more about [https://www.w3.org/wiki/Evergreen_Standards#Use_Cases use cases] below.<br />
* Specifications which are, in a sense, built of small independent pieces, where those pieces are added incrementally, for example a document that has a set of independent APIs that map to other features<br />
* Maintenance of Recommendations, where bug fixes and minor missing features can be added with less pain than the 'revised recommendation'.<br />
<br />
== Transitions between the Evergreen and Recommendation Tracks ==<br />
<br />
The following initiations or transitions are envisaged:<br />
* A document may be initiated on either track ("this document will be developed as a Recommendation | Evergreen Standard")<br />
* A document previously on the Recommendation track may switch to the Evergreen track; typically this happens after Recommendation status, for maintenance, but may happen on any re-chartering;<br />
* A document on the Evergreen track may enter the Recommendation track by satisfying the requirements for a WG Working Draft or Candidate Recommendation, and entering as such. This would typically be an ER Snapshot.<br />
** Transition to the REC track does not necessarily mean that specification development as an ES stops because the work is entirely completed. For key parts of the web architecture, the spec is in constant evolution. However moving a snapshot to the REC level provides certain checking and validation for the work (e.g. complete cross-functional and AC review) which adds value in the technology development. There could still be an ES version that is further developed and developers wanting the most up to date version of the specification should use that.<br />
* Although a specification might remain as an ER for many years, there is an expectation that ultimately every spec transitions to the REC track, because it is only at the REC track where full horizontal review and AC review is provide. The Charter for an ES spec must specify the expected point in time for transition to W3C Recommendation, even if that time is beyond the time horizon of a particular charter.<br />
<br />
= Use Cases =<br />
<br />
There is debate in the community whether to apply the Evergreen Standards approach for all standards or only for limited use cases. We don't take a position on this question at the moment in the document, but we list here some of the proposed use cases that have been mentioned:<br />
<br />
* Accessibility API Mappings (see https://github.com/w3c/w3process/issues/79)<br />
* Vocabularies. This is because most vocabulary defintions have little IPR contention, and grow in a natural incremental fashion.<br />
* Registries. Similar reasons to vocabularies<br />
* Profiles of the Web Platform (e.g Web Media). Profiles of the Web Platform involve little spec development, but indicate which portions of the standards are most appropriate for industry segments.<br />
* Maintenance. Maintenance of specification by nature is intended to track evergreen incremental enhancements rather than bold new features; plus have less IPR contention.<br />
* Core infrastructure. Some specs provide core infrastructure for other specs; but may not need to reach a level of Recommendation per se. Web IDL might be an example.<br />
* Incremental guidance. Specification such as WebAppSec seem well suited for an incremental or evergreen approach.<br />
* All specifications. There are those that feel that an Evergreen approach is a best fit for all specs.<br />
<br />
= Roles and Responsibilities in the Evergreen Model =<br />
<br />
As with any W3C Working Group, there are Chairs for the group, Editors for the documents of the group, and participants in the group. However the roles and responsibilities are somewhat different in these groups.<br />
<br />
For an Evergreen Standard, the Editors of the specification have the primary role to ensure that the specification represents the current consensus of the Working Group. This is done by informal means: regular conversations between the editor and participants; participants raising issues about the spec in github; editors addressing issues and pull requests; and editors tracking implementations to ensure that the ER is both reflective of implementation as well as sensitive to the issues raised by the community. The Editor achieves this consensus without issuing formal calls for consensus; instead the Editor is continually in contact with the group to ensure that the ER document represents a consensus.<br />
<br />
As opposed to the REC track, the Chair does not have the responsibility to call for consensus or assess consensus as a result of a poll of participants. But the Chair has an important oversight role to ensure that the group's discussions proceed professionally and in accordance to CEPC, and to be a resource for participants who disagree with the way that the editors are documenting the evolving consensus of the group. If a participant believes that the editor is not behaving fairly, the chair is a resource to facilitate discussion between the chair and editor. If that does not solve the issue, the chair may also issue informative calls for consensus, or engage in other discussions to see whether consensus can be reached or whether the editor can adjust their position. <br />
<br />
Despite this important facilitation role of the chair, they generally do not have the authority to overrule the sense of the editor of where consensus lies during the ER phase of a specification development. However, in an extreme case, the chair can request that the Director look into the situation and possibly remove the chair.<br />
<br />
We discussed in the [https://www.w3.org/wiki/Evergreen_Standards#Overview Overview] that we expect incremental community review of an ER. It is the responsibility of the chair to ensure that there is appropriate notification to review groups about the progress of the ER.<br />
<br />
However, when the ER is ready to make the transition to the REC track, the chairs will have a more significant role assessing consensus in the usual way.<br />
<br />
= Documents and their status =<br />
<br />
We have described the mechanics of how a WG group develops an ER, with the editor assessing consensus and seeking incremental wide review. The next question is, if this is done successfully, then what is W3C recommending in terms of the spec? What should developers do with it? What can developers depend on, and what risks are there? <br />
<br />
We address that in this section, but first we take a broader view of different W3C documents and what W3C is saying about them. After all, W3C provides many types of documents. For each type of document, W3C conveys "status" to the document based on the process used to generate the document.<br />
<br />
* Community Group Specifications. These documents have no particular W3C status, although the individual contributions come with a level of patent protection through the W3C CLA.<br />
<br />
* Community Group Final Specifications. These documents have no particular W3C Status, although the entire specification comes with enhanced patent protection through the FSA agreement that may be signed by participating organizations.<br />
<br />
* Working Group Working Draft. These documents have no particular W3C status, but they are guaranteed to be within the scope of a WG approved by the Director after review by the AC.<br />
<br />
* Working Group Candidate Recommendation. These documents, like Working Drafts are within an approved scope. Additionally, they:<br />
** Have met the requirements of the WG, or explained why the requirements have changed.<br />
** Have addressed issues raised<br />
** Represent the consensus of the WG<br />
** Have a plan to demonstrate implementation experience<br />
** Have received wide review (including horizontal review)<br />
** Have received Director's approval for this status<br />
<br />
* Working Group Recommendation. These documents have all of the "status" as CR documents. They have the additional status of:<br />
** Have demonstrated implementation experience<br />
** Have W3C Royalty Free licensing commitments associated with the specification.<br />
** Have received AC review of the spec<br />
** Have ensured that all Formal Objections are resolved through Director review<br />
** Have an Appeals process if the AC disagrees with the Director<br />
** Represents a stable reference.<br />
** Has been adopted<br />
<br />
That brings us to Evergreen Standards. One the one hand, W3C needs a track for them because W3C's TAG has determined that there is an Evergreen Web [1]. But that puts pressure on the Standards Development Process. Standards must constantly be updated to ensure the Web's usefulness. But it is not possible to achieve all of the "status" features of a W3C Recommendation and be responsive to that time frame.<br />
<br />
That is why W3C is introducing an experimental path called Evergreen Standards to address that. In ES, there is a continuous evolution of the standard and a patent policy which provides continually improving patent commitments. Key features of the W3C process such as document review are done incrementally. This results in a document, the Evergreen Recommendation, that has sufficient review that W3C can provide a ''tentative recommendation'' to implementors that the spec may be implemented - while acknowledging that it does not have the full "status" of a W3C Recommendation. <br />
<br />
So, ''incremental review'' means that the WG operates in a fashion that:<br />
* The regularly announce that their documents should get wide review<br />
* They specifically maintain a relationship with horizontal reviewers to get their review<br />
* But, they may be operating too quickly for a full wide review.<br />
<br />
For that reason, in a charter which specifies that a spec will be developed as an ES, the charter will indicate a time frame for the ES spec to be taken to a Recommendation. There might be several years of development on the ES path, yet there is an expectation that at some point a REC will be achieved as well. There may be circumstances where the Director and AC conclude that the REC path is not necessary.<br />
<br />
* Accordingly, an Evergreen Recommendation has the following "status" associated with it:<br />
** Are within the approved scope of a WG<br />
** Represent the consensus of a WG (driven by the editor with oversight from the WG chair)<br />
** Have demonstrated implementation experience<br />
** Have received incremental wide review (including incremental horizontal review)<br />
** All key horizontal issues have been resolved<br />
** Have ES contribution Patent Commitments associated with the spec<br />
<br />
Thus the ES has achieved much of what the community is looking for and hence W3C confers it with the status of ES which both informs the community of what they can rely on, and also establishes where there is incompleteness.<br />
<br />
The most serious incompleteness is the incompleteness of patent commitments. Accordingly, it is expected that the WG will on a regular basis (e.g. every 12 months) create an ER Snapshot which gets the benefit of full patent commitments for the ER spec.<br />
<br />
That still does not provide all of the value of a complete consensus process with the widest possible review. Accordingly, at an even less frequent review cycle, snapshots are taken through the full REC process.<br />
<br />
* Accordingly, the benefit of ultimately taking an ER spec to a REC as well is to ensure that the spec ultimately has:<br />
** Full wide review (including horizontal review)<br />
** Director approval<br />
** Received an AC review of the spec<br />
** Ensured that all Formal Objections are resolved through Director review<br />
** The benefit of an Appeals process if the AC disagrees with the Director<br />
** A stable reference.<br />
<br />
[1] https://www.w3.org/2001/tag/doc/evergreen-web/<br />
<br />
= Different Evergreen Models =<br />
<br />
There is a choice between a âsnapshot' and sliding-window model, for both IPR review and functional review. What we have here is hybrid -- sliding-window for the technical reviewers, snapshot for the IPR.<br />
<br />
This is like the WHATWG [https://whatwg.org/workstream-policy process] which requires a periodic manual "review draft" ('snapshot') approximately every 6 months, and at that time all the legal reviewers have 45 days to respond. WhatWG doesnât have liaisons, cross-functional groups, an Advisory Committee, or Director/team.<br />
<br />
In the sliding-window model, we deem all the technical groups (external, cross-functional, Advisory Committee, and Director/team) to have tacitly accepted features 180 days after they first appear, unless they file an issue. This incremental tacit acceptance is sufficient for W3C to confer status on an ER that there is sufficient review to be reasonably confident that a feature is stable and can be implemented. But it is less than the status associated with a full W3C Recommendation which has had wider and more complete review.<br />
<br />
If an issue has been raised, the editor has the lead role to address the issue and re-establish consensus. This is discussed in: [https://www.w3.org/wiki/Evergreen_Standards#Roles_and_Responsibilities_in_the_Evergreen_Model Roles and Responsibilities]<br />
<br />
There is little '''functional''' difference between âWeâll keep you informed of the grocery list as it builds, and you must do your grocery shopping at least once a weekâ and âYou must do your grocery shopping immediately when the editor issues the weekly shopping listâ â it is the same amount of work, at the same frequency; but the former allows you to choose when, and indeed spread it out if you want to, while the latter says âjump nowâ. But there is a difference of work-mode.<br />
<br />
= Licensing =<br />
<br />
We require the PSIG to look at spec development in the Evergreen model, the RF licensing requirements of W3C, and the spec review process within a member organization. But the general philosophy around licensing should be:<br />
<br />
Based on the WHATWG [https://whatwg.org/workstream-policy process], perhaps with <br />
* an adjustment of intervals (we probably prefer a longer filing period, say 60 days).<br />
* a provision that WHATWG lacks, for an exclusion opportunity on the current Working Draft, on leaving the WG (to match the Patent Policy, and close a significant gap).<br />
<br />
An exclusion filing must result in:<br />
# A notification to at least the WG general mailing list, the advisory committee, and PSIG, so that the community is immediately aware and can take appropriate steps.<br />
# The formation of a [https://www.w3.org/Consortium/Patent-Policy-20170801/#sec-Exception Patent Advisory Group] (PAG).<br />
# The documentation, in the header of the specification, of the exclusion and the PAG, until the PAG completes its operation and its recommendations implemented.<br />
<br />
<br />
<br />
= Advisory Committee (AC), Director, Cross-functional, and Wide Review =<br />
<br />
The W3C has a value that all substantive changes are subject to these four kinds of review: "horizontal review," "wide review,", Director, and Advisory Committee review. For Continuous Publication, we mandate automated reports to the AC and cross-functional groups on a regular basis, reporting on substantive changes. This is what provides the signal to cross functional groups that they may perform their reviews, but does not guarantee that the reviews will take place. If the WG is rapidly making additions to the spec, it is possible that cross function groups will not have the ability for a full review. But the notification ensures that there will at least be an incremental review.<br />
<br />
In the past, cross-functional groups have been at "arms length", and doing reviews only at major transitions. Now we're asking for more incubation, experimental implementation, and so on, waiting for a transition in the REC process may be too late; there may be implementations, test suites, and designs that follow on from a feature, already in place. For both continuous publications and the traditional rec-track process, cross-functional groups need to be noticing issues and changes as they arise, and reacting as soon as possible when they see problems, ideally by having people 'embedded' in those other working groups, but minimally by watching specification progress.<br />
<br />
External groups should be notified by liaison of the existence of the Continuous Publication, as early as is practical and useful, and agreement reached with them how they will review substantive changes. They may request to be added to the automated report, for example; they may elect to watch the repository manually; or ask to be notified manually by the WG e.g. in liaison or email. Such manual notification should be both archived and also occur no less frequently than every 180 days.<br />
<br />
There is a 180-day period before changes are considered reviewed and accepted. This period starts on the first report that details the change (even if it was later reverted and re-inserted). Note that anyone, including AC, cross-functional groups, public, and members of the WG, are free to comment on anything at any time, of course; the 180-day deadline merely sets a date before which changes ought to be considered by the working group, and after which they might apply more back-pressure.<br />
<br />
This implies a tooling requirement. There must be simple to use automated tools which inform the community when a change has been made so that way they know which changes are about to become accepted. Further, a reviewer who has reviewed the document in the past will want to know the changes since their last review.<br />
<br />
To enable the automated reports, all changes must be made through Pull Requests (no direct commits). Pull Requests are considered '''substantive''' unless tagged as "Editorial" or "Minor technical". Issues are assumed non-substantive '''unless''' tagged explicitly as substantive (to avoid flooding the reports with issues that have not yet been categorized).<br />
<br />
(Note that the tagging for issues is necessarily the opposite to Pull Requests, as we don't want to report untagged, newly filed, issues, that the WG has not yet considered, as automatically substantive.)<br />
<br />
The automated report must detail:<br />
* new substantive changes since the prior report<br />
* substantive changes that will be declared past their 180 day review period in the next automated report (i.e. a kind of 'last call' for comments)<br />
* substantive changes that have just passed their 180 review period<br />
* all other changes (minor, editorial, etc.) performed via Pull Requests<br />
* suitable reporting on issues, noting particularly any tagged "substantive" or "cross-functional" (recently opened, recently closed, tagged substantive but still open, etc.)<br />
<br />
(Note the the WG, cross-functional groups, external bodies, and AC are at liberty to request other tags, e.g. identifying issues or pull requests of particular concern to those communities; we already have a substantial set of [https://w3c.github.io/issue-metadata.html tags].)<br />
<br />
For any issue filed against the document, the WG should consider whether an inline "issue" or âerratumâ notice should be placed in the document.<br />
<br />
For âreviewâ issues filed by the AC, a cross-functional W3C group, or by an external âliaisonâ body, the filing group can request, at any time after filing the issue and until the issue is resolved, any or all of:<br />
# that there be an inline issue/erratum notice, and/or <br />
# that the feature be marked as âprovisionalâ<br />
#that the feature be removed until consensus is reached.<br />
The WG is not automatically obliged to grant any request, but note that such denial may escalate the disagreement.<br />
<br />
If the WG and filer are unable to reach consensus, then the usual recourse to Formal Objections, Appeals, and Director rulings can be followed. As the continuous publication process does not entail formal Transitions, Director review can be triggered by the filer and WG deciding that they are at an impasse and one of them filing a Formal Objection. Formal Objections must be documented in the header of the document until the resolution is implemented. <br />
<br />
Since features that are stable in the specification for 180 days are considered final (there is an implied "acceptance" decision), disagreements should be raised to the editor, and then to the chairs before that 180-day period expires. If an issue is raised to the editor and the chair does not feel that the editor has sufficiently addressed the issue, the chair may appeal to the Director; possibly removing the editor.<br />
<br />
Similarly, if a participant has raised an issue and believes that neither is appropriately addressing their issue, they should Formally Object to the Director prior to a feature being around for 180 days. But they may only do that if they have first raised the issue with the editor and the chair and they have not gotten satisfaction.<br />
<br />
= Charter, Repository, Document, Testing, and Implementation Requirements =<br />
<br />
WG Charters may declare that a document is developed on the Recommendation Track, or on the Continuous Publication track. Changes between tracks, for any document, require a new approved charter. <br />
<br />
In order to enable 'harvesting' of the Github repository URLs of Continuous Publications, by both lawyers and the tools that inform reviewers, the Github repositories must be created before the charter is sent to formal AC review, and the URLs to those repositories must be in the charter, in a section clearly listing those documents on the Continuous Publication track.<br />
<br />
Those Github repositories must be in the W3C space and also must document the publication URL (usually Github.io) of the readable document.<br />
<br />
The readable document must list, in its header, the URL that refers to the latest viewable version, and also a permanent URL to the specific revision being viewed. It should also identify the Github repository where issues are filed and revisions made. As noted above, both unresolved (a) Patent Exclusions and (b) Formal Objections must be documented in the header of the specification.<br />
<br />
The charter must identify the implementability, implementation, test suite, and test pass coverage requirements for a feature to be considered not provisional but final. Features that do not meet these requirements should be integrated first as provisional, and a second Pull Request made to change them to non-provisional, when the requirements are met.<br />
<br />
= Implementation expectations =<br />
<br />
Typically speaking an ES specification will consist of different features at different levels of implementation maturity due to the requirement to be "Evergreen", that is, very reflective of current implementation and thinking among implementors. Included in that are features:<br />
<br />
* For which there is sufficient implementation experience and testing that the Director would ordinarily feel that those features could be approved in a W3C Recommendation.<br />
* For which interoperability has not yet been demonstrated, but there are at least commitments from sufficient implementors that there is a strong likelihood that the features will ultimately be accepted as Recommendations.<br />
* (In rare cases) Draft features that the WG is working on that are significant chartered deliverables being developed in the WG which are expected to be implemented but which lack firm implementation commitments at this time.<br />
<br />
While there could be good reasons to have features of various levels of maturity in a specification, it is important to clarify what part of the specification is actually being given support by W3C for developers to implement.<br />
<br />
For all specifications for which W3C is conferring status, the rule is that the status is only being conferred on those features where there has been sufficient implementation experience and testing to demonstrate interoperability. This is true whether the features are in an ES, an ES snapshot, or a W3C Recommendation.<br />
<br />
That does not mean that the other features need to be stripped from the document. They remain in the document but are considered as informative material for the spec, not normative, endorsed features for implementors.<br />
<br />
This characterization of what parts of the spec are considered normative must appear in the status of the document.<br />
<br />
= Tooling Requirements =<br />
<br />
There are various forms of tooling requirements. Some of them are tooling for the specs, to identify metadata about feature status. Other tooling relates to tagging issues in the Github repository for the spec.<br />
<br />
We have indicated above some of the required tooling for features. Since features achieve greater status by aging (in particular, we assume after 180 days there has been sufficient time for incremental horizontal review), there needs to be tooling so it is easy to determine when a feature was introduced and/or last changed.<br />
<br />
Since features achieve greater status by acquiring implementation experience, testing, and demonstrating interoperability, there needs to be tooling so it is easy to determine that a feature has all of this experience.<br />
<br />
Since a feature is more meaningful to implementors when there are implementation commitments, there must be tooling for that.<br />
<br />
Since a feature is considered normative in an ES when it has 180 days of aging and implementation experience, tooling must make it easy to identify that status as well.<br />
<br />
Tooling related to tagging issues in GH is as follows:<br />
<br />
We need <br />
* to define the standard tags that the report tool will use to work on, for Issues and Pull Requests.<br />
* the report tool to distil Pull Requests by tag (editorial, minor technical, or assumed substantive) and date (first appearance, will hit 180 days in the next 30 days, has passed 180 days, all since merging)<br />
* the report tool to distill Issues by tag also<br />
<br />
Ideally there is a commit hook that generates a "permanent link to this version" header.<br />
<br />
Note that all documents in a Github pages repo can have a unique URL, and are immutable; these come free. Those wanting to reference a specific unchanging version can do that. You can refer to a specific revision in GitHub using htmlpreview or rawgit.com; for example the August 17th version of WebVTT is<br />
<br />
<http://htmlpreview.github.io/?https://github.com/w3c/webvtt/blob/2b24ae60e84e8cbac033c148db2715104e0b9368/index.html><br />
<br />
or rawgit.com<br />
<br />
<https://rawgit.com/w3c/webvtt/2b24ae60e84e8cbac033c148db2715104e0b9368/index.html><br />
<br />
It should be easy to mark a document as under PAG review or under a Formal Objection, while exclusion or FO processing is in progress.<br />
<br />
We might like better support for in-line errata, and provisional material, and the ability to see a document without those (and thus make a snapshot), but this is optional.<br />
<br />
= Tooling Design =<br />
<br />
For a given section, sub-section, paragraph, or API of a specification, we may identify the following:<br />
<br />
# tests in WPT<br />
# test results from WPT<br />
# feature implementation information from caniuse.com<br />
# 180 days information<br />
# articles in MDN<br />
<br />
For snapshots, the annotations will be providing as JSON objects, contained in one file per specification generated on the day of the snapshot, then loaded and render using a JS script. The annotations within a given snapshot are NOT expected to change/involve overtime. In order of preference, each annotation object will be identifiable with:<br />
<br />
* API information (eg AuthenticationExtensionsClientOutputs, AuthenticationExtensionsClientOutputs.rawId)<br />
* CSS property name (eg "background-size")<br />
* Markup elements and attributes (eg "use", "use@width")<br />
* section title (eg "Android Key Attestation Statement Format")<br />
* CSS Selector (eg "pre.idl")<br />
* fragment identifiers (eg #preventSilentAccessCredential)<br />
* section numbering<br />
<br />
The same identifier may apply to more than on annotation object.<br />
<br />
Bikeshed and ReSpec, the most currently used spec editing framework, will need proper support to identify annotation object identifiers as well as WPT, caniuse.com, and MDN identifiers. Test files can be identified by providing a list of files in WPT. Test results can be deduced from that list. A test file may contain more than one test and we will need to work with WPT folks to get a method to identify specific tests within a test file. caniuse.com already provide annotations to integrate a feature implementation information.<br />
<br />
A tool will generate the annotation file using information embedded within the specification. The specification may contain additional annotation objects to be merged as well. A tool should check the resulting annotations to determine if all annotation objects are still relevant.<br />
<br />
Last update information will be generated based on running diffs with the 180 days-ago version and generating resulting JSON annotation objects. We'll need to explore if the result can be refined using commit history information (see [https://github.com/w3c/payment-request/commits/gh-pages payment-request commits]).<br />
<br />
= Referenceability =<br />
<br />
For all W3C specifications, it is important to know how they are normatively referenced by other specifications - both on the ES track as well as the REC track.<br />
<br />
Placeholder for PLH<br />
<br />
= Sample Charter Language =<br />
<br />
The Fruit Action Working Group (FAWG) will develop the following on the Recommendation Track:<br />
* Pineapple picking and handling, <br />
and the following on the Continuous Publication Track,<br />
* Olive picking, pitting, curing and bottling; in the Github Repo (URL goes here)<br />
** The ES spec for Olive picking will have an IPR snapshot every 12 months.<br />
** While the Olive picking spec is on the Continuous Publication Track, it is intended that after 4.7 years, a snapshot will be taken to Recommendation.<br />
<br />
For a feature to be considered final by the working group (on either track):<br />
* it must be testable by a test in the Agricultural Products Test (APT) suite at (URL goes here)<br />
* there must be at least 3 complete implementations<br />
* at least 2 of those implementations must pass the applicable APT tests<br />
* at least 1 of those implementations generates packed olives, and at least one uses packed olives, and they interoperate<br />
<br />
Features that do not meet these requirements will be integrated first as provisional, and a second Pull Request made to change them to non-provisional, when the requirements are met.<br />
<br />
= Sample Document Header =<br />
<br />
Olive picking, pitting, curing and bottling.<br />
<br />
W3C Evergreen Standard 15 March 55BCE<br />
<br />
'''Latest version''': (URL to the evergreen standard goes here)<br />
<br />
'''Permanent link to this version''': (URL for this exact version goes here)<br />
<br />
'''Repository''': (URL to the Github repository for issues etc.)<br />
<br />
'''Editors''': (Editors listed by name)<br />
<br />
'''Current unresolved Patent Licensing Exclusions''': none, or a URL to the exclusion plus a URL to the PAG information<br />
<br />
'''Current unresolved Formal Objections''': none, or a URL to the Formal Objection filing<br />
<br />
'''Abstract''': (as usual)<br />
<br />
'''Status of this document''': <br />
<br />
This document is developed by the (link to Working Group). Comments and issues are welcomed and should be filed at the (URL to the issues page of the Github repository). <br />
<br />
This document was produced by a group operating under the W3C [https://www.w3.org/wiki/Living_Standards Continuous Publication] process and policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with [https://www.w3.org/Consortium/Patent-Policy-20170801/#sec-Disclosure section 6 of the W3C Patent Policy].<br />
<br />
The disclosure obligations of the Participants of this group are described in the Working Group charter.<br />
<br />
= Detailed explanation of the Continuous Track Patent policy =<br />
<br />
Looking for input from PSIG.<br />
<br />
= Summaries for various constituencies =<br />
<br />
== Lawyers ==<br />
<br />
(needs editing to match the snapshot model)<br />
<br />
Lawyers will need to take roughly the following steps:<br />
* Review the charters of the working groups that your organization intends to participate in. <br />
* Collect, from the charters, the URLs of the Continuous Publication repositories and add them to your 'watch list'.<br />
* When you join a working group, review the most recent snapshot and file any applicable exclusions, within the deadline.<br />
* When snapshots are made, review it and file any applicable exclusions, within the deadline.<br />
* Watch other exclusion filings, of course; take any steps you think indicated, and consider joining the PAG.<br />
* Optionally, if you want early notification of changes, watch the monthly automated reports of Pull Requests, or get automated immediate notification by GitHub of Pull Requests, for repositories in your watch list.<br />
* When you leave a working group, do a final exclusion check on the working draft that was current as of the time you left the group.<br />
<br />
== Working Groups ==<br />
<br />
Working groups need to do the following:<br />
* Create Github repositories for your documents on the Continuous Publication track before writing your charter.<br />
* Define clearly in your charter the documents on the Continuous Publication track; list the URIs of their repositories.<br />
* Define clearly in your charter what requirements a feature must meet to be considered acceptable (testing, implementation, interop, etc.).<br />
* Watch Pull Requests and make sure:<br />
** that Pull Requests are correctly tagged (editorial, minor, or, by default, substantive);<br />
** that if Pull Requests add to 'core draft' (ie. material that is not an erratum report, provisional, or editor's note) that the addition meets the WG requirements (testing, implementation, interop, etc.).<br />
* Watch issue filings and tag those also.<br />
<br />
== Editors == <br />
<br />
Editors need to make sure that material that is provisional, an erratum report, or an editor's note, is correctly tagged, and that tags are removed when the material becomes final. If a new feature is too complex to be inserted inline as provisional, manage separate "editor's drafts" that the WG can review until such time as they agree to merging. Check that the 'core draft' reads correctly as well as checking the entire document.<br />
<br />
If there have been any technical changes since the last snapshot, make a new snapshot no later than 180 days after the last one.<br />
<br />
== Other Groups ==<br />
<br />
Read the automated reports and review the changes as they happen. File an issue with at most 180 days if there is a problem. Raise a Formal Objection, ideally within 180 days, if impasse is reached so that Chairs can facilitate a discussion and (if necessary) the Director can get involved if needed to resolve disagreement.<br />
<br />
== Team == <br />
<br />
The team:<br />
* makes sure the process is followed, Charters are correctly drafted, etc.<br />
* makes sure that the Pull Requests (and issues) are tagged correctly, and that technical changes meet the charter requirements;<br />
* makes sure that snapshots are made if technical changes have occurred since the last snapshot, and 180 days are about to elapse;<br />
* ensures that the comments from outside the WG are given due and timely consideration by the WG (notably, within the six months tacit acceptance period);<br />
* when an exclusion is filed, the PAG is formed, notifications sent, and the document header updated (and removed when the PAG is completed);<br />
* when a Formal Objection is filed, notifications sent, and the document header updated (and removed when the Formal Objection is resolved).<br />
<br />
= Comparison of the Continuous and Traditional Recommendation Tracks =<br />
<br />
{| class="wikitable"<br />
|-<br />
! Concept !! Continuous !! Traditional<br />
|-<br />
| wide review || Incremental, by automatic notification and lack of objection || On Transitions<br />
|-<br />
| horizontal review (i18n, a11y, security, privacy, perf, device independence, TAG, etc.) || Incremental, by automatic notification and lack of objection || On Transitions<br />
|-<br />
| Advisory Committee review || Incremental, by automatic notification and lack of objection || On Transitions<br />
|-<br />
| tests || Defined in charter, verified by WG and reviewers incrementally || Defined in charter, verified by WG and reviewers on transitions<br />
|-<br />
| issues addressed || Verified incrementally || Verified on transitions<br />
|-<br />
| IP || Whole spec from all WG members given exclusion opportunity at a snapshot || Whole spec from all WG members at Rec<br />
|-<br />
| consensus || verified continuously || verified at transitions etc.<br />
|-<br />
| errata || In issues and possibly inline || Not well handled; in issues or possible erratum document<br />
|-<br />
| maintenance || Ongoing || Episodic<br />
|-<br />
| use cases || In charter or requirements document (which may also be Continuous) || In charter or Wiki or somewhere<br />
|-<br />
| requirements || In charter or requirements document (which may also be Continuous) || In charter or Wiki or somewhere<br />
|-<br />
| implementation commitments || Requirements defined by charter || Requirements defined by charter<br />
|-<br />
| implementation experience || Requirements defined by charter || Requirements defined by charter<br />
|-<br />
| Director's approval || Incremental, tacit unless objections raised || On transitions<br />
|-<br />
| Appeal process || After Formal Objection || After Formal Objection<br />
|-<br />
| stable reference || By using specific revision references or periodic Rec snapshots || Normal<br />
|-<br />
| adoption || Requirements defined by charter || Requirements defined by charter<br />
|-<br />
| status duration || Indefinite || Indefinite<br />
|}</div>Plehegar