Three Buckets of Thoughts
Author(s) and publish date
- By:
-
-
Karl Dubost
-
- Published:
Kevin Lawer has written a great blog post Web Standards' Three Buckets of Pain explaining cultural differences between communities.
Opening up the W3C
Justin Thorp commented (emphasis is mine):
Karl, I'm really excited by your efforts with opening the W3C. The only thing is I hope its more then just "opening up." We can make our mailing lists and our documents publicly available... we can make more primers... but I'm not sure that's enough. It's about engaging the development and design community in a genuine conversation... its as you said it "being in liaison with the developers, designers and the Web pro communities." I'm here to be a servant to your efforts however i can be.
I'm pretty sure we can work out something. Seen from the inside, the door has always been opened, but people didn't know about it, or know that they could interact. The efforts of W3C staff to publicize it might not have been enough. There is also a question of scalability. More on that a bit later.
There is a perception problem on both sides. And I'm pretty sure there will be frictions and unknown issues by the mixing of communities, but that's more exciting than worrying. smile
Learning the vocabulary, the way people think or interpret is always challenging and wonderful at the same time. I emphasized the "we" because we will be able to achieve this if Web designers, Web developers, implementers, hackers are working together, which reminds me I have an action item for the HTML working group about HTML 5 for authors.
Waterfall model
Then Dan Bradley said:
First, you have to have a spec, then you implement against that spec, then you test the implementation against the spec. The W3C has created several specs, and Browser developers developed code against those specs. Sadly it's the third part that falls down. The W3C did a great job providing tools to validate HTML, CSS, and other specs for the web development community at large, but they haven't done anything to validate there specs for the browser developers that I know of.
This model of development is usually called the waterfall model. Not all W3C working groups are using this model. Some have introduced a test driven development for their specifications, some have chosen to be very practical and to carefully specify what has been already deployed.
Life of W3C specifications
It starts with implementers (from companies often) who have a product in development or an idea of a future product. These developers create a specification around their requirements for their own products, plus things they think would be cool to have. Sometimes the passionate discussions create heavy specification. It's a difficult exercise of knowing what should be inside or not. To find the right balance.
Personally, I'm much in favor of a specification which starts small and can evolve, adding a new set of features at the next version.
When the specification reaches Candidate Recommendation stage, the Working Group is officially asking for implementation experience. It doesn't mean that they don't have them already. It really depends on the working groups. It is the time where some groups start to think about test suite and how to prove what is implemented in an interoperable way. The group is producing an implementation report. It is far to be perfect and shows its own issues. I should write a separate article about it.
Personally again, I prefer when the group is working on test cases at the very beginning of the specification life. So that there is an iterative process between specification/test/implementation. But here I just show my QA hat.
To enter the next step, Proposed Recommendation, the WG has to show that each feature is implemented twice in an interoperable way. Really challenging. Features will be removed from the specification if there are no dual implementations of each feature.
Then it becomes a W3C Recommendation. Implementations are often already available on the market by this time and are in the process of being finalized. Software bugs related to ambiguities in the specification, to early implementations are part of the software life cycle. The working group will fix minor bugs in errata, and bigger issues in a next release (which takes time.)
This is another opportunity for an article about products and specifications ecosystem after publication.
No, it isn't true that lines of communication were always open. If so, that would mean there never was a problem of openness to be solved. Just as an example, if one discovered a CSS problem and documented it on a blog, CSSWG would pretend such documentation didn't exist and would insist you join a high-volume mailing list, submit your bug all over again that way, and then sit there and have Tantek call you an idiot for a week. Or you were told to use Bugzilla, the least usable site on the Web.
And “a perception problem on both sides”? Doesn’t that admit that the W3C held in contempt the people who actually used and loved the Web? No? I don’t think so, either. The W3C never gave us an initial thought, let alone a second thought. They never knew we existed. The W3C spent all day writing impenetrable standards for a medium it never even used.
Hi Joe,
I had the chance to work on different parts of the hill. I was once a student in an University discovering the Web when it was being created and ermerging in 1991/1992. Then I created the first Web site of Meudon Observatory when I was a research assistant there. I had my own conspiracy theories about the move from IETF to W3C, but still I had also the possibility to have dialogs with people doing stuff. For example, I remember sending a comment about HTML 2 or (unborn) HTML 3 and have Dave Raggett replying to me and asking me more details.
Then I have worked in a Web Design agency in France in 1994 and again was able to access the documents, and to send comments to them if necessary. I was just a simple Web developer at this time. I also started to translate as a volunteer some specifications in French and I was authorized to do so in a world where most people were very protective about their documents. It was the time where some people were going to court for Cache in copies on search engines and browsers. But W3C had free access to documents.
The work has always been accessible to me, and I have always been able to send comments following the process.
Then I have been hired by W3C and understood a bit more the process document, and how it was working. How it helped to channel information. A process is not something perfect, but it is here to give a balance of constraints and flexibility. It is also which is built slowly step by step when issues arise. In fact the development of a process in a community is always very interesting in a written or verbal form. I have seen it with microformats and whatwg, for example. Things seems to be "free for all" at the start, then when the issues come, the process builds up.
Tracking issues on weblogs is far to be easy.
Let's take a quick metaphor, I want to have a pizza delivered at my place, and I put an announce on my door at home. Hoping that someone sees it and that the closest pizza delivery service come to my place. I go a step further and I notify the service by saying "hey my command is on my door", then the person is replying to me, could you order through our system. There is reason for that. One part of it is accountability; there is also paper trail, records, etc.
But Working Groups and chairs are discussing these issues for the last two years on how to improve the tracking of issues, and how to be able to track comments from Weblogs.
There is also the language issue. How do we track a comment made in hungarian with a thread in the hungarian community?
My answer is that it takes connectors. People who know the tools, the process in each community and are able to forward the issues in the right format and the right language, following the process.
Standards are made of humans, and there are such admirable people in the community who make efforts to bridge worlds. I have deep respect for them. Either by translating specifications, helping to understand the technologies, pointing issues in a constructive way, proposing ways of working better together.
Joe, do you have a proposal or an idea for tracking issues raised on weblogs, with a process which is smooth and flexible?