I didn't see this started elsewhere, so I thought I would give it a shot.
Perhaps while it's being worked out, not yet posted as the official FAQ, we can even point people to this meta post. That way they can at least read what's here and get some direction.
Please limit each answer to one FAQ topic.
On-topic and Off-topic Questions
{On-topic}
{Off-topic}
See this thread for the examples compiled so far.
My comments above got so long that I think they fit better as an actual answer.
The answers to this so far seem to indicate a desire to make our FAQ as comprehensive as possible so that new users have an easier time. This assumption, that an all-encompassing FAQ makes things easier, is false.
First, I speak as a person with a fair amount of knowledge in software usability. My degree had a strong focus on human-computer interaction and usability engineering. I've used and expanded this knowledge professionally. I don't intend this to be interpreted as some type of trump card that makes my opinion "better", but rather an indicator that I'm not just pulling it out of thin air. (I still consider myself "just a developer" and don't have a "usability engineer" title.)
I'm going to drastically over-simplify our sites user-base into two demographics:
Regular users - These users have below-average to average familiarity and experience with computers, the web, and online forums/wikis
Power users - These users have above-average to expert familiarity and experience with computers and all things web
Now, a scenario:
Robert, a regular user, has a question. Robert, however, has not read the FAQ, and quite possibly doesn't even know what a FAQ is. Robert will do one of two things: (1) make a decision/assumption and go forward or (2) ask for support/guidance. In either scenario Robert will be given an answer by another member of the community, either in the form of a direct answer or as a correction to whatever erroneous assumption he may have made (if his assumption/decision was correct it will go unnoticed and he will subsequently continue to do this correct action).
Now, what happens after the scenario:
Robert will almost always (at least more often than not) say, "This should be in the manual/FAQ/somewhere", oblivious to the fact that he never read it in the first place. Robert thinks that because he had a question it must be common/frequent enough to warrant being in the FAQ. This is just normal human egocentric behavior. However, Robert ignores the fact that he never read the FAQ/manual in the first place. Robert isn't even the type that enjoys doing that. He has a very low threshold for when he deems something too complicated to bother with, yet he advocates adding complication to said document.
Now, a scenario for a power user:
Pamela is a power user. Pamela likely has read the FAQ, or at least has enough general web/forum knowledge and experience to make educated guesses. Pamela, being a typical egocentric human, has assumptions and expectations that other users, including Robert have read the FAQ, or will read it when directed to. Pamela will tend to see a question and do one of two things: (1) if the question is new, answer it or (2) if the question is in the FAQ, direct the user to read the FAQ.
Now, after this scenario:
Pamela has foresight. She can see other new users asking Robert's question again. She comes to the conclusion that Robert's question should be added to the FAQ so that future Roberts don't need to ask the question. Pamela has a high tolerance for web complexities and can thus tolerate, and read (enjoyably) a comprehensive FAQ.
Letting this scenario play out over time will lead to a larger, more comprehensive FAQ/manual that is read by an increasingly smaller population of both Roberts and Pamelas. Robert, because he never read it in the first place, and when directed to a document of increasing complexity is less likely to even when directed. Pamela, because as the complexity increases the subset of Pamelas willing to read this decreases.
If you'll look at the StackOverflow FAQ you'll see that is very minimalist. It answers the very high level questions covering only the basics of how to get started using the site. It closes with a link to a more comprehensive set of FAQs which are housed on the meta site. This is the proper solution for both Pamela and Robert. The information is appropriately minimal enough that Robert will read it, at least when directed to it, and has a link to more comprehensive FAQs which a subset of Roberts will follow, or at least remember is there, giving them a pseudo-Pamela familiarity with the site. Pamela is much more likely to follow this link as well, and tolerate the added complexity/verbosity, or at least remember that it exists for future reference.
We already have the tools in place to manage our own community-editable FAQ: the meta site. The [faq] tag is intended to serve this purpose, it's even highlighted differently to stand out from other tags. Additionally, the search functionality searches the questions and answers of the site, not the FAQ. We should be encouraging as many of our users as possible to feel comfortable coming to the meta site to ask their questions instead of increasing the amount of knowledge they are "expected" to have. (While not expressly intended, the FAQ does imply that a user should know what's in the FAQ at least).
Encouraging users to ask in meta, or at least directing them to a meta FAQ that has already been asked reinforces their participation in the meta site. This reinforcement is invaluable because it translates to a larger percentage of community participation in the meta, as opposed to a "select few".
The ability to manage our own FAQs using meta, with all the feedback tools provided, is simply better than a rigid FAQ that requires super-moderator (Jeff, Robert, etc.) intervention to change.
[faq] tag to questions on meta.
All this points to a need for two levels of FAQ, as has been suggested here. So, something like:
FAQ (the one linked to at the top of every screen) High-level overview of SE, like the one linked to at the top of every page
The Manual, a more detailed FAQ than the regular one for users new to the site (and probably new to SE). It can be called anything, but it's be good to avoid using "FAQ" in the title to avoid confusion. Perhaps call this the Site Cookbook.
Whatever solution the community adopts, it should avoid duplication with existing resources where at all possible to avoid errors due to transcription or site updates.
Accepting Answers
If you're satisfied with one of the answers to your question, click the green check-mark to the left of the answer. You don't have to choose the answer with the most votes if it's not your favorite. You don't have to accept an answer for every question. There's a time limit before you are allowed to accept an answer.
Communicating With Users
Communication is encouraged, but not in answers themselves. Underneath each answer is a space to add comments. If you want to get a user's attention, put @ in front of their name, and they will be notified (@topchef Great idea!). If people have left you a message, the envelope at the top of the site next to your name will glow yellow.
Extended discussion about the site itself happen on Meta. Click the link in the menu-bar at the top of the site to go there. (Click the same link that says 'parent' to get back). The url is http://meta.cooking.stackexchange.com.
Using Tags
A tag is a label that groups a question with other similar questions. You can put up to 5 on each question. Combine multiple-word tags with dashes (french-cuisine, storage-method). Separate tags with spaces, commas, or semi-colons.
Favor existing and popular tags over creating new tags. Don't use synonyms; just pick one. Don't use tags which discuss the type of question (discussion, beginner, opinion) instead of the content (bread, baking, flour).
Question Status
Occasionally question will be problematic. A protected question isn't open to low-reputation users. A locked question is not open to any users except for answer-voting. A closed question will not accept answers and doesn't effect reputation.
:note, this is close, but probably needs clarification