Shipping features without consensus

[Brad Lassey]

Hi folks,

I've been giving some thought to the concerns around shipping web APIs without consensus. As I understand it, the central concern is how to handle the case where consensus is generated but it is different than the thing we shipped. To that end, I'm wondering if, when we have an intent to ship for a feature that lacks consensus, we should have a plan for how to "unship" it and/or migrate to a new undefined API that accomplishes the same use cases. Thinking through and documenting that plan might help us design APIs that can be migrated more easily and it would also demonstrate a commitment to eventually achieving consensus with the broader community. I'll note that such plans would probably vary greatly between APIs, but that by documenting those plans we could generate some best practices of how to ship such things responsibly.

WDYT?

-Brad

[Daniel Bratell]

I am not sure I follow. Possibly there is some previous discussion I've missed, but what arena are we talking about?

Consensus among vendors, spec maintainers, the blink community or Blink API Owners?

If it's about how specifications can keep changing after the the initial shipping, I only think that has to be handled on a case by case basis. It's unfortunate that a v1.0 spec is sometimes incompatible than a shipped v0.9 implementation, but it's a risk the first implementer takes and changing into v1.0 needs to be handled as any other modification of the public API surface IMO.

Several of the steps in the shipping process is there to prevent unexpected surprises post-launch, but sometimes going first means showing others how not to do and backtracking.

If this was about something else, then this was just a random statement. :)

/Daniel

/Daniel

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CALjsk146k%2BhKrynRYo%2ByGq-WogPZSdARFsv4fvrPgLC%3DOaVY6w%40mail.gmail.com.

[Brad Lassey]

Thanks Daniel,

Some answers in-line

On Mon, Sep 20, 2021 at 11:19 AM Daniel Bratell <brat...@gmail.com> wrote:

I am not sure I follow. Possibly there is some previous discussion I've missed, but what arena are we talking about?

Consensus among vendors, spec maintainers, the blink community or Blink API Owners?

I'm referring specifically to a lack of consensus among vendors and in particular to the cases where one vendor, such as Chrome, is looking to ship an API that no other vendor has really engaged on.

If it's about how specifications can keep changing after the the initial shipping, I only think that has to be handled on a case by case basis. It's unfortunate that a v1.0 spec is sometimes incompatible than a shipped v0.9 implementation, but it's a risk the first implementer takes and changing into v1.0 needs to be handled as any other modification of the public API surface IMO.

Several of the steps in the shipping process is there to prevent unexpected surprises post-launch, but sometimes going first means showing others how not to do and backtracking.

I tend to agree, but what I'm suggesting is that when we're in the situation of "going first" we should put some thought into how we can safely and reliably backtrack.  

-Brad

[Mike Taylor]

From the perspective of having to deal with compat fallout for a less well-tested browser in a former life, I think this is a good idea.

One example that comes to mind is WebRTC "unified plan" vs "plan b". I wasn't involved in any of the decision making there, and probably lack a lot of context on the complexity of switching over - but my team got to deal with top sites not supporting Firefox for years, and having to ping folks via back-channels to try to understand what Chrome's plans were. I think having a public plan - even if imperfect - would have been useful especially when communicating with partner sites.

[Chris Harrelson]

Hi Brad,

The API owners discussed your proposal at the meeting yesterday, but we only got partway through the discussion... We'll continue again next week.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/dd777fb8-b61d-8d3b-5369-833cd1d5635f%40chromium.org.

[Chris Harrelson]

I have an update! There was one (brief) API owners discussion soon after my Sep 24 email, and then everyone got really busy for a while. But I did follow up recently with Brad and others, and have a refined proposal, which is below. 

Here is my rationale for the suggested section quoted below: the goal is to encourage intent owners to, when shipping features, design it in ways that anticipates future changes to the API. The reasons could include changes made as a feature receives additional implementer interest or during subsequent standardization steps (the situation Brad mentioned in his original email). And it could also include other causes, such as generalizing a feature to additional use cases, and feedback from developers when it's deployed at scale. Such designs will hopefully make it easier to change the API than it would have been otherwise.

Second point: this section does not require an intent owner to agree to any future change in advance. However, an interoperable and open-standards web is already a value of Blink, and implicit in all the checks that go into the intent process. I also believe that interop is a process and a goal, and one that is achieved over time, not all-at-once. I think it goes without saying that Blink and the API owners encourage everyone to do things that increase interop and openness of the web platform, and that includes potential changes after a feature has first shipped.

What do you all think?

---

Blink Process Change: new section in the intent-to-ship questionnaire, as described below:

Plan for future interoperability

Please document a plan for adapting your feature to ensure interoperability with other implementers if the specification evolves. In particular, what steps have been taken in the API design that make it flexible to changes in the future?

As much as you can, connect the answers back to any critical feedback received so far from participants in the standards discussion.

