<Ralph> CEO Update slides
<scribe> scribenick: Ian
Jeff: Welcome! Lots of attendance!
[Housekeeping]
Jeff: Please complete the feedback survey
to help us improve TPAC
... Naomi and the Keio Team were amazing at securing sponsors;
most sponsors ever.
[Slide displays all sponsor names]
Jeff: Many thanks in particular
to the Platinum Sponsors: Rakuten Institute of Technology,
Coil, NTT
... Thanks also to Gold sponsor Panasonic
... Let's thank all the sponsors!
... Please recall that all W3C meetings are guided by our Code
of Conduct
Code of Ethics and Professional Conduct
Jeff: There is a CG that is
working on a substantial revision to the code of conduct.
... Schedule for today before breakouts includes two important
topics: continuous spec development and MDN
... there is also a breakout session on Process 2020 later
today
... MDN did a developer survey to look at developer needs; W3C
participated. We think it's important for the W3C community to
hear the results, and there will be a breakout later today.
Jeff: We will finalize the
breakout grid (this year mostly done before TPAC started)
... We canceled reporting this year in favor of more breakout
time
... Tonight we have a reception on the first floor
... Some additional points for the community; we are proud of
our commitment to diversity.
... we created a diversity fund to raise money to pay expenses
for people who might not be able to attend otherwise
... In 2018 we enabled 2 people to attend.
... In 2019, under Léonie Watson's leadership, we were able to
support 7 scholarships. Many thanks to the 11 companies that
enabled that.
... we did hear that it requires time in companies to budget
for these scholarships, so for next year we will start this
effort sooner
[W3C Process]
<fantasai> Process CG mailing list https://lists.w3.org/Archives/Public/public-w3process/
Jeff: Process changes managed through the Process CG; many important changes are coming. Please see the editors' draft for what's coming
<fantasai> Process CG GitHub https://github.com/w3c/w3process/issues
Jeff: the small team that does this work is doing amazing work, but we'd like broader participation.
[TPAC 2020]
Jeff: next year's meeting 26-30 October in Vancouver, Canada
[Fantasai and Philippe Le Hégaret]
plh: Good morning and thanks for surviving TPAC so far!
Continuous Spec Development Slides
PLH: Come to the breakout session and don't hesitate to ask us questions.
[Ian does not plan to reproduce the slides by scribing PLH verbatim]
Where can the REC track be improved?
PLH: One note - patent policy commitments only solidify at REC, even though deployment happens sooner.
PLH: Use cases: Vocabularies (e.g., DCAT), mappings, registries, profiles, maintenance, enhancement, rapid development, tracking
PLH: If you are a chair and you want us to stop by your meeting let us know.
PLH: Goals include preserving important goals like consensus, wide review
PLH: Goal is to include this
evolution in Process 2020
... the current preference is to fix the Rec track rather than
create a parallel track, and to continue to incrementally
improve the Rec track
fantasai: We propose a set of fixes (which can be taken together or separately)
fantasai: Licenses are not guaranteed until Rec status. We'd like to get them sooner since specs are deployed sooner.
<florian> fantasai: each of these 6 proposals can be taken individually, but adopting them all give the most benefits
fantasai: the proposal is to
adopt a contribution model (like WhatWG and Community
Groups)
... licenses by all participants would become active at the end
of each exclusion period.
... Key Questions: Can we change patent policy? Do we need to
experiment?
Survey for AC reps on this topic
Proposed Fix: Streamlining Routine CR Update Approvals
fantasai: Updating WDs is
automatic given WG approval, but updating CR requires
Director’s Approval. Most updates, however, are routine and
don’t need much scrutiny.
... so the proposal is to allow automatic Director’s Approval
for straightforward cases
... e.g., where there is a WG decision, no objections, changes
documented, no new features, etc.
... we'd like to make this easy case automatic
Decoupling CR updates from CR review drafts
fantasai: We'd like to decouple
CR into two types of publications: (1) Updates and (2) Review
draft
... the latter would trigger Call for Exclusions and other
process checks
... this would align with how many groups operate today
... we'd like to make it easier to update CRs so that W3C
points people to the same draft developers are looking at
fantasai: We'd like to allow
groups to inline errata.
... allow in-place updates to a REC; no approval process needed
to get feedback of modifications
... let's implementers see changes are coming
... and once there is review of these inline modifications, you
can do a call for review to get a formally updated
Recommendation
... you can get review of some or all of the inline
modifications
Allow Adding Features to an Extensible REC
Fantasai: Some communities want
stable feature set, others want continuous development
... the proposal is to re-use REC maintenance process for
incorporating proposed changes (above) to also allow
incorporating proposed additions into specifications chartered
to be extensible.
... and make clear to each community what they are getting
fantasai: Registries need
lightweight update process, possible maintenance outside a
WG
... proposal is for a new type of technical report for W3C
Registries
... proposal allows for continuous updating of registry with
low overhead
... different registries may have different levels of process,
so the check is "was the expected process followed" for that
registry
... updates to registry publication that conform to registry
definition can be published instantly.
[PLH on impact]
PLH: easier maintenance, lower overhead, earlier patent commitments
[We skip]
PLH: Key is to improve tooling to help reduce cognitive load of context-switching due to ongoing changes
Impact on implementers and users
PLH: RF commitments provide more confidence, official specs reflect latest thinking, easier maintenance, granular reviews of Proposed Recs
Motivations for Alternative Track Proposal
PLH: Process CG originally tried
developing an alternative track proposal but there were
concerns
... AC more willing to change patent policy for an alternative
track
... WGs that want continuous development feel the proposal
package is insufficient.
... those are two motivations for an alternate track
“Evergreen Recommendation” Track
<florian> ^the above are hypothetical, **if** they were true, we'd need the evergreen track
PLH: We have been asking WGs and
Horizontal Review groups about value or challenges of alternate
track
... there's also a survey to the AC
https://www.w3.org/2019/Talks/TPAC/continuous-standards/#29
Questions for the AC in the survey
PLH: if you have questions, please come to our breakout session later today!
fantasai: We wanted to enable WGs
to do continuous updates at the same time as we wanted to have
checks in the process.
... for REC status we wanted to ensure wide review and
implementation experience
... the REC status is formally recognized by other
organizations, so we need to have the necessarily stability
properties
... we are trying to bring together these different
requirements: ease of work, horizontal review, stability
... and to enable both flexibility for groups as well as enough
structure to enable new (or controversy-laden) groups to manage
their work
marcosc: This is great, thanks for hearing editors! Let us know how we can help
fantasai: Please encourage AC reps to complete the survey, provide feedback and support
Jeff: I want to emphasize the
importance of AC feedback. Changing the patent policy or
process involves a lot of work. I'd like to see a lot of
enthusiasm and momentum from the membership.
... please ask your AC rep to add to the support
Dom: MDN is one of the most popular documentation portals for the Web. I am part of the effort.
Dom: Mozilla organized a survey
that involved the W3C community
... group chairs helped inform shape of survey
... today we will go over what we learned.
Kadir Topal: I am the product lead for MDN Web
Docs
... I started my career in
1997 as a Web Developer
... this is my first TPAC
... you are amazing [at making sausage]
[slide on the case of CSS Grid]
Kadir: CSS Grid was a massive
success because it addressed a real user need, was shipped by
browsers around the same time, etc.
... but CSS Grid was years in the making, and layout had been
an issue since the days of using tables for layout.
... so we had some questions: why did it take 5 years between
spec and shipping interoperably?
... what were the critical elements of moving this forward.
[Web Platform Lifecycle]
Kadir: We identified 3 distinct
phases: Research, Standardization, Adoption
... it is very simplified, of course, and looks like a pipe
even though it is more like a loop of loops in reality
... we really wanted to learn more in particular about the
research phase (developer pain points etc.)
... it's important to do more research to understand the
developer pain points
... here's what we heard about how things are
prioritized....
... and what stood out in our project was clearly that we need
to hear more the voice of developers
... it's hard to get people to adopt something if a solution
does not meet needs or does not do so in the right way
[Developer Needs Assessment]
Kadir:- Prioritized list of web designer and
developer needs
...- Published on MDN
...>- Annually published, tracking changes over
time
Kadir: This assessment is not
owned by any particular browser vendor
... We think that if we do this well, the MDN DNA can be the
voice of designers and developers working on the web
... asking these question is not trivial since the audience is
diverse and the problem space is enormous
... We formulated the survey based on interviews with
developers and designers from the beginning
... it was an outside-in process; that was really
important
... we followed a pinpoints analysis process to go from
interviews to the survey
... "Observations" -> "Insights" -> "Critical
themes"
... we transcribed 16 hours of interviews, bucketed them.
... lots of moving post-its around
... we worked with our MDN advisory board, revised the survey
to remove ambiguities
... in July 2019 we launched the final version of the
survey
... the survey was available in 8 languages
... we heard from more than 76K developers and designers over 4
weeks.
... more than 28K completes from 173 countries and almost 10K
hours of developer time
... we think this is the biggest dev/designer survey ever
conducted.
... we can slide the responses in different ways due to sample
size
[Sample Questions]
Kadir:- overall satisfaction with web
[Sample Results]
Kadir:Main question of the survey was top frustrations:
- having to support specific browsers
- outdated or inaccurate documentation for frameworks and libfrariers
- interop again: avoiding or removing a feature that doesn't work across browsers
- interop: testing across browsers
- interop: making a design look/work the same across browsers
[What are main barriers to adoption of a new feature?]
1) Interop across browsers
2) Documentation and training
3) Support for legacy browsers
[Biggest pain points for HTML dev]
- Biggest pain point cited was NONE
[Overall satisfaction]
- 76% are satisfied or very satisfied
[Applause from the room!]
[Next iteration]
Kadir: Report for first
iteration in Nov 2019, second iteration starts March 2020
... then publish next results in September 2020 in time for
TPAC 2020!
[Prioritized list of needs]
Kadir: Goal: Tool for
prioritization....
... you are the target audience (in this room), how useful to
you? What level of granularity?
Kadir: Many thanks to everyone who contributed!! I'm excited by the results and look forward to more in this space.
Glenn_Adams: You mentioned
browser vendors many times, but there are other types of
applications as well for Web technology.
... you didn't mention volunteerism in WGs, which is a key
factor in how priorities are worked out
Rick_Byers: one of our top priorities at Blink is to help developers love the web more, so I want to say I am committed to changing priorities in our team based on what you learned
Phil_Archer: Thank you for MDN!
Charles_Lapierre: I was surprised that accessibility was not listed as a top frustration.
Kadir: It is in the list of frustrations. It ended up fairly low on this list. Our interpretation is that it's more about lack of knowledge or practice
Dom: Reminder that the rest of
the day is an unconference, where the discussion is driven by
the participants
... Coralie Mercier and I have worked with the meeting planners
to make this a success
... Many TPAC attendees find this day energizing and a great
way to discover new topics
... we have been collecting breakout session proposals
Dom: participants decide which sessions they want to attend
<koalie> slides: TPAC Unconference
Dom: please ask Coralie or me questions about the day.
Dom: We changed our format from previous years based on feedback. In particular, we heard:
- Please have more breakout sessions!
Dom: so we went from 4 slots to 5 this year
- We also did more work before the meeting on the grid to avoid the "mad scramble" which was non-inclusive
- We also heard that having the schedule in a wiki was hard to read (especially on mobile)
- Also because people may be interested in more than one session, people may wish to follow some sessions by IRC. So we have IRC channels publicized in advance
Dom: We welcome your feedback on
these improvements
... We have 12 rooms and 5 slots, for 60 sessions (compared to
40-ish previously)
... however, we gave up the reporting session. We will try to
compensate for that by asking the session leads to create
written reports
... regarding gathering session proposals in advance - the
response rate was really amazing!
... that is also far more than we had received previously
before a TPAC
... my early analysis of the proposals is also that there is
more diversity in who proposed sessions.
... the agenda page is mobile-friendly so that people can
move among rooms more easily
... We have some questions!
- Should we allow more opportunity for last-minute session proposals?
- Is 60 sessions too many?
Dom: Thanks to Marie-Claire
Forgue for organizing 14 demos at the 3:30pm break. Demos from
WGs and CGs
... demos provide a great way to keep tabs on what's going on
in other parts of W3C, and to understand why and how these
technologies are being used.
... you can also discuss them with the people who are behind
the technologies.
... the demos will be set up in the break room
... Regarding final preparations:
<koalie> Demos later today
- Any last-minute adjustments?
- Proposal for the last session room?
Dom: I invite proposers to come to the front of the room to enable you to adjust the grid with minimal conflict
<koalie> agenda page
Dom: While we are doing the final
preparations, I invite other people to check out the final
agenda at 10:30 and plan to be at your first session at
11:00
... please have a look at the sessions now as I anticipate few
changes
Please also see:
Good practice for running a session
Dom: Organizers, please allow 5
minutes at the end of the session when people have to travel to
the next session
... A breakout proposer includes (1) people who already
proposed sessions (2) people who want to propose a sessoin