Re: [whatwg] Correcting some misconceptions about Responsive Images

On Wed, 16 May 2012, Glenn Maynard wrote:

> On Wed, May 16, 2012 at 8:35 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
>>  The downside of the CG as executed is that it was much less successful
>> in attracting browser implementor feedback (in part because it was
>> apparently not advertised in places frequented by browser standards
>> people). So the implementor feedback only got applied later, and without
>> full knowledge and understanding of the CGs efforts. It's not useful to
>> have a standards process that doesn't include all the essential
>> stakeholders.
>>
>
> This isn't a new suggestion, but worth repeating: starting a CG is fine,
> but *do not make a new mailing list*.  Hold discussions on a related
> monolithic list (like here or webapps), with a subject line prefix.  Making
> lots of isolated mailing lists only ensures that the people you'd want
> paying attention won't be, because the overhead of subscribing to a list
> (for a subject people may only have passive interest in) is much higher
> than skimming a thread on whatwg or webapps-public that people are already
> on.

FWIW I think that forming community groups that are limited in scope to 
gathering and distilling the relevant use cases could be a functional way 
of working. For example if, in this case, people had said "we will form a 
group that will spend 4 weeks documenting and prioritising all the use 
cases that a responsive images feature needs to cover" and then the 
results of that work had been taken to a forum where browser implementors 
are engaged (e.g. WHATWG), I think we would have had a relatively smooth 
ride toward a universially acceptable solution.

Of course there are disadvantages to this fragmentary approach compared to 
having one centralised venue, but it has the advantages too; notably 
people are more likely to subscribe to a low-traffic mailing list that 
just covers one feature they care about then subscribe to the WHATWG 
firehose. It also wouldn't require the unscalable solution of having 
vendors subscribe to one list per feature (fragmentation in this direction 
is already a huge problem at e.g. W3C and means that obvious problems with 
specs get missed until late in the game because people with the right 
expertise aren't subscribed to the correct lists).

Received on Thursday, 17 May 2012 09:19:21 UTC