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

From WHATWG Wiki
Jump to navigation Jump to search
(update this page as the rationale document now exists)
(less HTML5, fixing a few links)
Line 1: Line 1:
So you want to take part? You can!
So you want to take part? You can!
* Review [http://whatwg.org/specs/ the specifications] and [http://whatwg.org/mailing-list#specs send comments]! (See below for details.)
* Review [http://whatwg.org/specs/ the specifications] and [http://whatwg.org/mailing-list#specs send comments]! (See below for details.)
* Write articles about HTML5 on the [http://blog.whatwg.org/ blog].
* Write articles for our [http://blog.whatwg.org/ blog].
* Write [[HTML5 tutorial|tutorials]] for new authors and for authors moving to HTML5.
* Write [[Authoring|tutorials]] for new authors.
* 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 the document explaining the [[rationale]] of the decisions behind the spec. (See below for details.)
* Maintain the document explaining the [[rationale]] of the decisions behind the spec. (See below for details.)
* Help to edit the [[FAQ]].
* Help to edit the [[FAQ]].
* Write [[test cases]].
* Write [[test cases]].
* Write [[demos]] (ideally in a Google Code project).
* Write cool demos.
* [[Implementations|Implement HTML5]]!
* [[:Category:Implementations|Implement HTML]]!
* Edit one of the many [[companion specifications]] that are lacking editors.
* Edit one of the many [[companion specifications]] that are lacking editors.


Line 18: Line 18:
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'.".


'''See also [[Reviewing HTML5]].'''
'''See also [[Reviewing]].'''


== A rationale document ==
== A rationale document ==


It basically would consist of watching the e-mail lists, the bugzilla
It basically would consist of watching the e-mail lists, the Bugzilla
bugs, IRC, and chatting with Hixie, and then writing documentation to
bugs, asking questions on [[IRC]], and then writing documentation to
explain the thinking behind different parts of the spec on the [[rationale]] page.
explain the thinking behind different parts of the spec on the [[rationale]] page.


It could be as little work or as much work as you would want it to be. One
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.
could easily imagine this becoming a group effort.

Revision as of 08:29, 26 January 2011

So you want to take part? You can!

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'.".

See also Reviewing.

A rationale document

It basically would consist of watching the e-mail lists, the Bugzilla bugs, asking questions on IRC, and then writing documentation to explain the thinking behind different parts of the spec on the rationale page.

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.