Re: AppCache post-mortem?

cc- most of the people - I believe they are on the mailing list.

On Tue, 14 May 2013 10:06:26 +0100, Alex Russell <slightlyoff@google.com>  
wrote:

> On Tuesday, May 14, 2013, Dominique Hazael-Massieux wrote:
>
>> Hi All,
>>
>> Thanks a lot for the excellent points that have been brought up in this
>> thread; I'd like to propose a summary of where I think we are, and would
>> like for volunteers to step forward to bring up more concrete plans that
>> we can include in our proposal.
>>
>> * technical work item: partial cache update; Tobie and Chaals at least
>> agree this is an important use case, and presumably have a reasonable
>> idea of what the requirements are; Alex has looked into the
>> (non-negligible) amount of work that would be needed to make this true,
>> and believe NavigationController is a first step in the direction that
>> would make this possible.
>> It would be great if Tobie, Chaals and Alex could caucus to document the
>> requirements and challenges for that particular piece of technology;

The Webapps group is tasked with trying to fix this problem. Fast is good  
- but too fast is probably one of the causes of the problem in the first  
place.

>> this would be a great contribution to a potential follow-up
>> specification work.
>>

> My current plan with the Navigation Controller is to continue to iterate  
> in conversation with developers and vendors using the github repo and
> issues system as a way to note and address concerns. When the design
> looks to be more stable, it will be circulated more widely, including in
> public-webapps. At that time, the Chrome team is on the hook for an early
> implementation to validate the design and I will be writing spec text for
> it.

I'm all for keeping your focus on developers, implementors, users, and not  
spec-mongers. But a little bit of formally pushing it to webapps might be  
a way to get it in front of more developers, who might take advantage of  
the fishbowl to think harder about it, and give the sort of feedback  
you're looking for.

>> * structural challenge: there seems to be consensus that it is currently
>> too hard for developers to influence the course of a spec, even when the
>> state of the related technology is close to being unusable.
>
> This mis-charachterizes the issue: developers care about specs and
> standards incidentally. What they *really* want is a way to change the
> world which they must live in

Yes...

> -- and that world is defined by the browsers that vendors with the
> largest footprints deploy.

No. Well, not entirely. It is defined by the tools that matter to them -  
so the gorillas have the biggest footprint in that definition, but there  
is a lot of the space where others are the most important players.

> We have ample evidence of easy-to-change specs that nobody implements and
> nobody is helped by.

Indeed.

> What we can do is to help create better, higher-signal channels to funnel
> developer feedback to the few places it can actually matter; lending the
> W3C's bully pulpit to developers who feel the pain but are known to be
> elected representatives of a much larger group would go a long way in
> eliminating the instinct of vendors to write off individuals.

I get where you are going, and think it broadly makes sense. Vendors won't  
stop writing off the individuals asking for things they don't want to do  
(nor the massive groups asking for it). W3C provides a forum where those  
people can clarify what they are looking for, and build the kind of use  
cases, demonstrations, and explanations that make it easier for people to  
look at the argument.

People can work with vendors to implement, vendors may prefer to wait and  
see if some other vendors does it first, or people can just write specs in  
a vacuum and somehow hope they stick.

As vendors make these choices, the market flows around them and changes.  
By the time today's standards work is ubiquitous in the big part of the  
bell curve of development, today's top 7 browsers (or search engines or  
authoring tools or CRM systems or…) will almost certainly be replaced as  
the most important, either by newer versions or by newer products from  
vendors who better adapt to the market.

>> Several proposals have been voiced to help reduce that barrier:
>> - make it much easier to submit bug reports, with a bug squad that would
>> actually triage and dispatch bug to the relevant working groups as
>> needed

Yes, I think this would be really helpful. I think one of the important  
things that makes whatwg a comfortable place for some people to work is  
that there is a single point of entry.

>> - make it easier for developers to provide more qualitative and
>> quantitative feedback on various technologies via surveys

Hmmm. Not so sure if this is what developers want. Surveying opinion for  
the truth (as opposed to the results you decide to get - which are easy to  
produce) is actually a very tricky thing to do. Putting 3/4 of the  
necessary effort into getting answers, that convince us to direct 7/8 of  
our energy in wild goose chases is a serious risk.

