A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.
To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).
What you can do: Difference between revisions
No edit summary |
No edit summary |
||
Line 4: | Line 4: | ||
* Write [[HTML5 tutorial|tutorials]] for new authors and for authors moving to HTML5. | * Write [[HTML5 tutorial|tutorials]] for new authors and for authors moving to HTML5. | ||
* Monitor and respond to questions on [http://www.whatwg.org/mailing-list#help the help list] and [http://forums.whatwg.org/ the forums]. | * Monitor and respond to questions on [http://www.whatwg.org/mailing-list#help the help list] and [http://forums.whatwg.org/ the forums]. | ||
* Maintain a document explaining the rationale of the decisions behind the spec. If you're interested in doing that, please e-mail Ian Hickson ([email protected]). '''This would be very popular. We get requests for this all the time. We just haven't found someone with the time to do it.''' | * Maintain a document explaining the rationale of the decisions behind the spec. If you're interested in doing that, please e-mail Ian Hickson ([email protected]). '''This would be very popular. We get requests for this all the time. We just haven't found someone with the time to do it.''' (See below for details.) | ||
* Help to edit the [[FAQ]]. | * Help to edit the [[FAQ]]. | ||
* Write [[test cases]]. | * Write [[test cases]]. | ||
Line 17: | Line 17: | ||
Then use the widget at the bottom right (it says "Click the location of the error to select it, then type your message here:") to submit review comments on the spec. The best review comments are those along the lines of questions you couldn't find the answer to. For example, say you wanted to find out what elements you could put in a <p> element, and you couldn't work it out. Then you would file a bug "I couldn't find the answer to the question 'What elements are allowed inside <p> elements'.". | Then use the widget at the bottom right (it says "Click the location of the error to select it, then type your message here:") to submit review comments on the spec. The best review comments are those along the lines of questions you couldn't find the answer to. For example, say you wanted to find out what elements you could put in a <p> element, and you couldn't work it out. Then you would file a bug "I couldn't find the answer to the question 'What elements are allowed inside <p> elements'.". | ||
== A rationale document == | |||
It basically would consist of watching the e-mail lists, the bugzilla | |||
bugs, and IRC, and chatting with Hixie, and then writing documentation to | |||
explain the thinking behind different parts of the spec — probably on this | |||
wiki somewhere. | |||
It could be as little work or as much work as you would want it to be. One | |||
could easily imagine this becoming a group effort. |
Revision as of 02:11, 29 April 2010
So you want to take part? You can!
- Review the specifications and send comments! (See below for details.)
- Write articles about HTML5 on the blog.
- Write tutorials for new authors and for authors moving to HTML5.
- Monitor and respond to questions on the help list and the forums.
- Maintain a document explaining the rationale of the decisions behind the spec. If you're interested in doing that, please e-mail Ian Hickson ([email protected]). This would be very popular. We get requests for this all the time. We just haven't found someone with the time to do it. (See below for details.)
- Help to edit the FAQ.
- Write test cases.
- Write demos (ideally in a Google Code project).
- Implement HTML5!
- Edit one of the many companion specifications that are lacking editors.
Sending feedback
The most useful thing from an authoring standpoint would be going through the spec and finding bits that don't make sense. Start with the authoring view:
http://whatwg.org/html?style=author
Then use the widget at the bottom right (it says "Click the location of the error to select it, then type your message here:") to submit review comments on the spec. The best review comments are those along the lines of questions you couldn't find the answer to. For example, say you wanted to find out what elements you could put in a <p> element, and you couldn't work it out. Then you would file a bug "I couldn't find the answer to the question 'What elements are allowed inside <p> elements'.".
A rationale document
It basically would consist of watching the e-mail lists, the bugzilla bugs, and IRC, and chatting with Hixie, and then writing documentation to explain the thinking behind different parts of the spec — probably on this wiki somewhere.
It could be as little work or as much work as you would want it to be. One could easily imagine this becoming a group effort.