- From: Peter Kasting <pkasting@google.com>
- Date: Thu, 23 Jul 2009 15:12:46 -0700
On Thu, Jul 23, 2009 at 2:48 PM, Manu Sporny <msporny at digitalbazaar.com>wrote: > contribute ideas: great! > scrutinize them: wonderful! > form consensus: fail (but that's what the W3C is for, right?) > produce: fail (unless we don't want to scale the community) > > Ian is really the only one that is actively allowed to produce anything > of significance in WHAT WG. In general, if he doesn't agree with you, it > doesn't go in. It's already been stated explicitly multiple times in the past that the HTML5 process is not ultimately consensus-driven, so this shouldn't be news to anyone. I for one consider that a feature, not a bug. I think it's fair to say that one needs to have a pretty > significant chunk of time on their hands as well as technical chops to > make a contribution to the HTML5 specification. Incorrect. All sorts of people have made contributions of small corrections, opinions on issues, spec proposals, etc. Ian has publicly committed to reply to every email and so far I see him doing precisely that; frequently this results in spec changes. When people's opinions are ultimately rejected, it is not without due consideration first. To approach the issue from another angle, we have roughly 1,000 members > on this mailing list and could have close to 1 billion people[1] that > could be using some form of HTML by 2012, a number of those are web > developers (read: a huge developer base). > > The Linux kernel mailing lists have close to 30,000 members[2], and I > don't think it's a stretch to say that there are fewer kernel developers > in the world (read: small developer base) than there are web developers > and designers. So, I've been wondering about the 30:1 discrepancy. You're comparing non-analogous situations. LKML is inherently of interest to all kernel developers, pretty much by definition. The HTML spec creation process is not inherently interesting to all web developers. A closer analogy would be to the engineers working on HTML support in UAs. I suspect that this mailing list _is_ inherently of interest to that group. We don't give anybody the impression here that they could directly impact the specification if they so > desired. If people sending emails containing proposals, and having the editor directly respond to all of those emails, frequently by changing the spec, does not give you the impression you can impact the specification, I'm not sure what would. I can git clone the Linux kernel, mess around with it and submit a patch > to any number of kernel maintainers. If that patch is rejected, I can > still share the changes with others in the community. Similarly, nothing prevents UA authors from coding any feature they wish and hoping it will gain traction. Similarly, nothing in the HTML5 process prevents anyone from proposing a feature that has been rejected by HTML5, and attempting to convince UA authors to support it directly. To the degree that these don't happen, it is because practical considerations make success unlikely: it is much more difficult for a random web developer to convince a vendor to support his idea in a particular UA than for a random coder to post a patch online alongside a modified kernel build. (However, it is not impossible: at least Firefox and Google Chrome can be built, as non-branded versions, from source by any interested party; and in fact that capability has been used for precisely the above purposes: see e.g. Iceweasel.) Similarly, people > that are creating user agents tend to not care about examples (in > general) Speaking as one of those people, you are completely mistaken. Examples are highly useful to UA authors. And implementation details are occasionally useful to web developers, insofar as they document expected behaviors very precisely and thus are useful when trying to test how real-world UA behaviors differ. I think the only valid point here is that web developers trying to read the spec directly probably want the "implementation details" as a reference rather than inline. They should be able to edit /something/ lasting, publish it for review, > and rise or fall on the merits and accuracy of their specification > language. They are not being given the opportunity to do so. Anyone can post a proposal anywhere on the web, which they themselves edit. If they want the imprimatur of the WHATWG, then it seems reasonably to expect that that proposal would have to be accepted by the editor(s) of that group. I'm not sure why there is a perceived lack of clarity here. Rejected proposals are always given concrete rationale for rejection (IMO). it > was meant as a feeler document to see how this community would react to > the proposed changes. For my part, I would be very unhappy to see the HTML5 process made more consensus-driven; I much prefer systems that approximate benevolent dictatorships, and I don't perceive the current leadership of the group to be insufficiently responsive to communication. PK -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090723/eddc098a/attachment-0001.htm>
Received on Thursday, 23 July 2009 15:12:46 UTC