os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Update policy on documentation fixes.

Browse source 
Discussed with: doceng
This commit is contained in:
Hiroki Sato 2004-08-21 08:27:46 +00:00
parent 5e4bb60b6c
commit f4ae35c6d7
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/www/; revision=22038
1 changed files with 38 additions and 6 deletions

44
en/releases/5.3R/policy.sgml
View file

@ -1,7 +1,7 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" [
<!ENTITY base CDATA "../..">
<!ENTITY email 'freebsd-qa'>
<!ENTITY date "$FreeBSD: www/en/releases/5.3R/policy.sgml,v 1.1 2004/08/19 06:53:01 scottl Exp $">
<!ENTITY date "$FreeBSD: www/en/releases/5.3R/policy.sgml,v 1.2 2004/08/19 18:49:13 scottl Exp $">
<!ENTITY local.rel "5.3">
<!ENTITY local.rel.tag "5_3">
<!ENTITY title "FreeBSD &local.rel; Code Freeze Policy">
@ -80,11 +80,43 @@
<h2>Documentation fixes</h2>
<p>These are defined as changes to existing documentation in manual pages,
release notes, and doc articles and books. This does <b>not</b> 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.</p>
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.</p>
<h3>Documentation fixes for the src/ tree</h3>
<p>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.</p>
<h3>Documentation fixes for the doc/ tree</h3>
<p>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.</p>
<h3>Translations</h3>
<p>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.</p>
<h2>Feature additions and modifications</h2>
<p>These are defined as changes that add new features to the system or