What you can do

So you want to take part? You can!

• Review the specifications and send comments! (See below for details.)
• Write articles for our blog.
• Write tutorials for new authors.
• Monitor and respond to questions on the help list and the forums.
• Maintain the document explaining the rationale of the decisions behind the spec. (See below for details.)
• Help to edit the FAQ.
• Write test cases.
• Write cool demos.
• Implement HTML!
• Edit one of the many companion specifications that are lacking editors.

Sending feedback

The most useful thing would be going through the spec and finding bits that don't make sense.

http://whatwg.org/html

You can 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.

How you can improve HTML

This is the text of an article Hixie wrote.

Are you trying to do something on the Web that you find you can't do because HTML simply doesn't have a way to do it?

With your help, we can improve HTML, add a feature to address your problem, and in five to ten years you'll finally be able to do it!

Here's how:

First, write a description of the problem. What are you trying to do? This should be a high-level description. One way to see if you're describing it at a high enough level is to consider whether your description makes as much sense for a Web developer as it does for, say, a mobile phone native app developer. So if your description talks about HTML elements or JavaScript or HTTP headers, then it's probably too low level. If it talks about what a user sees, how a user interacts with a computer or device, or how a user uses a computer or device to create some sort of content or effect some sort of change, then you're on the right path. If you hear people referring to "use cases", it is to this problem description that they refer.

In particular, your description should not be a solution. Don't propose new elements or attributes, new APIs, new semantics, new features. The time for discussions of solutions is later.

Next, do one or more of the following with this description:

0. Discuss the topic on our IRC channel (#whatwg on Freenode) to see if you've missed anything obvious

1. Post it to [email protected]

2. Post it on http://forums.whatwg.org/

3. Visit our IRC channel (#whatwg on Freenode) and ask for help posting it on our blog at http://blog.whatwg.org/

4. Post it as a bug report at http://whatwg.org/newbug (you'll need to create an account)

Participate in any resulting discussions. Post a link to your e-mail, forum post, blog post, or bug report to your own blog or to other social media sites to encourage others to participate. For best results, I recommend that you avoid creating new places for the discussion to occur (e.g. new mailing lists, wiki pages, or working groups). Keeping the discussions in existing places ensures that experience participants will see your discussions and will be able to lend you their experience. The most important part of these discussions is clarifying how common the problem is, what related problems other people have that could maybe be addressed at the same time, and what work-arounds exist to avoid the problem.

Ideally, some browser vendors will at this point start commenting on the problem, hopefully saying that they agree that it's a problem. Getting browser vendors to believe there's a problem is the second best thing that you can do to ensure your problems gets solved. (The best thing that can happen is for browser vendors to implement a solution. See notes below.) Once you have browser vendors buying-in to the problem's importance, you can start talking about possible solutions. (You don't have to, though, and there's no guarantee that the solutions you propose will be adopted rather than some other ones.)

If you posted on the forums or on the blog, then once the discussion has settled down, ask for someone (e.g. zcorpan, for the forums, or whoever you spoke to on IRC, for the blog) to forward your proposal to the main [email protected] mailing list. This will get the topic onto my (Hixie's) radar. (Bugs are all already also on the radar, so you don't have to worry about those.)

Eventually, I will see the e-mail(s) or bug. This can take a few months, because there's a lot of feedback to go through. I then take all the information in the thread, related forum posts and blog posts, and anything else I can find; I sometimes talk to browser vendors, bring the topic up on IRC for some sanity checking with whoever is online, etc. And then I write a reply to all the e-mails, and possibly update the spec accordingly. Lather, rinse, repeat.

You may ask why browser vendors have a prominent role in this process. The answer is simple. The specification is not magical; it cannot force browser vendors to do anything they don't want to do. If I write something in the spec and they don't implement it, there's nothing we can do: the feature doesn't really exist, it's just fiction, and we've all wasted our time. To avoid wasting my time, I try to work with the browser vendors to make sure that what I specify is something they're willing to implement. (It doesn't always work out that way, but then after a while I update the spec to match what they did do, or didn't do, e.g. removing things that nobody has implemented.)

If you want to participate in the process in ways other than reporting problems you find with the Web, there are various things you can do: participate in discussions on the mailing list, forums, blog, or bug system; chat with us on IRC (#whatwg on Freenode); write test cases; write tutorials; review the spec... The best place to start is to join us on IRC and ask what you can do.

We also have a FAQ: http://wiki.whatwg.org/wiki/FAQ