– DRAFT –
Discuss: How to build a new feature for the web platform — and make it a success with developers

Feature Success

RRSAgent: make minutes

Adrian: I'm with the ARIA WG, my interest is helping to make sure new features are accessible

Adrian: exposed in a way that users can understand, use etc

Karl: features are implemented in different timelines sometimes

Karl: ???

<karlcow> S/???/How do we handle differences of implementations? How do we handle the breakage across browsers? (Interop/webcompat)

jamesn: it's hard to build enthusiasm around accessibility features

mike: it's neglected someitmes

mike: don't have a good way to measure

ty-everett: I'm interested in learning the process around getting new features added to browsers

kgovind9: I work for Chrome. We have various processes etc. One thing I noticed that a lot of devs aren't familiar with W3C

kgovind9: We say "can you open an issue", folks don't have a github account or don't have experience working with standards

eemeli: I work in localization, mozilla. It's a thing developers think they can fix afterwards

eemeli: everyone invents their own thing

eemeli: we've been working with the unicode CLDR, introducing a new standard messaging format

eemeli: hwo can we make sure the thing we're building that does all the things actually gets adoption

selya: Common problems that can be addressed in the early stages of the design

mike: There are no magic answers

arma: We (Intel) have been implementing device sensors. Hard to get feedback

arma: how is it for other browsers or other people. Who is using our API, how can we interact with them

zcorpan: ???

<dbaron> zcorpan: one thing is doing an origin trial if your feature is new. At least Chromium has a way to get feedback from people participating in the origin trial.

<dbaron> zcorpan: Firefox has origin trials but doesn't have a formal way to collect feedback from them. That's one way.

<dbaron> zcorpan: Another way, if your feature is shipping in stable already, there's a project called HTTPArchive, where you can query for anything having to do with source code of websites in the data

<dbaron> zcorpan: so if you have a use counter for your feature that's queryable in HTTPArchive, can get a list of websites and find contact information for those websites.

karl: partner with someone who is asking for the feature

aki: curious if there are web devs in the room. A few folks raise hands

(blockchain, webviews...)

eemeli: I've build YAML which has a few users

<annette_g> I build web apps for scientists

mike: get feedback as early as possible on feature design

mike: w3c is open now, it didn't used to be that way

mike: don't even need to be a w3c member to have influence

andreubotella: We were discussing, in order to fix something you need to know what needs fixing

andreubotella: browser centric workflow

andreubotella: web dev workflow is they already have an issue

andreubotella: can hire Igalia to fix browser issues

andreubotella: can also figure out if your proposal makes sense etc

niklas: browser versions break things in our apps. Raised issues but no response

<karlcow> https://bugs.webkit.org/ WebKit

<karlcow> https://bugzilla.mozilla.org/ Firefox

<karlcow> https://issues.chromium.org/issues

<karlcow> Broken web browser https://webcompat.com/

niklas: reported a few years ago, with repro. Sometimes no replies

karlcow: you can report to webcompat.com for broken websites in any browser

karlcow: web devs can file bugs there

karlcow: issues can go from there to the browsers own bug trackers

niklas: in my case it was a webview issue

mike: In my experience, I look at a lot of bugs, I try to be a good citizen. Karl does this fulltime at webkit

mike: I cc karlcow and put a certain keyword in the keyword field...

mike: anyone can do this. If you see a bug and it doesn't get attention, see who you need to alert

<karlcow> I'm karlcow

jamesn: for webcompat, for live sites... what if you're still developing

<aardrian> +1 to James on the accessibility issue reporting

karlcow: you could do it on webcompat.com

karlcow: people will look at it and forward

jamesn: is it just an extra layer, or not

mike: one opera person left, another one came in. So we have 4 again

dbaron: if you have somethign that you know is a bug in particular browser, I would encourage you to file it for that browser directly

zcorpan: I agree

<karlcow> Karlcow: agreed

mike: web dev feedback... hard problem to solve

mike: I'm an elected moderator at stackoverflow... went on strike last year. I didn't return

mike: before chatgpt, it was easier. Folks went there to ask questions. I mined that data, in a manual or semi-automated fasion

mike: I tried to figure out what are the things that are causing people pain

mike: for the web platform

mike: something we can do, but is timeconsuming

mike: there are tags, e.g. websocket

mike: requires resources and time for someone to do that. But should be possible to do in a better way than I did

aki: I'm from Ecma. Universities pay dues

aki: they do research

aki: put together effective research questions. How folks use our APIs

aki: it's not automated, it's hard, but gets useful info

<aki> *Universities pay NO dues to participate in Ecma

mike: recommend https://browser.engineering

mike: tutorial on how to build a browser engine in python

mike: the authors Chris Harrelson, Pavel Panchekha

mike: Pavel has students who are also interested in our problem space

mike: how can we hook into a way that the students can do research on etc

mike: how we can exploit academia :D

mike: when you look for dev problems, things you assume is a great solution e.g. service workers

mike: in practice, web devs have said, it's not the greatest thing

mike: appcache tho

mike: a lot of folks use websockets

mike: try to drive adoption, sometimes still don't get it right

aki: getting merchants to participate is hard

dbaron: in the response to getting things wrong

dbaron: one thing we see is valuable, is getting real feedback sooner

dbaron: sometimes ship peacemeal

dbaron: sometimes dangerous to design a whole new thing, without knowing how to validate that it's good

mike: Step 0, I learned from Ian Hickson

mike: go back and describe your problem

mike: when ask people to do this, they often don't give you a use case, they give you a solution

mike: identify in a few sentences, what problem are you trying to solve

mike: get agreement that it's a problem

mike: monitoring usage and success

mike: Interop 2024

mike: kadir and foolip identify a discrete set of web dev pain points

mike: what's the process to get things into browsers, first describe the problem

mike: if the problem needs a change to the HTML spec, file an issue at whatwg/html

mike: optionally, if you care to propose a solution, you can offer a concrete description of a solution

mike: going the other way doesn't work well

mike: if we don't have evidence that it's a common web dev problem, won't be prioritized

mike: another common mistake is folks get too involved in their solution and forget the original problem

aki: I agree. Once you have identified the problem, figure out if it's someone else's problem

mike: something that's measurable or confirmable

mike: Book, how to win friends and influence people

<karlcow> https://en.wikipedia.org/wiki/How_to_Win_Friends_and_Influence_People

mike: I often give a copy away

mike: you can't do things on your own

mike: unless you'll implement it yourself, which you can, but you still need to get someone to review

mike: go back to first principles

mike: communicate things in the right way

mike: fall into "someone's wrong on the internet"

mike: one of the things in the book is "you can't win an argument"

mike: shouldn't rathole in issue trackers over an argument

mike: focus on convincing people of things, treat interactions as a job interview for a job you really want

mike: maybe the interviewer is not super competent

mike: what can I do to get this unfortunate interview interaction, to convince the person

mike: get people to act on what you say

zcorpan: still need to convince browsers that the thing is important and something they want to maintain

karlcow: cost is very high to introduce something to the web. Need to maintain forever

mike: need to convince the code owners

mike: if you write a spec, need to be committed to maintaining that spec for the rest of your life

mike: you'll get bug reports on the spec

<aki> or worse, you'll get CVEs

zcorpan: https://wpc.guide

mike: was this useful?

mike: open to feedback

RRSAgent: make minutes