WHATWG’s development model
You may be wondering just how do things work around here:
The process of writing the specs boils down to two general areas: defining the existing HTML language better and defining new features.
For defining the existing language better, the goal is to take the existing specs and reverse engineer the way existing browsers work and to do extensive research on existing documents to work out what the specs should say.
There are multiple aspects and phases to defining new features. Based on feedback from authors; what they are asking for that the existing specs lacked, forums, browser bug systems, common class names, support of features libraries like toolkits, the group tries to make a semantically clean, accessible, backwards-compatible solution - all while trying to remain consistent with the existing language.
You (yes, you!) are welcome to raise questions, concerns or leave comments on future WHATWG proposals by joining the mailing list; documented and wider reach, or join the live community at #whatwg channel on the freenode IRC network; hack and chat, or use the forums; perhaps less chaotic than the mailing list.
Just to give an idea on how all this works, we'll use the mailing list as an example on how a spec is defined in the proposal. Simply bring up an issue for a collective brainstorming session. It may seem confusing at first since there is no set structure in which these discussions take place, but note that the purpose of these open debates is to generate enough feedback where the community can refine the issue. The discussions in the mailing list are not meant to make a final decision on the issue but to clarify them. The editor then looks at all feedback and makes a decision on a spec.
If you keep this model in mind, it is not so chaotic after all.
defining new futures
Way to go, McFly!
Seems a little chaotic indeed. I wonder if an approach similar to that of the microformats process wouldn’t make more sense.