Developer Feedback to W3C (was: AppCache post-mortem?)

Hi, folks-

Dom, thanks for pinging me. Some of this is reminiscent of a blog post I 
wrote last year [1], which reflects some ideas that had already been 
floating around for a while. While we've made a bit of progress in some 
of these areas (particularly the "crowdsourcing testing", which may have 
been part of the inspiration for Test the Web Forward), I don't think 
any of these ideas has reached their full potential.

On 5/14/13 4:15 AM, 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.
[...]
> * 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. 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

I would suggest that it should also be easier to file a bug with 
implementers, as well. I've always wanted to have a place to file a bug 
once for all the browsers *and* the working group (backed by a test, of 
course), let people upvote that bug, show which browsers pass the test 
with regular updates, and demonstrate the priority of certain bugs among 
developers. Sort of a combination of a bug-filing system and 
community-driven, sustained Acid Test. Having each browser have their 
own issue tracking systems is necessary, but it makes it hard for 
developers to coordinate on systematically requesting for specific bugs.


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

I'd really like to get this going. Part of the problem is finding 
developers and designers to answer this; coordination between all of our 
DevRel teams, and major dev sites, could help us come up with the right 
set of questions and a meaningfully broad set of responders.


> - get developers effectively represented in the W3C process via a
> new class of membership or through an elected representative

I don't think developers should have to join W3C to participate; they 
can participate now in our public WGs, and even join the WG as Invited 
Experts.

I have noodled around in the past on having "developer representatives", 
elected periodically... questions would arise of whether they truly 
represent their constituents, how to hold them accountable, how to pay 
for their travel and time, etc. I think I favor the idea of a W3C 
staffer dedicated to advocating for developers, but it doesn't have the 
same feel as someone elected and serving as an independent advocate.


> As Alex pointed out, getting more developer feedback is only useful
> if that feedback has real influence on the course of our various
> technologies, 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.
>
> 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'll also ping our devrel team since this whole thread is very
> relevant to them)

Having some infrastructure and community around all these efforts would 
be useful. The route I took to doing this was starting WebPlatform.org. 
Our initial aim there is to provide high-quality documentation, so 
developers get in the habit of going there for information (unlike 
W3.org), and then to incrementally build up the tools and information 
for participating in standards themselves... for example, learning about 
features early and trying out the JS shims, so they can give educated 
feedback about how well it works and how it might change; and even just 
serving as a central location to find someone to help you triage your 
bug or feature request, answer surveys, and generally discuss stuff that 
will impact standards.

We're making good progress on the documentation front, and starting to 
get into a rhythm... maybe in a few months, we can start to think 
seriously about some of these other aspects.

[1] http://www.w3.org/community/devrel/2012/03/22/devrel-and-webed-cg/

Regards-
-Doug Schepers
W3C Developer Relations Lead

Received on Tuesday, 14 May 2013 09:44:08 UTC