Re: AppCache post-mortem?

Hi all,

Apologies for the sporadic and late reply.

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:
>>
>>> • At least some of the feedback comes in the form of a grumpy gripe
>>> in the middle of a more or less unrelated discussion. I'm not
>>> blaming Tobie here ;-p
>>>
>>
>> I had a bad day yesterday. Sincerely sorry for the rant.
>>
>
> Don't be, it's a useful conversation. I only picked a bit at you because
> the structure of the email made it unavoidable :)
>
> [Can you email me directly (or in an appropriate forum) about the diff
> thing? Let's see if we can make that happen.]
>

The diff thing will need vendor participation early. It has implications
waaaaaaaaay down the line for cache invalidation, optimization
opportunities, timing, etc. Getting control over these caches and a place
to do this work (as Navigation Controller) provides is a stepping-stone and
one that might remove a lot of the pain in the short-term; at least that's
what the Google Apps teams have told us when we've discussed this use-case
in terms of NavController.


>  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.
   - Elected and funded "web developer representatives" whose job it is for
   some term to participate in standards work and lobby vendors.
   - 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.
>

I'm a huge fan of spec-factoring appropriately. 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:

   - Individual groups are dominated by invested single-issue participants;
   often people not building larger apps out of web technology themselves.
   There might therefore be blindness to the entire space of potential
   solution locations.
   - Time-frame concerns leading to a "if you can fix it here, do"
   mentality. This may be locally optimal. Nobody gets points with webdevs for
   saying "*your hoped-for feature will be with you shortly, just as soon
   as that WG or standards body over there gets its act together to spec the
   thing we have indicated to them that our spec needs"*
   - 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.


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


> 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.
>
> A CG has the advantage that we can launch it right now, provided we're
> committed to staffing and advertising it. I'm game. We can have an issue
> tracker on GitHub and that's all we need.
>
> There is one annoying point that we need to keep in mind: the RF policy.
> If we have "substantial developer suggestion" -> this group -> some WG ->
> some spec, then we'll need to secure an RF commitment from the developer.
> It's not fun, but it's not something we can skip. We should try to
> progressively work out ways of making that easy.
>

Who is this meant to protect and from what?

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. But we're nowhere close to that
today, so we all just live with the risk.


> I'm guessing that we *could* perhaps use the CG commitment tool for that,
> so long as we shape the input we send to other groups as an output document
> of the CG. That might actually prove lightweight enough to be usable, but
> IANAL. The RICG has a lot of experience with this that I'd like to hear
> about (Marcos?).
>
> I still like Spec The Web Forward as a name.
>

I don't. It implies that specs change things. 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.


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


> --
> Robin Berjon - http://berjon.com/ - @robinberjon
>
>