I'd be interested to hear of any examples where more formal governance could have helped reduce uncertainty or risk though.
-
-
Replying to @RickByers @marcosc and
Sometimes, all you need is the reassurance that the process is fair and balanced.
1 reply 0 retweets 1 like -
Replying to @tobie @RickByers and
While I’m not familiar enough with Chrome development to point at particular examples where the governance model helped derisk implementation, I have a recent example in mind with AMP where I feel like the governance model really did.
1 reply 0 retweets 0 likes -
Replying to @tobie @RickByers and
The particular example in mind was implementing the opt-out mechanism for CCPA compliance by next Wednesday. I strongly believe the governance system was critical in making sure that deadline was met and that the implemented solution was actually the right one.
1 reply 0 retweets 0 likes -
Replying to @tobie @RickByers and
It would be interesting to interview other players in the chromium field to see how they feel about the governance model, and if they’d be more keen to contribute if the governance model was different.
1 reply 0 retweets 2 likes -
Replying to @tobie @RickByers and
Actually, now that I think a bit more about it, there was a lot of uncertainty around the privacy and security requirements that chromium had around the sensor work I did for Intel a few years ago, that a better governance system would have clarified upfront.
2 replies 0 retweets 2 likes -
More predictability around the handling of privacy and security is a great example! That's also one of the top ~3 concerns I hear from Google chromium engineers too. I personally think its worth investing more in that area for all chromium stakeholders.
2 replies 0 retweets 1 like -
Replying to @RickByers @tobie and
I hear this also from folks who depend on Chromium to build their browsers: They end up side-stepping Blink’s governance by turning prefs off in their products, or using PING as a proxy to put the break on features (or ask Mozilla folks to jointly voice concerns).
3 replies 1 retweet 4 likes -
Replying to @marcosc @RickByers and
These are product choices. If the flags aren't flexible enough, that's one thing. That flags need flipping is simply the result of disagreement, which is both healthy and rational.
1 reply 0 retweets 2 likes -
Replying to @slightlylate @RickByers and
Completely agree - flags are great! My impression of what's not so great is not really having much say in engine direction (and having to fight proxy battles for/against features through W3C or other means instead of via blink-dev).
1 reply 0 retweets 2 likes
Fighting *against* features is implicitly asking to edit the choices of other embedders. That's the work of flags in a well-run project pre-consensus.
-
-
Replying to @slightlylate @RickByers and
That would be true if what Blink shipped wasn't also seen as "The Web Platform"
. Therein lies the problem: in that by flipping flags one can be painted "anti-Web", when some features perhaps should never been implemented in the first place (a failure of governance).2 replies 0 retweets 3 likes -
Replying to @marcosc @RickByers and
Moved goalposts. We have ways for products built on Chromium to disagree. That's part of why there are more Chromium browsers today than any other sort. What we don't have is a single product. Each makes choices and competes in the market. Products have engine choice too!
1 reply 0 retweets 1 like - 6 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.