At the W3C, chartered WGs have specified durations (usually ~2-4 years,) and specified deliverables. Let that sink in. Before anyone sits down to the very first meeting, the chairs have to agree on _what they're going to deliver_.
-
Show this thread
-
You literally have to know roughly all of what you will have wanted to consider in-scope in 2 years when you start out. There's ability to rescope things slightly, but it's painful. Your best opportunity to do that is your next re-charter (hence I argue for short-ish charters).
1 reply 0 retweets 1 likeShow this thread -
Now imagine you find out from a partner that they've got a super important problem; something you didn't know about, but would clearly be a fit for the Frobulation WG. What to do? Two options: 1.) Try to shoehorn it into the Frobulation WG 2.) Find some other venue in short run
1 reply 0 retweets 1 likeShow this thread -
The first is attractive for a few reasons: - all the experts are "in the room"; they literally know everything about the space! - if you can convince the WG that your thing is in scope & everyone miraculously agrees with your proposal, you have a "fast track" to standardisation
2 replies 0 retweets 2 likesShow this thread -
But remember, the WG already has chairs, and an agenda, and deliverables, and a fixed date to deliver them by. Your new idea _is randomizing_ from that perspective. And every WG is busy! The work of dotting every "i" and crossing every "t" is vital, laborious, and time-consuming
1 reply 0 retweets 2 likesShow this thread -
Trying to do the sort of open-ended investigations of a solutions space that you need to do to iterate towards the right solution is nigh impossible under these conditions. And that's without considering the constituency considerations.
1 reply 0 retweets 1 likeShow this thread -
Yes, all of the "right people" (implementers, knowledgable insiders in the space) are "in the room" at the WG, but why? Because their organisations are members. And those folks _tend not to be web developers_....who are the people you're (often) designing a feature for.
1 reply 0 retweets 1 likeShow this thread -
Standards groups aren't a fitness function. Getting every implementer to believe they could implement your proposed design or producing tight spec text *tells you nothing about it's ability to solve a real problem for developers or users*.
1 reply 1 retweet 4 likesShow this thread -
This is why you see Chrome engineers preferring to start new explorations in forums like
@wicg_. It's an open space that's super easy for web developers to participate in, which also preserves the ability to migrate a design/spec to a WG at the next rechartering opportunity.1 reply 0 retweets 2 likesShow this thread -
I don't set many policies for the Standards Team here, but "incubate first" is the most important of the short list; finding the spaces where you can iterate rapidly, not annoy the "right people" while you sort through rough hewn ideas, and get real developer feedback is *key*
1 reply 0 retweets 3 likesShow this thread
Chartered WGs of course *want* to take web developer feedback into account the way incubations processes can, but they literally don't have the time...and that's by design.
-
-
Anyhow, if you're a web developer and want to have a big impact on the future of the platform, comments you leave in repos and discourse threads in
@wicg_ shape things at a critical moment: https://wicg.io1 reply 5 retweets 9 likesShow this thread -
BTW, none of this takes away from the great work that WGs do. They're the big leagues and CGs are the farm teams. We need them both! But we also need to expect reasonable things of each, else we'll always be disappointed.
0 replies 0 retweets 6 likesShow this thread
End of conversation
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.