Re: AppCache post-mortem?

On Tuesday, May 14, 2013, Charles McCathie Nevile wrote:

> On Mon, 13 May 2013 15:35:34 +0100, Alex Russell <slightlyoff@google.com>
> wrote:
>
>  Hi all,
>>
>> Apologies for the sporadic and late reply.
>>
>
> No, it's a valuable contribution. And we've been playing this game for 20
> years without quite winning, so what's a few weeks :)
>
>  On Monday, May 13, 2013, Robin Berjon wrote:
>>
>>  On 07/05/2013 18:52 , Tobie Langel wrote:
>>>
>>>  On Tuesday, May 7, 2013 at 3:53 PM, Robin Berjon wrote:
>>>>
>>>
>  The main problem is the time commitment required for developers to
>>>> lobby a given feature. This pretty much makes it impossible for
>>>> developers who are not paid to do so to have a say in the development
>>>> of Web standards. Which is a shame.
>>>>
>>>
>>> That's definitely true.
>>>
>>
>> ...But it is not fatal.
>>
>> If the W3C believes that it is important for the health of the ecosystem
>> that developers have a more active voice, and if it is believed that this
>> voice is not present for economic reasons at the W3C, it seems plausible
>> that the W3C has an interest in fixing this. I can think of several
>> partial solutions, some of which might be combined to provide effective
>> relief:
>>
>>
>     - An "individual member" class of membership at the W3C whose
>>    "organization" gets a proportional set of elected reps based on some
>>  metric.
>>
>
> Given the consensus approach W3C uses, I don't think proportionality
> matters unless we're doing it wrong at a deeper level already (which is of
> course possible).
>

It has an aggregate effect in the senese that nobody is allowed to vote on
any standard without formal standing, and that's not afforded to web
developers except by their proxy organizations today (e.g., the jQuery
Foundation). Also, those are hugely over-worked representatives who are
mostly giving of their own time even when their orgs sponsor. It's just not
correct to imagine that corporate and university sponsored reps are under
the same constraints as webdev reps are today. One or two seats at a table
of hundreds is still tokenism.


>     - Elected and funded "web developer representatives" whose job it is
>>  for some term to participate in standards work and lobby vendors.
>>
>
> But see your point about funding this.


They are not incompatible. Both argue for a sustained mechanism.


> Plus people who get funded to do stuff are at risk of doing work for the
> funding instead of the original goal. (Yes folks, this means *all* of us).
>

...which is why institutions that want to matter look at incentives and try
to shape behavior to discourage agency-theory problems. In voting
organizations, that's usually frequent and contested elections.


>     - An occasional (quarterly? twice-a-year?) "hot issues" survey that is
>>    conducted via reputable polling techniques and funded by the W3C.
>>
>>
>>  I'm not sure what the best solution is, but there's a couple of
>>>> things that could be useful:
>>>> - The number of entry points for developer comments/requirements has
>>>> to be kept to a minimum, max three (HTML, CSS, JS APIs), and should
>>>> be unrelated to how groups are partitioned.
>>>>
>>>>
>>> Definitely. Gauging from the number of bugs on the HTML specification
>>> that can best be solved using a new CSS feature, I wouldn't separate
>>> HTML and CSS. In fact, it's often unclear whether a feature needs
>>> markup or an API (or both), as was indeed made apparent with AppCache.
>>> So let's not split at all. That's a solution-space issue.
>>>
>>
> Way back when, I spent a lot of time on the WAI Interest Group, which was
> once perhaps one of the most important fora for Web Accessibility (now it
> is useful, but not the hottest place in town).  The idea was that anything
> could be brought there, and redirected to wherever it needed to be heard.
>
> Of course, the problem space (even in accessibility) as understood was a
> lot smaller then. Which helped.
>
>  I'm a huge fan of spec-factoring appropriately.
>>
>
> Ditto... and equally a fan of some considerable fraction of total effort
> being spent on capturing the discussion of people whose input is good
> enough to work with, but misdirected enough to be easily lost by a
> super-efficient division of labour.
>
>  I've lead teams that have attempted just this, and even with a global
>> view and massive resources, it's HUGELY difficult today. Several
>> theories about why this might be  true:
>>
> ...[good sense]...
>
>>    - Individual WGs continue to be use-case driven, leading to a
>>    scenario-solving approach that is willfully ignorant of the overall
>>    architectural concerns and how their designs play into them.
>>
>> The last of these is something the TAG can weigh in on (forcefully, if
>> necessary), but often at the wrong time in the lifecycle. Better that we
>> attempt to change the culture and bring in more people with a global view.
>>
>
> Yes.
>
>   - There needs to be some form of cross-group instance (an IG, maybe?)
>>>
>>>> that receives these comments/requirements and filters them.
>>>>
>>>
>>> I wonder if there's value in having an IG over, say, a CG.
>>>
>>> One advantage of an IG is that we can call it the "Feedback and Requests
>>> Interest Group" and thereby use the catch phrase "You're complaining,
>>> but have you spoken to the friggin' FRIG?"
>>>
>>> Other than that, it's more "official", but I don't know that anyone
>>> cares.
>>>
>>
>> Unless it's a channel for discussion with the people who can set
>> priorities at vendors, why would they? Seems like a great way to babble
>> 'em with bullshit, if you ask me.
>>
>
> Yeah, this is an important point. Which means a success criterion is to
> have vendors actually engaged.
>

