Yep. And shipping experimental implementations can be part of that. But when you tell devs about this cool new feature, you need to emphasize that this is a *proposal*. That you want *feedback* because it may *change*. Which doesn't fit well into big corporate announce-a-thons.
-
-
Replying to @AmeliasBrain @fantasai
Announce-a-thons aside, we are consistently *begging* for more valuable and timely feedback from other vendors. If you have concrete examples of incubation work not being done in the open and requesting for feedback, I'd love to hear them
2 replies 0 retweets 5 likes -
1 reply 0 retweets 0 likes
-
Replying to @matthewcp @yoavweiss and
This is literally begging for developer feedback via Origin Trials and WICG open process: https://groups.google.com/a/chromium.org/forum/m/#!searchin/blink-dev/Isinputpending/blink-dev/ItkbDBevOrs …
2 replies 0 retweets 3 likes -
Replying to @slightlylate @yoavweiss and
There's a GitHub linked above with some feedback but little response. This is also shifting the goalpost, the *design* of the API doesn't appear to have been done in the open (again, GitHub with little comments), it was done in private meetings between FB and Google.
1 reply 0 retweets 1 like -
Replying to @matthewcp @yoavweiss and
There is no immaculate conception for web APIs. The explainer is a request for collaboration and you can shape the future of the API by engaging on GH or OT. What is objectionable about that?
2 replies 0 retweets 0 likes -
Replying to @slightlylate @matthewcp and
Lemmie try another way to describe what's going on here: Some customers (folks working on a heavily used framework) talked about a problem they had with receptive platform engineers. Together they sketched out a straw-person API...
1 reply 0 retweets 0 likes -
Replying to @slightlylate @matthewcp and
...then, they made the a doc to explain the problem and one possible solution and published it, asking for feedback is any constructive sort. Why? Because they could be wrong! It might not actually be the core problem (but rather, adjacent). It could also be the wrong design.
1 reply 0 retweets 0 likes -
Replying to @slightlylate @matthewcp and
Then, to try to understand of the design was good, they built a version based on what came out of that public debate...
1 reply 0 retweets 0 likes -
Replying to @slightlylate @matthewcp and
That process can only really tell you if the thing is *implementable*, not if it solves an important problem in a good way. And BTW, standards committees can't determine that either!...
1 reply 0 retweets 0 likes
So, they are running an experiment to find out. And it's a *real experiment*. The thesis could be disproven! Has happened to a lot of OTs.
-
-
Replying to @slightlylate @matthewcp and
This is in contrast to the old way of doing things where consensus was valued more highly than evidence. Doing design outside committee, running trials, getting feedback, and iterating are *just good feature design*. And the result should be confidence in the design.
1 reply 0 retweets 0 likes -
Replying to @slightlylate @matthewcp and
...and that confidence should be backed with data. Data that
@yoavweiss and I and other Blink API OWNERS weigh when something is proposed to ship. It's a high bar!1 reply 0 retweets 1 like - 14 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.