These are defined as changes to existing documentation in manual pages, release notes, and doc articles and books. This does not generally - include comments in source files. Documentation fixes must have a PR - number and are encouraged to have a review. Changes that are widespread - or cover significant technical information should be reviewed without - exception. All changes must be vetted through that parent branch for 2 - days.
+ include comments in source files. Documentation fixes are classified into + trivial and content fixes. + Trivial fixes are defined as changes which do not need a technical review + such as fixing a typo, wording, markup error, and so on. + Content fixes are defined as ones which need a technical review, + such as changes to the contents of documentation and build infrastructure. + +All changes must be committed to the parent branch first, + vetted through that branch for 2 days. + Content fixes must be sent with a PR number when the changes + are large or involve one of the TODO items (these are periodically + posted to the freebsd-doc@ mailing list during the release cycle, + and should also be filed as PRs). When the changes are self-explaining, send + them to re@ as an MFC request. + Changes that are widespread or cover significant technical information + should be reviewed without exception.
+ +Similar policy is applied to the doc/ tree, + but since doc/ is not branched and is not frozen, trivial fixes + are allowed to be committed without explicit approval before BETA4. + Content fixes must be committed with a PR number when the changes + are large or involve one of the TODO items (these are periodically + posted to the freebsd-doc@ mailing list during the release cycle, + and should also be filed as PRs). When the changes are self-explaining, you can + commit them into the doc/ tree. When you are not sure if + committing your patch without approval is reasonable or not, + please ask doceng@. Documentation Engineering Team + reserves the right to reject and back out your change. + After BETA4, doc/ slush begins and non-critical + changes to English documents are discouraged.
+ +The above two policies also apply to translations, + but all changes are considered as trivial changes during + the period before the doc/ slush is over.
These are defined as changes that add new features to the system or