>> - get developers effectively represented in the W3C process via a new
>> class of membership

Developers are represented through the process. Yandex is in tiny part a  
browser maker, but we are primarily developers of stuff on the Web. And  
there are many more W3C members enormous, large and small who are  
developers.

How they get effective representation, and how W3C ensures that they get  
as fair a hearing as possible, is really a question of how well the W3C  
staff do their job of managing the Consortium. And while that is actually  
a lot harder to define, let alone drive closer to the definition, I think  
it is a very important outcome.

>> or through an elected representative

I think this is a bad idea. (Given the way W3C currently does elections I  
think it is a terrible idea, but even if that changes…). Related to the  
survey problem, this is a way of fixing the single most important problem,  
at the expense of being irrelevant to everyone who isn't concerned by  
that. And because winning elections becomes a goal in itself, we risk  
creating a system that provides a solution searching for more problems,  
instead of focusing on fixing things that need fixing and leaving well  
enough alone.

>> As Alex pointed out, getting more developer feedback is only useful if
>> that feedback has real influence on the course of our various
>> technologies,

Yeah. And part of that comes down to interpersonal and group interactions  
and willingness to listen.

Yehuda said that was the real problem in so many words, and I agree with  
his characterisation of the way things were in 2010 and that this was a  
serious root cause. I think things have changed somewhat - but not  
completely.

The impression that "browsers are what matters" is I think partly to blame  
for this. To put it crudely, we should give the browsers a kick up their  
collective backsides and remind them that they are meant to serve their  
users, and not vice versa.

When we get back to talking to each other as peers, we will recognise that  
browsers are indeed very important players - but should not be the sole  
governers of the web stack.

>> incl. in their implementation in browsers — so an
>> important aspect of making this work is to determine what parameters of
>> the way we gather or represent that feedback will make it truly
>> influential.

Some people (Tobie, Yehuda, PaulB spring to mind for specific moments,  
along with the WebTV IG as a whole) have done a pretty good job of this,  
while others (numerous, but not all, telcos leap to mind) seem to have  
been too scattered in their approach to really have an impact.

It's about demonstrating a market and convincing suppliers to work in it.  
Of course, there is a risk of imagining a market that doesn't exist and  
sinking a pile of money in it, then finding nobody is interested.

The lesson I take from this is that W3C's strength isn't well used by  
creating a new group for any sector that comes knocking, but instead is  
that it can help a new "industry" (whether you mean movie moguls or  
anonymous email developers) integrate with the community who are  
collectively driving forward the technology of the Web stack.

Which again comes down to social interactions as much as anything.

After all, vendors are mostly businesses, whether governmental or academic  
organisations, universities, companies, or organisations with a legal  
framework which restricts their ability to distribute profits to their  
shareholders... It is generally not their job to solve everyone's problem  
- they often have the legal requirement (most specifically relevant to  
companies) to look out for their own benefit and trust in Adam Smith's  
"invisible hand" to provide for the common weal.

>> I believe these 3 proposals have merit and can bring a very positive
>> impact on W3C (well beyond our gap with native); but as they stand,
>> they're still mostly vaporware, so I would need volunteers willing to
>> dig further into them to turn them into more concrete proposals on which
>> we could elaborate. Any taker? Robin? Alex? Yehuda?
>
> I honestly think this all hinges on the ability and wilingness of the AC  
> to understand how screwed we are regarding developer feedback today. My  
> sense is that it's just not on their radar yet.

So as an AC rep (and member of the AB for at least the next 45 days) I'll  
undertake to make sure that it gets further onto their radar. For some,  
especially those who represent developers, it is all too painfully clear  
and imminent. But I think they have not managed to collectively explain to  
each other just how big a group this represents.

As Dom says, I think W3C management do have some understanding of the  
issue, so a reminder will fall on fertile ground, as it were.

cheers

Chaals

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals@yandex-team.ru         Find more at http://yandex.com

Received on Tuesday, 14 May 2013 11:58:36 UTC