Minutes from TPAC's Friday session

Hey all!

Unfortunately, minutes from IRC didn't properly generate, but I managed to
manually create minutes docs (TAG discussion
<https://docs.google.com/document/d/1hPaEUaH1djp2w-A4FzMUEiylxbxHM3gvg1lUF7Tm46Q/edit?usp=sharing>,
Complex incubations
<https://docs.google.com/document/d/1L36EhPaEQ0d9k_nGBiqJDryrgqqM3eGPlBgB6PsDpgQ/edit?usp=sharing>)
from
my IRC archive. I'm posting them here for safe keeping.

*WICG/TAG discussion*
Minutes

yoav: Have seen lots of good feedback on reviews.. at the same time, devs
also not happy about latency of process.

.. priorities might be different

rbyers: From Blink perspective, we have good overlap between our process
and WICG....

... and the TAG community. Highly overlapping goals; wanting to ship,
wanting to get review...

.. have appreciated the TAG review.

.. We all want spec quality improvements.

.. Want to see more collaboration between Blink, TAG, WICG

torgo: WORDS

.. we've had a lot of design reviews. This is the TAG's "beating heart"

.. (core activity)

.. have seen success in having more design reviews coming in.

.. have over a 100 reviews

.. have new processes this year that we hope to help speed up reviews

s/100 reviews/100 reviews open right now

.. e.g., recently have started 2 person breakouts to increase throughput.

.. updates to issue template, and process too!

.. avoids lots of back/forth on access control issues, etc.

.. We are interested in talking to WICG about where the gate are or should
be.

.. TAG needs to remain responsive to our communities.

.. When talking with slightlyoff about Fugu, brainstormed priority flags as
an idea.

rbyers: our folks want to do the right thing, but often TAG review doesn't
block, so maybe not everything is high pri.

bkardell_: What's a reasonable amount of time?

.. to create an incubation, request TAG review, ship the feature...

[others] seeking clarity on question

bkardell_: e.g., creation of WICG effort; is gated already.

.. at some point this is ready for TAG review.

marcos: TAG is part of blink process.

cwilso: Not an easy question to answer.

hadleybeeman: We should separate WICG community from blink process. Not
here to sort out Blink process (not in our remit).

.. TAG may have gone too far into seeing things too early. Some of these
things may not have had sufficient review, etc. Want to find a better
balance.

cwilso: As WICG co-chair + blink guy (trying to help blink process). Blink
has asked for early TAG review...

.. maybe there are multiple levels of ask? Proposals at different stages
might need sanity-checking early vs deep review.

AmeliaBR: I'm here as Invited Expert from Web + proposal bringer.

.. some of these haven't had the review they should have had.

.. all reviews are not equal. Should breakdown the milestones of when
things are reviewed

.. lacking the open discussion of problem before solution is presented

.. not sure if TAG is best place for that review... need to have a
discussion on the problem space.

.. But that discussion needs to happen before later review stages (detailed
analysis)

.. Split out different types (granularity or other) of review.

yoav: +1 to hadleybeeman and to cwilso: could have some kind of labeling...

.. spec stage, implementer interest, when will ship...

.. could help prioritize and know what feedback is needed.

.. Feedback on problem space vs. solution. We can figure out better tools
for this.

.. to AmeliaBR: discourse discussion are in two cases:

.. 1) browser developer explainers

.. 2) Web devs with a similar idea (feature request and API shape), but
doesn't work out since it doesn't advance much

.. we actually need use cases and pain points (not necessarily proposals)

.. would love to re-vamp forum to gather use cases.

.. browsers can look there and find evidence of pain points.

.. Can even map rants in to use cases.

torgo: on use cases:

.. TAG doesn't do "ideation" of new features.

.. (TAG members might)

.. We like to see a design (in order to review)

