Re: AppCache post-mortem?

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).

>    - 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. 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).

>    - 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.

>> 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.

> 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

Received on Tuesday, 14 May 2013 08:25:01 UTC