- From: Eduard Pascual <herenvardo@gmail.com>
- Date: Wed, 7 Apr 2010 19:55:58 +0200
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: Mikko Rantalainen <mikko.rantalainen@peda.net>, www-style list <www-style@w3.org>
There are some recurring key points that have been highlighted again by Mikko's and Boris' e-mails. Maybe it's worth reviewing each of them: 1) The W3C process is perceived by many people (me included) as being painfully slow. The key here is to figure out what are the core bottlenecks of the process, and find ways to fix them. 2) The W3C process is not arbitrary: its stages are well thought of and the process itself has been fixed to address some issues. The most blatant example was CSS2: the W3C was too eager to get it out, and as a result we had to wait for 10 years until the most used UA (Microsoft's Internet Explorer) implemented at least most of it (which finally happened with IE8, I'm not sure if their implementation is fully compliant with the spec; but it's a well known fact that sites that can forsake IE7 and earlier can get things done which many less headaches). When we speak about speeding up the process, let's keep that historic lesson in mind to avoid making the same mistakes again (what's the point of getting the specs faster into Rec stage if it takes longer to get them into "usable in real-world pages" stage?) 3) "Are you volunteering to...?" That kind of questions are, on the best case, an euphemism. If it weren't because it came from Boris, I'd take the last one even as an insult. Last time I checked, there are two ways to be part of the W3C process: - Be an employee of a W3C member company, and have that company commit your work time to contribute on the W3C work. - Become an "invited expert". That quite reminds me of the times when GMail was "invitational", and having a GMail account was a privilege. Who "invites" people to join the W3C work? How is "expertise" measured for potential invitees? Looking back at 1), it seems that we have figured out one of the bottlenecks on the W3C process: shortage of manpower, coupled with obstacles to acquire more manpower. Another bottleneck is the way specs are organized and advanced through the recommendation track. How long has passed since work on CSS Selectors Level 3 began until all major browsers implemented it? (hint: while MS has announced that IE9 will implement that module, this has yet to happen). In contrast, how fast are things like <canvas> or <section> being deployed? Maybe it's time to learn from HTML5's quite successful process, and incorporate some ideas of it into W3C's. Upon those arguments, I'm making here two orthogonal proposals, which are related mostly by the fact that they both attempt to address the causes of W3C slowness. This doesn't fit too well in the CSS-specific list, but it's derived from a thread here; and I don't know where else to post it; so here it goes and feel free to forward it to the appropriate place. Proposal #1: Facilitate participation on the W3C process. Sumary/Goals: - Allow volunteers to contribute on the tasks where bottlenecks are found (test suite development and spec text authoring seem to be the most prominent). - Make more clear and simple the requirements for joining the W3C work. - Ensure that the ability of and individual to contribute on a task is determine by the individual's suitability to the task, rather than by political/business factors such as employment status and the like, to the maximum possible and reasonable. Rationale: It's known that on many cases the specs stumble against non-technical walls through the recommendation track. Currently, it's fairly easy that two or more implementations of a feature survive the "real-world-usage" test, but still the spec lingers on LC stage while waiting for formal test-cases to be developed for them. On other cases, a desired feature can be well-known and even easily implementable, but the editors might fail to find an appropriate wording for it. It's not that unusual that a possible feature is easy to imagine and even describe in the abstract; but it turns to be very challenging to translate it to more formal language (a.k.a. spec-quality text). Also, it's quite common that people contribute really good ideas, but they fail to describe them in terms of use-cases and requirements. It's a huge hassle for the few editors to extract these details from the contributor's description. Specific details: - Create a "level" of contribution that doesn't involve so much bureaucracy to opt in for contributors. This could be called "External collaborator" or "External assistant". The key aspect is that it should require neither invitation nor specific employment status (after all, unemployed people probably have a lot more time to commit here ;) ). Reasonable requirements are: -> Have reached a minimum degree of participation on the mailing lists for the relevant specs (for example, these lists for the case of a CSS collaborator). -> WG members may object against a potential collaborator (for example, on the suspicion that it's a troll). Such objections should be voted by the WG, giving the Editor or the Chair the high vote in the event of ties. Specific details are up to the W3C. -> Ability/Commitment to participate on online meetings regularly. Ability to participate on F2F meetings should not be a requirement for these positions: many people may be suitable to undertake the collaborator role but still be unable to travel across the globe. Monthly meetings seem a reasonable frequency to me, but the details are up to the W3C and may probably vary between different WGs. - The role of External Collaborators is, in essence, to take away the bulk of the Editor's and WG member's work, allowing them to focus on supervising Collaborators and taking technical decisions; instead of spending so much time on interacting with so many contributors on the mailing lists. Specifically, External Collaborators would (each Collaborator might focus on different tasks): -> Translate informal feature requests from mailing list contributors into more formal draft update requests, by: 1) Gathering use-cases and requirements for the proposed feature; 2) Describing the feature with "spec-quality text"; and 3) Justifying that the feature, as described, addresses the use-cases and fulfills the requirements. -> Develop, collect, and formalize test cases from feature requirements, mailing list feedback, real-world feature usage (let's be careful with code copyright), and any other source. Also test the tests themselves, and document them (describe clearly what they are supposed to check, and what an implementation has to do to pass the test). -> Help warming down disputes on too heated debates. I don't remember anything too big on this list, but those of you who are also on the WHATWG's HTML5 mailing list will probably remember how the discussions about semantics/RDFa/microdata escalated into something close to open warfare. On that specific case, I admire how the editor politely handled the situation and calmly replied to even the most hostile posts. However, I don't think a spec editor should be left alone with such a task: it's handy to have a "reference authority" for these cases, but having to act as the teacher in the schoolyard prevents the editor focusing on the main editing tasks. A possible alternative could be to have some moderators on the lists; but mediating between conflicting sides seems a better approach than the warning and banning approach many discussion boards on the web take. - It seems that the ideal amount of collaborators for each working group would be something in the order of sqrt(community_size). So, for example, if a community has 900 members, the WG can directly interact with ~30 collaborators, and these would be interacting each with ~30 contributors on average. In any case, each group, each person, and each community are different, so this is just a very rough guideline, not a hard rule. This approach shouldn't prevent Editors and other WG members from interacting directly with the wider community; but should prevent them to have to deal directly with each message sent by each member, which is an insane amount of work for so few people. Proposal #2: Learning from the WHATWG process used for HTML5: Summary/Goals: The W3C process could take profit of some approaches taken by the HTML5 folks; without having to change too much of its current process. This should allow for similar benefits as those achieved on HTML5 work: faster implementation and clearer advancement through the recommendation track. Rationale: This very thread poses a great example: a feature that would be very cheap to specify and implement is stuck just because of how the W3C process work. The technical costs are very low, but the administrative ones are too high. This also hurts the ability of the community to get nearer to a consensus, since each part may place higher importance on either kind of costs. Hence some mechanism to reduce administrative costs of adopting new features (in general, improving the World Wide Web) could be highly useful. Specific details: On WHATWG's process, each feature of the spec advances independently through their equivalent to the "recommendation track". While this might not be too good to apply "as is" to specs produced by the W3C; it can be applied partially: - Up to the CR stage (included), let each feature advance independently through the track. Once a specific feature hits the "CR" state, it's already suitable for implementers to start working on it, regardless of how other features are doing. This means that implementation work can begin on the mature features while the immature ones are still unstable. - When all features within a spec have reached the CR status, the whole spec can be marked as a Candidate Recommendation, with the advantage that many of its features will probably be already implemented. - If most features within a spec reach CR status, but few others are holding the spec back, the WG will consider whether it's worth having the full spec waiting for them or let them fall back to the next iteration/version/level of the spec. - As soon as an iteration/version/level of a spec is on CR stage, the WG should be open to begin work on the next iteration. This doesn't mean that such work needs to begin immediately. For example, with CSS Selectors Level 3 already on PR stage, the CSS group should be open to proposals made for Selectors 4; but it's ok and reasonable to not commit too many resources to it while other CSS3 modules are still work in progress. It's possible that some people choke at the idea that, for example, Selectors 4 might reach CR stage before some modules of CSS3 reach even Last Call, but that would just reflect the dynamic nature of the web and the communities around it: there is probably more need for advanced selector features than for elaborate mathematical notation (after all, any document using CSS will be using selectors, while only a few of them will be using math-related features). If the W3C process' output has to be sped up, a will to sped things up is needed. Let's keep an open mind and remember that the future is only "future" until it becomes "past". I'm strongly convinced that these two proposals, used together, can provide a huge boost to the W3C process. Regards, Eduard Pascual
Received on Wednesday, 7 April 2010 17:56:51 UTC