Meeting minutes
Pick a scribe
Reminders: code of conduct, health policies, recorded session policy
Administrative
<cwilso> Code of Conduct: https://
<cwilso> Antitrust policy: https://
cwilso: Be inclusive, and nice to other people
… if any problem, contact me or Team reps
Goal of this session
<cwilso> AB incubation intro: https://
cwilso: Goal of this session is, we've had an open conversation in AB
… finally got around to writing some thoughts about it
… What is the goal of incubation?
… wanted to have breakout session to get more perspectives
… will have more breakouts, had one at TPAC, another will be at AC
… Lots of perspectives on how incubation should work, and when incubation is done
… summarized some questions in the document
<cwilso> How should incubation work? How should an incubation group be communicating their work to a broader venue to ease acceptance as a WG deliverable?
<cwilso> How should Working Group charters refer to incubation and future work? What best practices should we define for referring to incubations? What kind of timeline for deliverables are a good idea when work migrates into a WG?
<cwilso> What expectation of incubation should there be before work is accepted into a WG, or into its charter? At what stage of "doneness" should work move from an incubation venue to a working group? How can we identify the "right" time to migrate an incubation to a WG?
<cwilso> What success criteria should there be for incubations? What defines success in this context? What happens to incubations that are successfully defined and adopted in one engine, but not picked up by any other implementers?
cwilso: I'm particularly interested in third set of questions: what is the expectations before going to WG? How do we identify the right time?
… we've seen cases where incubation is pushed into WG too son
… or we incubate for so long that by the time we move to WG, it's too baked
cwilso: Want to hear what other people think. How can the AB, as shepherd of Process etc, "incubate" this idea? :)
dom: Some discussion at earlier breakout on Web Features
… François ran analysis on which features are defined in specs still in incubation, or still in WD, that are already widely implemented
… it's a bit of an anti-pattern, because stuff gets shipped and not much room for improving them through standardization process
… When we can, systematically detecting and discussing these situations, would be good
… Systematically expose these cases, same way that transition requests are a place to systematically expose issues with reviews, implementations, or testing
… More generally, create opportunities where this *has* to be discussed by someone, reviewed by the community
… that seems like a pattern worth investigating
bkardell_: There's a problem that's the same regardles of what kind of incubation is
… I have experienced a few different kidns
… We had incubation for 'inert', and didn't have for ':focus-visible' (just done in CSSWG)
… I'm also part of Open UI, part of WICG
<dom> minutes of web-features breakout where related data collection was presented and discussed
bkardell_: a lot happens there that winds up in WHATWG or CSSWG or some other group
… Problem I see in both cases, one of the big things that's nice about incubation is, there's not confusion that this is somehow already blessed
… nobody has agreed to spend the resources or time on it yet
… we're not sure, encourage exploration
… but exploration takes time, usually a lot of it
<cwilso> +1
bkardell_: and when it does get somewhere, it's often the result of a lot of work
… and when feedback comes back "you made a mistake in step 1", that's offputting
… especially for people who aren't used to standards process
… That's a challenge, and so we've been adapting in how soon we try to get checks
… we're figuring this out through the pain of experience
… we don't want things staying unchecked in incubation too long, even if not ready to transition yet
cwilso: To Dom's point about "incubations" getting shipped without standardization, without discussing
… tough part is when gets reviewed, exploration takes time, but review also takes time
… you don't want to create a perfectly crafted document only to have someone say "hey, your foundation is wrong"
… Today, with Chromium, the Intent process tries to make sure we get review by *someone*
… but challenge is exploration takes time, review takes time
… getting attention is challenging
… in WHATWG, we implemented "stages", taking TC39 stages and use it as a way to get attention on features earlier
… "this is semi-baked, please take a look"
… hoping that helps
cwilso: Two core problems: a) not confusion that this is blessed because "incubation"
… plenty of people actually have a problem like this, incubations ship and people say "this standard is developed at W3C"
<bkardell_> are there incubation stages, or is there a stage that it should move out of incubation into a wg?
cwilso: I've given our DevRel guidance, saying something is a standard is a very high bar
… but need to stay vigilant
… Key challenge is, who defines what "too long" is? When does it move to standardization
… If only one implementation, and don't have a second implementation lined up, should that move into standardization?
jyasskin: Listening to bkardell, some unformed ideas
… appropriate length of incubation probably depends on the feature
… some, you mention to WG or browser engines, and they say "yes that's a good idea" even if hasn't been incubated at all
… maybe should adopt to WG right away
… others need to build up support for them, and those get adopted later
… And some of them, one browser thinks is great and ships, and others disagree and refuse to adopt in WG
… These are relatively stable, but could shift if backwards-compatible change or change is worth breaking compat
… Then we have things like SOLID, multiple implementations, and already de-facto standards -- that's too late
… but we also need to make a strategy to deal with it
<cwilso> +1
jyasskin: because people will make mistakes in both directions
<Zakim> cwilso, you wanted to react to jyasskin
jyasskin: cwilso's document says "here's how to do incubation" but maybe we need different categories, and expect that features in different categories can follow different paths
cwilso: Yes, it was a brain-dump document from me. It is not intended to be the One True Thing people should do.
… encourage to file issues in ab repo against this document
… I will work to refine this document
cwilso: Also, I messed up by not doing introductions!
Introductions
cwilso: Chris Wilson, Google, longtime [many things standards]
<Zakim> dom, you wanted to discuss processing time of reviews, inspiration from "intents to *" and to react on "too long" in incubation
jyasskin: Jeffrey Yasskin, co-lead Web Standards Team with Chris
dom: Dominique Hazael-Massieu, W3C Team
Continuing the dicussion
dom: [missed]
… suppose we have a monitoring script that watches features in incubation, and if a feature is implemented in two different engines
… and it asks the spec editor what are their plans for standardization?
… doesn't mean you *have* to transition to WG, but you have to document your thinking about it
… and have the community discuss and maybe change your mind
… I think I like the systematicity of Intent to *
… Providing opportunities for these discussions to happen
dom: You say sometimes it's hard to know what's too long for incubation
… but something shipping in all major browsers and still in "incubation" is a failure
<cwilso> +1
dom: I agree that strength of signal can be discussed, but if every single browser ships a feature, then surely that should have gotten to a proper standardization review process earlier
<Zakim> csarven, you wanted to comment on implementation experience
csarven: Sarven, working on social web stuff for 10+ years, most recently in SOLID (since 2015) and also Social Web WG
csarven: I've been chair of SOLID since 2019, recently transferred to new individuals
<cwilso> WHATWG Stages reference, BTW: https://
csarven: the work in the CG, we started in 2018
<jyasskin> Sorry for mischaracterizing the details of Solid.
csarven: to characterize implementation work... it's important for WGs and CGs
… often there are different ways of designing something
… and a group could slap something together and say "it's done, ready for WG"
… but personally find that's not a strong indicator, just because spec seems ready is fit for WG
… the language or type of things that Process outlines on adequate implementations applies also to CGs
… Question about how should CG communicate incubation to ??
… When chartering, look at incubation experience that a group has shows a lot about how mature that work is
… it doesn't need to be flawless, every detail covered, doesn't leave much room to improve
… but signal that the group didn't just write a document and think this is fit for the world or the wild
… There should be a lot of experimentation, should be fit enough that people are using it e.g. themselves
… IndieWeb has a good view: build what you need, and use it, then you know it's real
… That's a stronger signal than the spec itself.
… Developing something that's real enough.
bkardell_: Part of reason we're here is, there are examples of specs that have words that aren't implemented anywhere, and show no indication they will be anytime soon
… and stuff that's mostly interoperably implemented that isn't in a WG, e.g. subset of Web Speech
… that happened in incubation early on, in CG
… eventually got to where everyone had an implementation
<dom> in an ... Incubator Group as they were called :)
bkardell_: and third classification, there's an interoperable subset, and there are some words, but doesn't really reflect reality of what's implemented or not implemented
… That's where Web Speech is, and where MathML was
… Sometimes writing those things is difficult, because they were built without a mind towards how the Web Platform really works
… need to bring people back to drawing board a bit
… How do you have checkpoints that allow people to use time effectively, and also respectful of other people?
… In CSSWG, occasionally suggest incubation. Most things picked up by CSSWG early, and occasionally push things to incubation
… but many times pick up things to spec that aren't ready to be implemented
bkardell_: We've tried many things, Chrome Status, etc. But missing something that lets us gauge when it's a good time to check in
… and not over-taxing
<csarven> jyasskin No worries, am aware how it may be coming across to some depending on entry points and what not =)
<Zakim> astearns, you wanted to react to bkardell_
astearns: Alan Stearns, current co-chair of CSSWG
… I want to caution on drawing conclusions from CSSWG incubation to other things that need WGs
<dom> a possible CSS example of "incubating too long": https://
astearns: CSS is special, we have a charter that has all of CSS in scope
… new work automatically belongs to the charter
… for our internal incubation, no clear inflection point for when it becomes part of a charter or not
<Zakim> tantek, you wanted to first point out the other end of incubating too long is too little, history of specifiction RECs, second ask what does implementer/implementation "interest" mean for claiming incubation success e.g. niche implementation, intern project, open source library in isolation, user visible/usable implementation, web user-relevant implementation? and third, lag in incubated->WG started
tantek: Tantek Çelik, Mozilla AC rep, AB, and longtime CSSWG contributor, and past co-chair of Social Web WG with csarven
tantek: Buiding on what bkardell talked about, the historical problem that incubation is designed to solve
… as much as we have problem of incubating too long, old problem was no incubation at all
… so a lot of RECs that are specifiction
… outstanding exercise to go through /TR and identify RECs to obsolete
… Keep in mind that incubation was a way to try out, experiment with ideas, without having to use heavyweight mechanisms that get to REC without implementations
tantek: We talk about implementation interest: are 2 or more interested, or think it's a good idea?
… questions wrt getting to REC, thats a problem for once in WG
… but getting out of incubation
… how serious does an implementer have to be?
… if it's a random Open Source library somewhere, or does it have to be a user-downloadable implementation that they can play with?
… does it have to be a broadly usable Web impleemtnation, like browser implementation, or are niche implementations enough?
… start as pet projects or personal websites, and propose to browser?
… Idk the right answer, it's a question.
tantek: Then there's still a huge lag from "this has incubated" and "WG has started, and we can publish a WD"
… Example is the Privacy WG.
… Things that have been incubated a long time, and still don't have a WG.
… If we wait until everything is *ready*, until we're completely confident that something is done, we have to wait again before we can produce a WD
<dom> [the new FO process isn't helping keeping that lag low :/ ]
tantek: Might need to consider velocity, and start the WG chartering process earlier
… so that when it's incubated, the specification work can start within weeks rather than many months
fantasai: I agree with Jeffrey that there are lots of categories, and we need to handle different ones differently.
<dom> who is "you" in "you should have that conversation", though?
fantasai: If you're at the point that a major implementer, even 1, is ready to ship, and you haven't had the conversation of whether it should be on the standards track, you should have that conversation. Once you deploy, it's hard to make any changes.
<bkardell_> fantasai: you mean not behind a flag, or even behind a flag?
fantasai: Once it's on the standards track, you get broader review, engagement, before it's locked down. Don't wait until 2 implementations are ready before moving to WG.
… Once they're ready, they're impatient. Shift earlier.
<Zakim> jyasskin, you wanted to speculate about template "reports" for incubation groups to produce and update as they repeatedly propose that a WG adopt their stuff
jyasskin: TAG produced a template-explainer to help build explainer documents, to make it easier for them to review proposals
… those are good output for incubations
… I suspect this implementation report is a good output to inform AC of whether something is ready to be chartered
… maybe one output of AB's incubation effort is such templates
… incubations, instead of asking "are we completely finished", should be asking their constitutency -- AC, engines, whoever -- "is this ready, do you support this?"
… if no, then keep going and try to answer questions in the next version of their documents
… but always have this proposal ready, so that if notice that ready to adopt to WG, then ready
… Asking is good, can inform the next version of the documents
cwilso: By end of incubation, you may have one subcommunity that supports the feature/area. But goal of moving into full standardization track is to build consensus across the *entire* Web community
… Everyone has to buy into this is a problem worth solving, and this is the right solution.
… Btw, I'm also on WHATWG Steering Group and wrote up the Stages document
… Stages are checkpoints
… but to take off many of my hats... WHATWG is purposefully engine-controlled
<jyasskin> WHATWG Stages: https://
cwilso: it's a requirement for 2 engines to be interested
… requires browser engines to buy into something, that it's incubated enough, to move to standardization track
… I do believe absolutely that we should make sure that when anyone tries to ship anything, reviews we do internally, make sure we've had that conversation
… and if that conversation is still ongoing, we try not to ship something where the conversation is still ongoing
… but challenge is when we can't get that attention
… we have a community that wants to solve the problem, but can't get engines' attention
… we've incubated as far as we can, but no attention... do we move it into a WG?
… let it sit for a decade?
… I'm not positive if that's right or wrong
… We may need to have features that do sit in a WG, on a real standardization track, for longer
<Zakim> tantek, you wanted to react to cwilso to respond to fantasai, no one is proposing 2+ implementations for "being incubated", key is prototype + interest and to also respond to cwilso, should it be the entire "web community"? should W3C not pursue "niche" web standards? like is/was Social Web niche when we did it? Is ActivityPub still niche?
<cwilso> s/cabal/vendors/
tantek: I don't think anyone proposes that we need 2+ implementations to exit incubation
… but *interest*
… if multiple implementers are interested, and hopefully a prototype, then good to land into a WG and iterate there
… may or may not reach success criteria; ok to fail
… but successful incubation isn't about multiple implementations, but interest from multiple implementations
<fantasai> +1 tantek
<cwilso> +1 that if you have two implementers in rough consensus, you're probably ready to move into REC track; but the question is if the community is only one implementer+others
dom: I like the idea of a process explainer for incubation, not just the technical piece but the standardization story
dom: wrt categorizations, some seem like no-brainer, e.g. 3 implementations and still incubation you're wrong
… but there are grayer zones
… different categories have different tradeoffs
<jyasskin> I'd say that the incubation has made a mistake rather than being "wrong". Nobody intends to stay in incubation with 3 shipping implementation; it just happens. :)
dom: Tantek's point about implementation interest, sometimes interest is note expressed... some implementations don't want to express themselves
<cwilso> +1 (that's kind of what we do in https://
dom: but the more less-gray zones we can map out, but leave only the hard cases for discussion, it will be easier to move forward on this topic
plh: To me, it's very important that we enable the Web to move forward
… when it comes to incubation, I tell ppl, a good idea can come from a big company or a single individual I pass in the street
… I don't trust companies, I trust people
… it's important that we don't put too many hoops into allowing people to push their ideas forward
… the JSON format, they didn't wait for standardization to be successful, that came much later after their success on the web
<bkardell_> some might argue html and http too :)
plh: when an API has to be implemented in browsers, that requires a different bar than a data format to use on the Web
<jyasskin> +1
plh: we can argue at length about success of TTML, for example
… It's not implemented in Web browsers.
… similar arguments about ActivityPub
… They all have different notions of what success is.
… We have to be very careful when we set bars, because one-size-fits-all won't help the Web move forward
<Zakim> tantek, you wanted to respond to cwilso, should it be the entire "web community"? should W3C not pursue "niche" web standards? like is/was Social Web niche when we did it? Is ActivityPub still niche?
<dom> [maybe incubated proposals should document their "incubation exit criteria"?]
tantek: Continuing the thread from plh, and cwilso's comment about getting the Web community behind something for it to move forward
… should W3C encourage niche standards?
… wide variety of opinions
… "if not across Web, not in a browser or search engine, not belong at W3C"
… or
… "if it has anything to do with Web, then belongs at W3C"
… There have been arguments in both directions, and examples of too far in each direction
… ActivityPub, Social Web WG was mostly Invited Experts, and a few company reps but not implementers
… was that a niche standard?
… if you look at implementations and number of users, can argue it's not niche anymore
… and has major implementers now
… if you bring to today, can look at BlueSky, developed by single organization and now has multiple implementations that are starting to interoperate
… They don't seem interested in W3C standardization
… Flip side we have SOLID
… Which is good? How do we assess what Web community is interested in? I don't have answers.
plh: Wrt standardize niche or not, Automotive WG wasn't closed down because it was niche -- there are many automobiles around the world.
… but closed because not ready to integrate with Web. Might re-open later, might take a few years.
… When you talk about niche, could represent millions of people
… We haven't tried to standardize MusicML because it's niche!
… But music is important to many people
… Web is so big, very easy to be a niche, unless you address millions of people
cwilso: Thanks for the conversation, good ideas like Process explainer
<tantek> what are our next steps cwilso?
cwilso: encourage everyone to follow work in the Advisory Board
<tantek> for folks here and interested in advancing incubation
cwilso: will continue to raise to the Membership
<csarven> I don't know.. working on web standards is kinda niche =)
cwilso: guidance for doing incubations, right steps for moving into real charter
… I don't know that we have enough of a handle on what goes into Process, guidance for Team
<tantek> csarven 😆 too true
cwilso: I would encourage to file issues in AB-memberonly repo
cwilso: Thanks for showing up!