.. TAG looks over the explainer, try to find the user need, and draw a
blank (don't see it)

Often it's phrased as a developer need

.. Would like to see "web users will benefit in this way"

.. Our feedback is sometimes in this form

.. Would love to see how this feeds back to user needs

marcosc: In general proposals come through discourse

.. not a huge problem, but could be better.

AmeliaBR: lots of the negative reaction is related to Blink proposals where
it seems like everything happens in one day! (may not be true, but it's
what it seems)

marcosc: to yoav: engineers will engineer, web devs will... uh, dev?

.. we can't ask them to not provide a solution, since that's how they think.

solution and problem often co-evolve

.. lazyload begat intersection observer... would not have found that

aboxhall_: found the process was iterative, solution to problem and back..

.. multi-stakeholder problem

.. can be hard to find the right community

.. need a small enough group to avoid going in a million directions at
once...

.. having enough diversity to get good ideas and rule out other ideas.

.. want to get things to TAG after having the multi-stakeholder discussion

scheib: See points: different review types,

.. entry to WICG not gated on TAG review (from marcosc )

.. several folks trying to use WICG to gain wider feedback

.. hoping for guidance on when things should enter WICG.

.. should TAG be involved in that or not.

.. clear understanding between TAG and WICG between developers

.. is there entrance criteria to WICG described?

yoav: Anyone can post on discourse

.. start a discussion about problem/solution

scheib: what about incubated specifications?

yoav: require interest from other parties.

https://github.com/wicg/admin#contributing-new-proposals
<https://www.google.com/url?q=https://github.com/wicg/admin%23contributing-new-proposals&sa=D&ust=1569759026905000>

yoav: looking for support from some other people in industry

scheib: Are we getting a takeaway to update the protocol for TAG reviews?

yoav: to marcosc:

.. use case description should come before solution.

.. solutions should have disclaimer saying this is our first iteration

.. perception of: "X" in title can be a trigger to many folks.

.. thread should be about problem, not solution.

marcosc: yes, absolutely. That's our job as chairs.

.. folks will ask for "X"

.. we want people to add things with zero barriers, but chairs should be
active to shape into use cases.

marcosc: I LOVE THE TAG 💘

.. may need a better process there

.. don't think that TAG review should be part of the WICG process

.. hearing from the TAG, don't bring things to us too early.

.. we give things a hear.

s/hear/year

.. some things mutate over time, then succeed.

cwilso: Have heard:

.. benefit for better framing around user benefits vs API

.. try to ensure multi-stakeholder buy-in

.. WICG is community to take things to makes me uneasy..

.. WICG is broad, want incubators to drum-up interest on their own. (does
not guarantee comments)

torgo: I do think there should some mention of TAG review in WICG process

.. the only people who have this in their process is blink

[other] and Samsung!

.. by requiring something to be in WICG before TAG review, could help our
throughput

.. but don't want to adversely impact the blink process

.. or to miss things

.. we should proceed careful

.. but want to be able to throttle back and improve design review quality.

torgo: We have a link to multi-stakeholder reviews (in our issue review
template)

.. also, where is this work being done?

.. we are tracking venues (WICG, Immersive web, etc.)

torgo: Would love to hear from WICG how TAG can help.

AmeliaBR: standards coming out of W3C not just have TAG, but also a11y,
i18n, privacy...

.. how do you incorporate those into the process?

.. e.g., when proposing a new feature, the person may not realize they need
these reviews.

.. it's harder to fix later in the process than earlier.

.. want to ensure these conversations happen earlier on.

.. people need to be looking critically at these up front

rbyers: I ack the problems I've heard in blink process; want to continue to
improve the team.l

.. maybe out of scope, but blink really values the expertise on the TAG..
would still love a forum of discussion between blink + TAG. Would love to
hear suggestions.

+1 on what Amelia said about additional wide review (beyond TAG). The TAG
does try to prompt I18N, A11Y and particularly security & privacy review
AND spec authors should also be seeking those more in depth reviews as well.

marcosc: to AmeliaBR: good (fantastic) points.

.. PING has asked to be involved earlier.

.. can add TAG into the process

.. to graduate a spec, we do have a step that asks a11y, privacy, etc. to
be considered.

.. yes we should go earlier... but incubation *is* earlier in the process.

.. some things ship as origin trials... once things start shipping (for
real) then (with Mozilla hat on) this should move into WG fast.

.. having specs is dangerous, sets expectations with folks.

.. they should just be ideas, explainers, etc.

hober: It would really help clarify WICG doc template to make it even more
clear.

.. TAG is mostly elected body, which results in TAG turnover.

.. leaves unbalanced expertise in the TAG at times.

.. want to ensure quality of review stays high... so

.. what do you think of TAG transfer to a high-expertise community? e.g.,
to CSS for a CSS feature?

cwilso, you wanted to explicitly ask if TAG thinks multi-stage review would
make the problem better or worse, or move review to later stage - "Minimum
viable API", etc.

.. could help ensure better review.

AmeliaBR: sounds good, but then need to find people to do the work...

cwilso: related question: does TAG ask for multiple types of review help?

.. TAG is uniquely suited to look at overall architecture of the platform.
I presume this is the best attribute.

.. mentioned to the AC in talk that if we try to capture minimum viable
API...

.. the design solves use cases, etc. but this is not captured.

.. (the design might actually work now)

cwilso: On horizontal review:

.. talked in i18n group, but they want to be plugged in at different times.
i18n later, and privacy earlier!

.. AB may be revising the process to help there.

hadleybeeman: to cwilso on particular review:

.. I like that; devils in details

.. we've dived deep into thinks like how promises work, and got feedback
that was not what was asked for.

.. they wanted wider integration feedback.

hadleybeeman: to tess on delegate reviews

.. we do delgate to ex-tag and particular experts.

.. e.g., when see CSS, but not reviewed by CSS, triggers concern that
review is too early.

hadleybeeman: to rbyers on blink + TAG

.. would be helpful; blink originated reviews are the majority

.. need to be sure our attention is balanced across constituencies

npm: draft specs written in WICG, which is necessary before entering a WG...

marcosc: not necessary, but common practice

npm: web perf has a different point of view. Don't think WICG should just
be for explainers.

.. I find TAG reviews useful.

.. How do we measure latency?

.. I might have unreasonable expectations... but some reviews take months
to be acknowledged?

torgo: we are trying to improve triage (be responsive to new issues)

.. so filers see that it was noticed.

.. today might get lucky if me or plinss actually adds triage to the agenda.

.. also some agreed-upon labels would be good. New spec, high-pri, etc.?

.. had new requirements for bots that can automate some of the process to
(to get back to issue creators earlier).

.. the TAG hears you.

.. do need to figure out how to throttle reviews too.

torgo: on wide review:

.. TAG created "ethical web principles" earlier this year.

.. for WICG, please look into that and consider social impact according to
that doc.

https://www.w3.org/2001/tag/doc/ethical-web-principles/
<https://www.google.com/url?q=https://www.w3.org/2001/tag/doc/ethical-web-principles/&sa=D&ust=1569759026913000>

marcosc: for the process step.. we should add review of the ethical
principles there.

marcosc: on spreading love of reviews:

.. have a pool of experts we can call on.

.. solicit volunteers.

torgo: done today, just informally

marcosc: make it formal.

.. could maintain a list, like at Mozilla does it with lists.

torgo: open to that idea!

sangwhan: on automation side:

.. I started working on automation. might make stricter reqs for filing an
issue.

.. if other folks want to be part of bot-trigger, let me know.

.. (me = sangwhan)

cwilso: will be circling back with my co-chairs, love to get TAG summary as
well.

sangwhan: we don't have a place to host it, so if anyone can sponsor a GPU..

agendum 1, TAG and incubation, closed

Complex Incubations session
Minutes

2. Best practices for complex incubation projects

Scribe: jyasskin

AmeliaBR: I proposed this topic. "Complex" incubation projects.

.. Things that are too big for WICG as currently defined. Great host for
focused proposals.

.. But lots of bigger projects that need lots of subject matter experts,
and the scope isn't a single element/attribute/API.

.. W3C has had CGs for ages for doing this, and there are lots that are
incubating specs. Some are affiliated with a WG, some independent. Don't
have a clear process for how those other CGs interact with the WICG.

.. I think the purpose of WICG is to encourage incubation as a general
process idea, in addition to hosting smaller projects.

.. But in practice, don't think there's been a lot of work making those
connections between WICG review/infra/Discourse and the other CGs.

.. Nigel Merritt isn't here but made some comments to cwilso that there's a
lot of busywork when setting up repos and transferring things. WICG should
document processes that other CGs could adopt wholesale.

.. Talked about SVG CG. Hard to get initial discussions happening, and we
should build on the WICG discourse, to get more people looking at
discussion before it moves to the CG.

.. How do you think interaction might work?

ack travis

Travis: I imagine WICG folks understand that we're not an exclusive
incubation community.

.. When personally faced with the decision of "here's a small feature;
where should I take it?", the answer comes from "which community best
serves the needs of this feature?"

.. Edit Context API: Should it go into WICG? Or where else could it go?

.. Editing TF community seemed right, so that's where it went.

.. I would love to tease out the principles of incubation and shop them to
other CGs who could apply them.

.. Not trying to monopolize incubation.

.. Finally, on business angle: this group was created because large orgs
have trouble joining a new CG because they need to ask lawyers. This one
has an appropriately large scope to reduce that friction.

ack cw

cwilso, you wanted to lay out goal of WICG and historical inception

cwilso: Want to tack on that the historical reason for the WICG is the
busywork of setting up repos, and from Adrian Bateman that when a rep joins
a CG they have to go through legal, and having one frees them from going
through legal every time they want to talk about one API.

.. Underscore that you don't have to do incubation at the WICG.

.. Conversation in the last hour concluded that we're about to end up with
lots more process.

.. Immersive Web WG has a paired CG to do incubations, and we'll want to
use the same timings as the WICG to trigger wide review.

.. Discourse: Asked yesterday whether Discourse is the right tool, because
it's a separate tool, and this is the only thing we use it for in the Web
Platform.

.. Should we use a proposals repo with issues?

ack scheib

scheib: AmeliaBR thanks for raising the topic.

.. I want to better understand negatives of using WICG for complex specs.

.. Larger projects need deep subject matter experts, and we've heard how
individual CGs have challenges. What's the downside of WICG?

.. Many new CGs are 1-1 with a WG, which keeps the subject matter
connection.

.. Maps CG coordinates outside the W3C.

Travis: Heard that "hey we're expecting a series of related specs, and the
WICG has no grouping mechanism." If you great a new organization, you get a
group to spawn multiple specs.

s/great/create/

ack yoav

yoav: Asking about discourse. What did you mean? Using Discourse as a way
to funnel input?

AmeliaBR: SVG CG trying to be like WICG for SVG things. Accept new
proposals. Ask whether something's a good idea. Find a larger community to
comment on things, rather than making people join the SVG CG to even know
that new things are being proposed.

.. Nigel's TimedText proposal shows that doing your work off in your own
community isn't a good way to get new members or make connections with
other folks doing the same thing.

.. Not about Discourse as a tool, but being connected to a larger
 community for early stage proposals.

yoav: I don't think there's a problem with incubations that start in the
WICG Discourse and then get spun out to other CGs.

.. could also have announcements or cross-post to other groups.

.. You might be overestimating the reach our Discourse currently has.

.. See if that brings you folks who aren't usually in the smaller CGs.

prushforth: IP and Lawyers: More overhead is problematic. Marcos made
categories for Web Mapping on Discourse, which was nice.

.. Intent is to bring web mapping community together with web platform
community. Hard to make people join, but nice to talk to them.

.. Talking within WICG, it's the same IP considerations as talking in the
Maps CG.

.. If they're signed up to WICG, can they contirbute to Maps CG without
joining that other group?

cwilso: IANAL. However, CGs work on a Contributor License Agreement, so you
agree to license your contributions. Commentary doesn't usually rise to
that level. So not much concern with having a conversation. On the other
hand, if they

  're signed up to WICG and then looked over and gave an API to the Maps
CG, it would need to be a Contribution, so you should ask them to join the
Maps CG.

cwilso: Patent law is an assessment of risk. Don't know if something
infringes unless you get successfully sued.

.. Ask people to sign up if they're making substantial contributions.

prushforth: Trying to get contributions and socialize ideas, so to start
the conversation, have to be where people are.

cwilso: Across the platform, we're open to saying "we have this idea, go
look at it." People can generally look without much concern. But when they
want to make substantial contributions, you should tell them to join the CG.

 AmeliaBR: Something that should be brought up with W3C lawyers. If all
major browsers are concerned about signing up to CGs. (Had this issue with
Apple.) If there's worry about the default CG license, maybe they should
create a new license that's appropriately scoped for an incubation group.
Or find a way to define the scope so it's not an issue.

Travis: Maybe make a legal umbrella for a set of CGs that are all trying to
pursue incubation.

AmeliaBR: Apple says "this line is a problem." W3C says "this line has to
be there."

cwilso: What is "appropriately scoped"?

AmeliaBR: Don't know. Find a way to make the lawyers happy.

cwilso: There's a natural tension in patent policy for royalty free
standards. You want everyone to contribute their IP without contributing
any of your own, which of course is impossible.

.. I'm pretty happy with the balance we've picked. Any company has to make
a choice to participate and have their contributions automatically licensed.

 .. There are companies that haven't joined WGs and even CGs because they
don't want to contribute their IP. It's easier in CGs because if you just
don't talk, you haven't contributed anything.

 yoav: Chris & Travis will know more since I've never dealt with lawyers in
a huge company, just very large. It's not as much about fear as much as
friction. They need to look at anything they're signing up to. Don't think
the current license is problematic, but maybe a way to expand and create a
CG umbrella that you can make licensing decisions all in one go.

 Travis: Pointing out that the W3C is taking the CG license as input to
redefining Process 2020 even for WGs.

.. Talk to the AB.

prushforth: Amelia, did you want to raise getting popularity for proofs of
concept?

.. We built a polyfill for Maps, and the standard advice is to see that get
popular, and then we talk.

.. Could spend time promoting it, but we want to get feedback so we can
iterate on it.

.. Say we have a polyfill, and the advice is to make this happen on the
Web. Then we didn't get enough feedback, but it got popular anyway.

.. Are we going to start over and fix the problems because we didn't get
enough feedback?

 AmeliaBR: Goes back to early wide review. If the WICG is building out that
process in more detail, it's important that that apply to all incubating
CGs.

 .. If you're working to get your thing widely adopted, want to ensure
you're not building a cowpath that we're going to hate to pave later.

yoav: Good point. Assuming you don't rely on backward-compatibility between
the polyfill and the future standard, we can always pave something next to
the cowpath.

AmeliaBR: Related TAG advice on not creating a polyfill that interferes
with spec iteration: https://www.w3.org/2001/tag/doc/polyfills/

 Cows on a cowpath
https://usercontent.irccloud-cdn.com/file/tRdChCjB/image.png

 .. What you're trying to get our of your polyfill ... you don't
necessarily want a polyfill, you want a userland library that lets you
better understand what devs/users want.

.. What are the missing primitives that make it hard or impossible to do
the thing you want to do?

.. The extensible web manifesto says we should address your use case with
as little magic as possible. With enough lower level primitives, you can
build your high-level components. We can build new APis that steal ideas
from the high-level components without using the same names.

prushforth: Sounds like a couple decades of work.

 AmeliaBR: Yep, that's the web.

Travis: Hard because you're proposing a markup language. Browsers are shy
about markup languages. HTML wasn't a great experience. MathML was cringy.
SVG was.

.. Other communities are more successful than markup languages.

prushforth: Markup is what makes the web the web.

Travis: Beautiful for end-users and devs to code against. Stable, not
fragile.

.. Encouraging MS folks to look at a markup language for 3D.

cwilso: Are we having a JS vs HTML discussion again?

prushforth: Web Platform is missing primitives, and those underly
high-level features. Not about disliking JS. Web Maps are JS today, and
they're great, but we want them to work better.

.. Markup brings standardized accessibility.

AmeliaBR: Think we've covered most of the agenda.

WICG/admin#78

AmeliaBR: Think we agree that supporting incubation beyond the WICG *is*
within the WICG's scope.

yoav: Depends on the amount of support. Won't hold your hand.

AmeliaBR: Write out the process so others can adopt.

.. Remind people that they can cross-post to the WICG's discourse.

.. Maybe talk to W3C about making licensing issues easier.

yoav: Two latter bullet points fall out of the WICG defining a better
process around wide review, and making that available to other CGs.

cwilso: Done with this topic.

wasserman: I'm from Google and a new member. Might discuss my work at some
point, but more wondering how to find CGs that are related to work you're
exploring.

 wasserman: Spoke with folks in Second Screen, in Webapps (sort of), got to
chat with Display Ads and Web-based Signage BG.

.. My work is centered around a gap we see, and it relates to Webapps,
Second Screen. But unclear how to be shopping the work around and finding
sponsorship in a WG or CG.

.. How does going to more specific groups relate to going to WICG.

 cwilso: Is your general question about whether you should go to WICG or
another CG/WG?

wasserman: Yeah.

cwilso: You're doing the right things. Seems like talking to Second Screen
is the right thing to do. It comes down to how *they're* doing work whether
the work should go there or somewhere else.

.. The WICG is the default for incubations, because we have process, steps.
They're about managing an arbitrary set of things. If there's already a
community that you can incubate within, that's great.

.. I chair the WebXR WG, and we have a matching CG, and we incubate
everything in the XR space there. If someone proposed something in the XR
space, I'd expect them to talk to the WebXR folks rather than just going to
the WICG.

 .. Not everything goes into the WebXR CG (there are features that go into
CSS), but lots do.

wasserman: Is there a WHATCG?

cwilso: You mean for feature that would go into HTML or DOM?

wasserman: I'm exploring why there's not a window.screens (plural). Is that
under the purview of the WHATWG, even though they don't meet here?

 cwilso: They have a different model than the incubation model. Incubations
do sometimes go into the WHATWG.

.. With that in mind, probably the right place for those features is the
WHATWG, but if they're semantically related to Second Screen, I'd go there.
There's nothing magic about the WICG.

 AmeliaBR: This reminds me of some previous conversations with cwilso. WICG
should improve the findability of existing groups and process. Should maybe
also keep a list of where you should be doing things and other CGs that do
incubation.

.. Matches previous topic of supporting other incubation groups, but also
helps people with an idea.

Travis: Yeah, if all you've heard is "WICG", but you don't see immersive
web specs, you might feel lost.

cwilso: Yeah, we should start managing that. We have a goal of not saying
"you should go here".

.. But we could suggest other possible venues.

 yoav: In the Sunday hackathon, we did a bunch of work to surface current
incubation in the WICG.

 yoav: Could split the archived from active ones, but not all active ones
are equally active. Wrote a heuristic to surface the ones that are more
recently active; need to ship it.

.. Could see it extending to "here are other CGs doing similar incubations"
on wicg.io, even if that's not in the WICG.

 .. Regarding WHATWG and the incubation models. Unfortunately, the WHATWG
is doing work in PRs, and work can stay in PRs for years. If you want to do
work that'll end up there but is relatively complex, I would start that
work in a CG and then merge it once it's in good shape.

.. I wish someone had told me that 2-3 years ago.

wasserman: Thanks for humoring me.

Travis: We're more grateful because we don't often get the fresh take on
things that your perspective provides. ❤️

cwilso: That's all we have.

.. Thanks scribes.