Meeting minutes
👋
<gsnedders2> ACL? Access control list? But that doesn't make sense in context?
greg: Principles of a responsible rollout
greg: potential impact of breaking change
greg: communication and rollout strategy
greg: Desire for Reporting API.
greg: Standards Process should be improved.
greg: Comms and Rollout timeline. to broadly communicate.
wanderview: in Chrome, enterprise team has also struggled. We have a process to surface risky deprecations from enterprise...
… we require deprecated / interventions can be disabled through enterprise policy.
gregwhitworth: It helps and doesn't help...
… sometimes only one enterprise customer won't turn on the policy--and that causes the world to end.
… they just expect their stuff to work.
… "salesforce breaks" is what customer sees.
jrosewell: Thanks Greg. ❤️salesforce.
… but there's a lot of smaller orgs out there too.
… I'm an example of one such organization
… we don't see these breaking changes
… nature of specifications, changes aren't written down, no rigor of W3C process applied.
… have inconsistencies in how the behavior varies between UAs.
… changes pile up. Could be anti[..]. I think this is one of the most significannt
… sessions. Thanks for listening.
yoav: speaking of "hard to watch everything on blink-dev"
… would it be helpful to have a deprecataion-dev list?
gregwhitworth: Chromium-only? Would love to get all vendors on board.
… need time to go gather info on deprecation.
yoav: so you are looking for a centralized place for dialog?
<jrosewell> blink-dev is an example of the "tax" that browser engineers place on the rest of the eco-system. It's "byzantine" for the wider eco-system participants.
gregwhitworth: yep, centralized place. Maybe a place to link off to the speicifc place to have the discusion.
rbyers: From Salesforce, are the problems you've seen from intentional changes or just bugs?
gregwhitworth: intentional changes (cites performance issue noted in slides)
… but had nothing to do with standards themselves.
… so would be nice allow the venue an opportunity to find NDA relationships with others to investigate.
rbyers: there are often a set of changes in where 99 bugs might be "not expected to break" but where one does...
wanderview: re: central place... challenge is that only chromium is bringing work? May not be as engine-diversified.
… you'd have to drum-up support from others.
hober: Re: question of TAG taking this up... selfishly suggesting: no. We're overloaded already.
… for TAG review, it's driven by the CG / WG when they think they are ready (and not otherwise)
<Zakim> hober, you wanted to react to wanderview
gregwhitworth: would Apple be interested in helping with an impact assessment if it came up in such a group?
hober: I don't hate the idea ;)
<Zakim> karlcow, you wanted to ask about version 100 communication operation if it was useful.
karlcow: Are you looking for long-time in advance notifications?
gregwhitworth: I don't think we'll get 100% of people prepared (regardless of timeline)
<Ben_Morss> How does one join this queue of questioners?
gregwhitworth: I'm lucky to have connections to browser vendors... but how do we allow others to get this communications.
<miketaylr> type "q+"
<Ben_Morss> thx
<Ben_Morss> ooo
gregwhitworth: note: the big ones have been really well communicated.
rbyers: happy to see you mention reporting API. Didn't think threat assesments would scale. Chrome use counters are a proxy.
… hope was to automate more of this.
… mentioned a dashboard... do you have what you need from Chromium perspective?
gregwhitworth: yes! And that's working for us.
… using that info (and Canary builds to test).
… getting data from customers is slow turnaround
rbyers: having a dashboard to be able to see this early and regularly.
… having tools to help makes it more scalable
wanderview: Another idea: a TaskForce to gate before launch.. but another idea: a post-mortem
… breaks aren't driven by standards changes, but having a review to understand how a decision was made...
<jrosewell> There is a disconnect between the pace of change in the browser world and some web site operators. How about not breaking things in releases unless both users and web site operators agree?
wanderview: at Google, post-mortems are helpful for learning.
… not sure it would work in multi-stakeholder scenario though.
Ben_Morss: Have been working on removing lesser-used storage things. Want to know if they are used, but don't know how!
… want to be able to find the right sites, talk to the right people.
… want to find a way to make this available to other companies too (not just browser vendors, etc.)
heycam: Lots of different kinds of changes that can break.
… at least for the one driven by spec changes.
… you might be asking for a process in the WG to survace these things.
… when groups make changes to specs, it would be nice to tag or collect them into some centralized place.
… for other cases (performance of accessibility issue), it might be very difficult for those making the changes to realized (in advance) that it would be a problem.
gregwhitworth: understand that [potentially] every feature could break something...
… may not be a standards change, but there is a priori knowledge that it will have an impact. Some of these may need NDA discussions...?
… not sure how we reach all companies!
miketaylr: if you had a deprecation policy magic wand... what is the minimum time you'd want to see?
gregwhitworth: nolanlawson how long does it take to do a code scan?
… about a few days. That might be a minimum
… to fix, it might take months.
… six months to a year.
miketaylr: restate: so 6 to 12 months?
gregwhitworth: yes, to ensure all of salesforce components are patched.
Orphis: Re: collecting info from WGs... an issue is that spec is updated, but UA don't ship the changes until much later.
… so telling people based on the spec change, may not be as effective.
gregwhitworth: More and more, my brain is thinking of reporting API automation... having a centrailzed status site.
… site could surface companies (who want to participate) that may be broken...??
… just brainstorming
… again tough when a component of a site is broken, and it implicates the larger site.
<jrosewell> +1 to it looks like "Salesforce" broke - customers expect their vendors to protect them from these issues
gregwhitworth: right now, every product need to go do their own setup. Don't know how to solve that.
<Zakim> karlcow, you wanted to ask about nightly browser versions and what is missing there to help?
karlcow: did you experience anything missing with reporting api or testing?
… we have so many permutations/combinations of salesforce, that's it's really hard.
yoav: 1) announcements should be driven by implementers, not WGs.
… 2) Reporting API for deprecation reporting. Spec isn't in a great shape. Chromium only?
rbyers: if Chrome is causing pain, we don't like that. Have added process, etc. Conclusion is that best source of data is experimentation (e.g., 1% of end users)
… we hear that 50/50 of enterprises don't have telemetry turned on.
… I can tell a use-counter is hit, but can't measure the impact.
… if it's below a threshold we assume it's not impactful. But it could be a user check-out flow.
… would love to see a API that indicates catastrophic failures has occured.
… then we could get more insight into what impact.
gregwhitworth: maybe moving forward? But "upgrading" the Salesforce app won't catch everything.
… might have to summarize some of the impact.
… inverse of reporting. You report to browsers.
… we don't think unhandled exceptions are an indicator of failure. but maybe not?
wanderview: When trying to improve on this... when give more folks more time, it translates to less urgency.
… need to find a balance.
gregwhitworth: I value a task force for this because getting on a call allows me to convey urgency in person.
<Zakim> Travis, you wanted to note telementry systems as scale for the web at large would be 💯
<gregwhitworth> Travis: we could invest a lot more in general in various kinds of telemetry systems to heal and understand what's going on
<gregwhitworth> Travis: I deal with internal customers just trying to figure out what it is so slow and there are things in the tools but can't see them in the labs nor are they hitting them but it's in the customer's machine
jrosewell: from econ perspective, a business has to decide whether or not to invest in the web platform... they may chose not to invest (or use it to distribute an app)
… have heard some interesting ideas.
… want to preserve the stability of the web.
… from a business and econ perspecive. Feel this is the most important issue facing the web at the moment.
gregwhitworth: envisioning a TF that meets 1x per quarter... who is interested in helping figure this out?
… yoav, Travis? others?
<jrosewell> I'd like to be included if scope is also including the cadence of change and aligning to pace of user / business change.
👍
gregwhitworth: want to start putting together a doc of potential solutions.
… thank you all for your time!
… we'll stay in touch!