I think I skipped entirely over success criterion to "how would you even do
that?"...something which is not clear to me right now, but which I think
can be engineered with enough care and attention to matter.


>  The group would not be producing Recs (which an IG can't do anyway) so it
>>> wouldn't give us better RF-protection that I can think of.
>>>
>>
> Yeah it would for the reasons you outlined later. The policy for IGs is
> more robust than the "maybe when you're done I might commit" that applies
> in CGs.
>
> ...[cf CG policy]...
>
>> Who is this meant to protect and from what?
>>
>
> Joe small W3C member, from patent trolls who wouldn't mess with people who
> have real portfolios and patent lawyers to match.
>

Wait...what?

This is implausible. Small members are likely to get roughed up by trolls
only on their way to bigger game.


>  If a developer comes to me and says "have you thought about adding X, Y,
>> or Z" to Chromium and I hadn't, there are still many opportunities to go
>> around the loop and determine who has rights where.
>>
>> That said, I think this is another great reason to create individual
>> memberships: they can be a place where the boxing ring's boundaries can
>> be set. As a vendor, it'd be *great* to know that someone is a member
>> and has therefore signed the right agreements.
>>
>
> Indeed.
>
>  But we're nowhere close to that today, so we all just live with the risk.
>>
>
> In practice, I think that small players at W3C often watch the larger and
> better-advised, knowing that if an issue arises there will be a PAG at
> which W3C is committed to sort the issue. Sure, sometimes the big players
> just decide to pay to make the problem go away (EOLAS) but sometimes they
> don't, and end up fighting a battle that makes the rest of W3C win (also
> EOLAS).
>
>  I'm guessing that we *could* perhaps use the CG commitment tool for that,
>>>
>>
> I would hate to be relying on that.
>
>  I still like Spec The Web Forward as a name.
>>>
>>
>> I don't. It implies that specs change things.
>>
>
> Despite agreeing with you that specs don't change the world, I like the
> name. I like Spec The Future Web even more. But not for any good reason.
>
>  They do not. They simply build momentum for things that already
>> exist in the world. Original change comes from the process of
>> collaboration with and between vendors who ship products.
>>
>
> Quite.
>
>   - WGs could go to this group to ask for feedback on specific APIs,
>>>
>>>> and this group would have a good way to broadcast that signal to
>>>> developers and quickly gather feedback (a blog? a github repo?, not
>>>> sure).
>>>>
>>>
>>> A Twitter account. "Developer Review Requested: The Unicorn Taming API
>>> http://t.co/DEADB33F. Feedback: public-stwf@w3.org"
>>>
>>>  - W3C members who care about devs could have an easy way to donate
>>>
>>>> funds to this group which would help developers travel to F2F events,
>>>> etc.
>>>>
>>>
>>> That's a good idea, but I'd only get to that part if we have something
>>> roughly successful already. If we get that, finding sponsors won't be
>>> too difficult.
>>>
>>>  Again, if the W3C thinks that getting developer feedback is critical
>> (and I think it should think this), then asking for someone to collect
>> a kitty which can easily peter out and which has no obvious path to
>> being long-term seems like asking for trouble.
>>
>
> Right. Likewise, the moment you set up some group for W3C specs and then
> declare that it has to be in english, I'll be asking about whether we can
> set up the Russian Language group - and assume that others will do so for
> other languages. These are basic features of the world. Nevertheless, I
> think it is worth following up these ideas.
>
> cheers
>
> Chaals
>
> --
> Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
>       chaals@yandex-team.ru         Find more at http://yandex.com
>