Most document style policies are established simply by using the provided documentation framework. However, by applying some conventions to the document source structure, community members will be able to work across more d ocumentation projects. The recommended documentation structure guidelines are as follows: The head book file should be named with the prefix "bk_". The document versioning as defined by the <releaseinfo> tag in the main book file bk_xxx should be named "Revision V.R.M", not "Version V.R.M" or simply "V.R.M" where: Significant updates increment the V (Version) value while reseting the R and M values to 0, Material, but small, updates increment the R (Release) value and reset the M to 0, and Trivial updates (such as typos and grammatical changes) only need to increment the M (Modifier) value. Numbering of "pre-release" versions or draft versions of a document may be handled in multiple ways such as incrementing the previous modifier level until publication and then updating appropriately, setting the releases to the anticipated level and then appending a "_preN" suffix where "N" can be incremented during drafting. Each Work Group may set their own policy here. Chapters files should be named with the prefix "ch_". Section and sub-section files should be named with the prefix "sec_". Appendix files should be named with the prefix "app_". Figures source and images should be placed in the figures sub-directory for the document. Releases of the same document sound be contained in the same tree, but tagged at levels of interest using the git tag command. See the for more specifics on git commands. In addition to documentation structure, general community/project guidelines are as follows: Contributions to the documentation projects should conform to the Developer Certificate Of Origin as defined at http://elinux.org/Developer_Certificate_Of_Origin. Commits to the GitHub project need to contain the following line to indicate the submitter accepts the DCO:Signed-off-by: Your name <your_email@domain.com>