At some point, the number of conventions and agreements floating around in your project may become so great that you need to record it somewhere. In order to give such a document legitimacy, make it clear that it is based on mailing list discussions and on agreements already in effect. As you compose it, refer to the relevant threads in the mailing list archives, and whenever there’s a point you’re not sure about, ask again. The document should not contain any surprises: it is not the source of the agreements, it is merely a description of them. Of course, if it is successful, people will start citing it as a source of authority in itself, but that just means it reflects the overall will of the group accurately.

…

Don’t try to be comprehensive. No document can capture everything people need to know about participating in a project. Many of the conventions a project evolves remain forever unspoken, never mentioned explicitly, yet adhered to by all. Other things are simply too obvious to be mentioned, and would only distract from important but non-obvious material. For example, there’s no point writing guidelines like “Be polite and respectful to others on the mailing lists, and don’t start flame wars,” or “Write clean, readable bug-free code.” Of course these things are desirable, but since there’s no conceivable universe in which they might not be desirable, they are not worth mentioning. If people are being rude on the mailing list, or writing buggy code, they’re not going to stop just because the project guidelines said to. Such situations need to be dealt with as they arise, not by blanket admonitions to be good.

— Karl Fogel, Producing Open Source Software