Examples include:
* “we put options in a dictionary of properties rather than a single boolean in the following places”
* “context creation is versioned, enabling new versions to return a different object”
* “we designed the API as a progressive enhancement that won’t break sites if removed or renamed

[Rick Byers]

Thanks Chris! While I know developers already find the form a little overwhelming and so we want to keep the questions to the bare minimum, but I agree that this is worth adding for the reasons you cite. 

I wonder if perhaps we should mention something about ongoing or potential future standardization venues in the examples? For example, I think the experience with scroll anchoring has some properties we'd want to encourage following. IIRC we presented it to the CSSWG fairly early on, but there wasn't any interest from other implementers so we shipped based on a WICG spec, with an occasional update discussed at CSSWG. Once it had been in Chrome for a while and people saw how it led to a meaningfully better user experience, other implementers became interested and asked for it to be migrated to CSSWG, which we did while investing to improve it based on the experience from a second implementation. So perhaps an example we could add would be "This feature has been discussed in the CSSWG but currently lacks multi-implementor interest in that venue. We're willing to continue development of this spec in CSSWG if such interest materializes in the future". 

Rick

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CA%2BN6QZuEzxYddUOfFQFpTw%2B6pEGHYc6vuxPX7wmCLP21EBegeg%40mail.gmail.com.

[Daniel Bratell]

We talked a bit about this on the API Owners meeting but as I was rudely kicked before I had finished talking ("Out of memory" so maybe a Google Meets memory leak?), I'll dump my thoughts here: :)

* Lots written here and suggested is valuable and useful, and good to consider when you design and ship APIs. I want people to at least think about how an API may evolve (or devolve) before putting it in stone.

* I think that it may be ok to ship an API that is hard to extend or change or unship. There may be other considerations (performance, ease of use, ...) that makes it something worth shipping and that takes priority.

* The current Intent process has quite a few form fields to fill, and we have heard or noticed that some are already not fully understood or filled in, and I don't want to add another step if it doesn't add any direct value.

Obviously these three opinion items are not 100% compatible with each other.

As some people said, this is most valuable when we have negative or no signals from other vendors and web developers so maybe it could be an optional step only relevant/active/shown when that is the case.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAFUtAY9wPj17cgsdqLwK5xZBo4DjEY65%2BHmj7X-VqLc2bWJ7%2Bg%40mail.gmail.com.

[Alex Russell]

Hey all,

We discussed this at some length at today's API OWNERS.

My personal view is that spec evolution post-launch has two directions: breaking and compatible additions, and once you've shipped, you should be pushing suuuuper hard into the second vein and avoiding the first. The OWNERS stake claims to shipped behavior, and maybe we should be doing a better job about helping folks understand that you're really, really, really committed to something when we send it into the world. But that seems like more of a broadcast, or educational opportunity,  and maybe less of a question?

Our process is designed to reduce risks where we can and make them legible when they can't be eliminated. 3 LGTMs pours cement into the feature's mold, and the process is designed to make getting to that point a high bar to clear. Once it sets (gets above some usage threshold), there's no changing it.

If our ceremony and pushback isn't causing folks to be intentional given that we require TAG review, requires spec language, tests, enable OTs, etc. then maybe we should tighten those up and block more intents that aren't showing that evidence. But we have the most responsible process now, and in cases where we allow folks to move forward without consensus, it's already a rough ride.

A few other things fell out of the conversation for me about how we might improve what's unclear:

On feature developer guidance

When we know we're out ahead, it might be helpful for us to spell out explicitly for teams what the alternatives will be once they ship. They're in the process document, but we don't expect folks to become process experts.

Perhaps chromestatus.com can detect attempting to ship w/o broad support and create a short interstitial for the developer that explains that once they get LGTMs, their process options are limited to compatible additions (preferred) or full deprecations (for breaking API changes). Or maybe a note along these lines should be appended to the generated mail to the list too?

Getting the consequences in front of intent drivers at least seems worth a try.

On signposting interop "play in the joints"

Mike West flagged that there might be space in specs to better highlight existing, designed-in opportunities for vendors to make different policy choices around a single spec. Mike suggested that maybe it's a place where we can have our template spec docs include a section for designed-in areas where we expect implementations to differ in behavior (but not API)?

I've seen this cut both ways. In some designs, intentional flexibility for implementations that might want a different policy has been treated as a spec bug, even when it's giving detractors exactly the ability to change behavior in their implementations that they want. If folks want an entirely different API or (more often) haven't thought hard enough about the tradeoffs and talked enough to web developers to arrive at a similar solution as us, it seems like the best way is through (to Rick's example), responsibly.

Normalising this sort of design note might be very helpful. Curious for Mike's thoughts about what that sort of spec template change would look like in practice.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CALjsk146k%2BhKrynRYo%2ByGq-WogPZSdARFsv4fvrPgLC%3DOaVY6w%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/dd777fb8-b61d-8d3b-5369-833cd1d5635f%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.