W3C home > Mailing lists > Public > www-style@w3.org > December 2006

Re: Issues list and big picture

From: David Latapie <david@empyree.org>
Date: Wed, 13 Dec 2006 09:28:46 +0100
Message-Id: <31F49113-51B5-4FC0-9EB7-4F34306756B0@empyree.org>
Cc: Bert Bos <bert@w3.org>, www-style@w3.org, www-qa@w3.org
To: Karl Dubost <karl@w3.org>


Le 13 déc. 06 à 03:59, Karl Dubost a écrit :

>
> Le 3 déc. 2006 à 19:05, David Latapie a écrit :
>> This is a copy of a reply regarding the “CSS big picture”. The  
>> original topic was the multiplicity of proposals and the reason of  
>> their frequent refusals.
>
> Are you requesting something like
> 	- a white paper about CSS 3?
> 	- an issues tracking tool for CSS 3?
>
> I have myself requested a few times this to the CSS WG. Some of the  
> specs have a kind of issues list in text only, but it is difficult  
> to access the content.
> Maybe something like
> http://www.w3.org/2005/06/tracker/

Both, but these are two different request, that just happened to both  
be related to quality.

===============================
== A white paper about CSS 3 ==
===============================

David Woolley mentionned <http://lists.w3.org/Archives/Public/www- 
style/2006Dec/0011.html>:

>> > Does this never lead the rejectors to ask themselves /why/
>> > these "variations" are so frequently proposed ? [...]
>
> I think the main reason is that people don't look at the big
> picture when proposing them. [...]

When a problem occurs frequently, it means there is something wrong  
with how it had been anticipated. Here, the thorough understanding of  
what CSS is.

- A white paper (or at least a FAQ) would help *contributors* write  
better proposals in respect to multi-modal access, accessibility,  
generalisation and so on => solid proposals
- As for *W3C staff*, it would alleviate their burden, since a lot of  
questions would have already been answered in the aforementionned  
white paper / FAQ - they would not have to constantly refuse /  
annotate for the same reasons => time-saving
- For both, it would better the reputation of W3C as an ivory tower  
not taking into consideration people's suggestion (just count the  
ratio of “read these fucking archives” or “won't work because you did  
not took x under consideration” to get an idea) => better reputation

I'm sure there is a lot of good ideas out there. For now, it sounds  
to me as a dialogue of the deaf. And that really a pity since both  
part are doing the best of themselves.

=======================================
== an issues tracking tool for CSS 3 ==
=======================================

That would be related to the former and to greater quality. This is  
what Karl is mentionning with <http://www.w3.org/2005/06/tracker/>  
(this very software may or may not be perfect, but this won't impact  
on the relevance of the idea)

- A white paper is a strategic tool. It shows the “big picture”, what  
we want and don't want to do, what are the common mistakes and so on
- An issues tracking tool is a tactical tool. It shows how different  
proposals comply (or not) with our ultimate goal. It serves both as
-- a repository for proposals, so that contributors won't reinvent  
the wheel - some proposals have already been made so this is  
redundant to start from scratch again; just improve the existing.
-- a constant reminder of what is wrong (or good!). If someone want  
to create a rule for something, someone else may point her/him to a  
previous similar case. That would save a lot of time and arguments -  
once again by not reinventing the wheel, this time not for improving  
but for not reproducing mistakes and spending lot of time repeating  
what had already been said.

Not counting the trivial advantages such as pointing to an “issue/ 
proposal” number instead of repeating whole paragraphs of text,  
federating people, having a standard tool easier to search than a  
mailing-list and so on. Plus the fact that some W3C ML have already  
implemented it.






As I said in my introduction, these two proposals follow the same  
goal : to attain a higher effectiveness or, as the qualitician  
Laurent Denis would put it, a higher efficiency - the best result at  
the least cost.


Oh, by the way: the same two requests hold true for HTML. Especially  
now that we're seeing some big changes regarding this language. This  
is about the right time to introduce such big things.

-- 
</david_latapie>
http://blog.empyree.org/   U+0F00
Received on Wednesday, 13 December 2006 08:29:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:48 GMT