Blink Shipping Process

[atanassov]

Hello TAG!

I'm requesting a TAG review of the Blink Process for Launching Features to the Web.

Given how closely we, TAG, work with teams from the Blink and Chromium community it will be great to review their process and consider if there are ways we could work more efficiently together.

• Explainer¹ (minimally containing user needs and example code): https://www.chromium.org/blink/launching-features
• Primary contacts (and their relationship to the specification):
  • Alex Russel @slightlyoff, Google
  • Chris Wilson @cwilso, Google
  • Chris Harrelson @chrishtr, Google
• Organization(s)/project(s) driving the specification: Google, Chromium
• Key pieces of existing multi-stakeholder review or discussion of this specification: N/A
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): N/A

Further details:

• I have reviewed the TAG's API Design Principles
• Relevant time constraints or deadlines: none
• The group where the work on this specification is currently being done:
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue):
• Major unresolved issues with or opposition to this specification:
• This work is being funded by:

We'd prefer the TAG provide feedback as (please delete all but the desired option):
💬 leave review feedback as a comment in this issue

[cwilso]

We're actually working on an update to the process, and it would be best to focus on that rather than what's on the page today.

[alice]

@cwilso Sure, should we wait? Or is there a draft you'd like us to look at?

[tomayac]

I'm requesting a TAG review of the Blink Process for Lunching Features to the Web.

@atanassov Rather hilarious typo :-) The TAG eats our launch process not for breakfast, but for lunch…

s/Lunching/Launching/

[atanassov]

@cwilso are we getting closer to review the new updates to the process?

[cwilso]

Yes! Sorry, got distracted and forgot to update this issue. We pushed the process live last week - the documentation at https://sites.google.com/a/chromium.org/dev/blink/launching-features has been updated. The "New Feature Incubation" section of this page is probably the most interesting/relevant here (the rest of the types of features are largely less controversial).

I'm happy to sit in on a live discussion if a Q&A would be helpful to the TAG, or answer questions asynchronously.

[cwilso]

I presume from the milestones you've been internally discussing; maybe it would be useful to have an interactive discussion?

[plinss]

Yes, we plan on inviting you to a call in the near future.

[atanassov]

We had a chance to review and discuss the Blink process during few of our breakouts. The following is a summary of our discussions.

In general we feel that the TAG review expectations from the Blink side can be summarized as:
(A) Be useful
(B) Not delay or block the Blink product schedules

From TAG's side, we want to feel like:
(C) TAG reviews can be impactful
(D) TAG reviews are not perceived as rubber-stamping

To that effect we think that moving the start of TAG reviews from step 3 to step 2 could help with (C), and moving completion of the review from step 6 to step 4 may help with (D).

We do want TAG reviews to be able to be completed in a timely manner and at high quality. Having an explicit exit criteria for each step of the Blink shipping process can help a lot. For example, step 3 is supposed to be an iteration step, right?

Another missing point from the process is calling out polyfills. More often, polyfills are used for incubation and that's when/where most technical discoveries and decisions are made. There is a missed chance for TAG to engage here and what's worse is that such features get easily adopted and become de facto standards/expectations.

Another observation is that most of TAG's engagement and feedback comes a bit too late in the process. In turn, the feedback is harder to accept since ideas are closer to solutions that are sometimes ready to adopt and ship. One idea that seems to have good traction with TAG is to introduce an early stage review (let's call it Ideas Review for now). This stage should be very lightweight and time-bound in terms of TAG review turnaround (say 2 weeks turnaround time or consider accepted). In order to meet such time expectations we would expect explainers to be short and easy to review. During idea-reviews we will have a chance to look for general platform consistency, best venues for said ideas as well as spot any prior-art lessons we can suggest to authors so they can get familiar with before moving to design.

@cwilso, happy to get together and discuss these during one of our plenary sessions or continue here, let us know.

[cwilso]

Yeesh, I somehow completely missed the notification on this response, sorry.

I think your (C) and (D) are completely reasonable, and I share those goals. On (A), of course we want the reviews to be useful, which is part of what pushed them later in the steps (when the ideas are better baked, rather than just a collection of use cases - please note that there is a definite goal of getting the Chromium process to encourage early engagement with the community, rather than waiting to drop a fully-formed idea of an API on the public community's plate. (Another way to read this is "the old de facto process was frequently well into prototyping (mid-late step 2) before it got announced publicly.)

The motivation for TAG review request being at the start of step 3 is that the entry to step 2 ideally doesn't have a design yet - you would be requesting a TAG review on a design that doesn't accomplish the goals, or is missing significant pieces. I'd already planned for if the TAG wants to be engaged when the ideas are first coming up, we can easily hook that in - we already have notification (at least in most cases) via the incubation path (the latter part of step 1 drives a WICG proposal, which will send new-incubation-repo notifications to [email protected], which we could ensure is more systematic). I think that's a different request than the "there is a fleshed-out design that should achieve the goals, could you take a look" review, and that's probably what having a discussion would be good for.

The reason TAG review is mentioned in step 6, not step 4, BTW, is because it's a completion - if you haven't gotten a TAG review and responded to the feedback by the time you send an intent-to-ship, the API owners are going to be looking very askance. Perhaps it would be a good idea for me to add an explicit "you should really be wrapping up your TAG review!" to step 4?

If you have some time to discuss during your next plenary session, let me know (preferably not between 3 and 6 AM in Pacific time. :P )

The exit criteria for each step are captured in the Chromestatus tool, and

[plinss]

Hi Chris, thanks for the feedback. Can you join us for our plenary meeting on November 11th? The exact time of day may change as we adjust our scheduling for the DST change, but we're currently scheduled for noon Pacific (we'll keep it a PST friendly time if it moves).

[cwilso]

Sure! It would better for me if it were NOT between 12pm and 2pm on November 11th (I have a contractor doing work in my house at that time), but I could make it work either way.

[cwilso]

I left a sentence fragment above, completed my thought below:

The exit criteria for each step are captured in the Chromestatus tool, and the goal is to encourage earlier asking-for-review and notification steps, while not delaying progress (but explicitly asking for response to all review issues at appropriate times).

[cwilso]

Gahh! I am so sorry, I didn't know when I was supposed to show up, and I think I missed it. My deep apologies; if we can get back on the calendar for this discussion, let me know.

[plinss]

Hi Chris, no problem, I also neglected to send out the meeting information in a timely manner.

Our plenary meetings alternate times to be more APAC friendly, our next meeting is at 10pm PST on Tuesday the 17th, otherwise I'd recommend 12pm PST on the 25th.

[cwilso]

12pm on the 25th?

[cwilso]

Also, I gave a (short!) talk on this at BlinkOn this week: https://youtu.be/hgEyQsy1D7w.

[plinss]

12pm on the 25th works. Join us at https://meet.jit.si/w3ctag

[torgo]

Thank you @atanassov for opening this. We're going to close this as we have multiple ways in which we are communicating with Blink - e.g. liaison calls, a new label, etc... If we feel we are getting out of sync we can re-open and have further discussions.