Change default Origin Trial assumption?

[Glen Robertson]

Hi,

Right now the default assumption in "Should you run an origin trial?" seems to be that an OT is not run when adding a feature, unless the feature meets particular criteria. This doesn't seem to match the expectation of Blink owners.

I think it would be helpful to update the doc to make it the default assumption that an OT is run for all new features except in rare cases (in which case it should probably be discussed here on blink-dev to check).

WDYT? I can send a CL to update the doc if it sounds reasonable.

-Glen

[Yoav Weiss]

I don't think there's currently an assumption that everything runs through an OT, unless some criteria are met. I actually find the documentation to match my thinking.

Do you have examples to the contrary, where an OT was required by default?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPV%2BSg_%3DzEGo-CbkUTY-i3qJ1NP3yD_4S0zuJXJ_%3D7ZHEnYmNA%40mail.gmail.com.

[Glen Robertson]

Not required, but certainly preferred/expected. I was thinking of the comments on the recent note_taking new_note_url I2S.

The feedback there seemed to be, even for a simple small manifest addition with developer interest, that an OT would have been preferred to get more developer signals/feedback.

To me that seems at odds with the advice in the documentation, and the confusion there (deciding whether an OT was needed) was more problematic than actually running an OT would be!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWm-e%3Dmp2NosY%3DfWcjrDgjAJ038JMkCrNoJOLVxt4Jt7Q%40mail.gmail.com.

[Yoav Weiss]

Maybe +Alex Russell can chime in with his thoughts on that front.

I read his comment as saying that since we didn't get a ton of feedback (from a WG, other vendors or developers), an OT would've been a good mechanism to get such feedback from the latter group. And while the risk for this specific feature is small, it might be worthwhile for future, similar additions. That (to me) is not the same as saying "an OT is expected by default", but is more "we need to make sure we got feedback on the API".

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPV%2BSg_WuNXQO4hmKe1M7hyTmpCdfJBrPO%3DoNAxSEhsdmPr5wA%40mail.gmail.com.

[Glen Robertson]

Hmm, in my (admittedly very limited so far!) experience, it is rare to get much feedback from developers on APIs before the OT stage. Maybe I need to get better at publicity!

If we need feedback (I agree we do) and OT is the best way to get feedback, it sounds almost like a recommendation to default to running an OT.

I'm keen to hear Alex's take on this!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWT39qoWhU%3Dp7QbuVobfYCZQB2hmeNnRYUzR2Ao98bsRQ%40mail.gmail.com.

[Domenic Denicola]

On Wed, Sep 1, 2021 at 3:53 AM Glen Robertson <gle...@chromium.org> wrote:

Hmm, in my (admittedly very limited so far!) experience, it is rare to get much feedback from developers on APIs before the OT stage. Maybe I need to get better at publicity!

If we need feedback (I agree we do) and OT is the best way to get feedback, it sounds almost like a recommendation to default to running an OT.

In my experience this kind of flow ends up being a bit backward. Ideally you have feedback from developers asking you to solve a problem; you propose and implement an API to do so; and then those same developers tell you "yes, this is a good solution". Violà, developer feedback!

This only requires an OT if the API is sufficiently tricky that the developers in question cannot evaluate it without deploying to production. But in most cases, such developers can give this feedback based on prototyping with the feature behind a flag. Or in very simple cases (like, a single manifest field addition?) by just reading the docs.

In contrast, building something that is not driven by developer feedback, but instead is solving a problem you identified without developer help, can be quite risky. In the past I've done this, and even went as far as running an origin trial in the hopes that doing so would generate feedback from some as-yet-unidentified set of developers. It didn't work out; the origin trial got zero feedback and the API ended up never launching.

I hope this helps!

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPV%2BSg-%2B%3D5MBe5k9ZwU2733BhgmL9yU6O47tr6V84KUMEbXqbQ%40mail.gmail.com.

[Glen Robertson]

Hmm, perhaps the experience is a bit unique then for us on ChromeOS - we often are asked to solve a problem for first-party or partner developers, which doesn't generate any public evidence of support/interest/feedback, so we need to find interested 3rd party developers as well.

Perhaps the best approach would be to convince those first-party or partner developers to express more public support or feedback?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra95Z7ccCOxqmPv%2BUtrEWarUJV3a7LtF5t-XotAydkhsZg%40mail.gmail.com.

[Yoav Weiss]

Partner developers are developers. Getting a public signal from them as part of the intent process is definitely useful.