Re: AppCache post-mortem?

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

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

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

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.

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

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

Received on Monday, 13 May 2013 11:58:10 UTC