diff --git a/en_US.ISO8859-1/articles/Makefile b/en_US.ISO8859-1/articles/Makefile
index 46e8e20a27..688669a66e 100644
--- a/en_US.ISO8859-1/articles/Makefile
+++ b/en_US.ISO8859-1/articles/Makefile
@@ -28,7 +28,6 @@ SUBDIR+= freebsd-questions
SUBDIR+= freebsd-update-server
SUBDIR+= geom-class
SUBDIR+= gjournal-desktop
-SUBDIR+= hats
SUBDIR+= hubs
SUBDIR+= ipsec-must
SUBDIR+= laptop
diff --git a/en_US.ISO8859-1/articles/hats/Makefile b/en_US.ISO8859-1/articles/hats/Makefile
deleted file mode 100644
index 070310e5a8..0000000000
--- a/en_US.ISO8859-1/articles/hats/Makefile
+++ /dev/null
@@ -1,16 +0,0 @@
-#
-# $FreeBSD$
-#
-# Article: Working with Hats
-
-DOC?= article
-
-FORMATS?= html
-
-INSTALL_COMPRESSED?=gz
-INSTALL_ONLY_COMPRESSED?=
-
-SRCS= article.sgml
-
-DOC_PREFIX?= ${.CURDIR}/../../..
-.include "${DOC_PREFIX}/share/mk/doc.project.mk"
diff --git a/en_US.ISO8859-1/articles/hats/article.sgml b/en_US.ISO8859-1/articles/hats/article.sgml
deleted file mode 100644
index de155281b1..0000000000
--- a/en_US.ISO8859-1/articles/hats/article.sgml
+++ /dev/null
@@ -1,121 +0,0 @@
-<?xml version="1.0" encoding="iso-8859-1" standalone="no"?>
-<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V4.2-Based Extension//EN"
- "../../../share/sgml/freebsd42.dtd" [
-<!ENTITY % entities PUBLIC "-//FreeBSD//ENTITIES DocBook FreeBSD Entity Set//EN" "../../share/sgml/entities.ent">
-%entities;
-]>
-
-<article lang='en'>
- <articleinfo>
- <title>Working with Hats</title>
-
- <authorgroup>
- <author>
- <firstname>Warner</firstname>
- <surname>Losh</surname>
- <contrib>Contributed by</contrib>
- </author>
- </authorgroup>
-
- <copyright>
- <year>2002</year>
- <year>2003</year>
- <holder role="mailto:imp@FreeBSD.org">Warner Losh</holder>
- </copyright>
-
- <pubdate>$FreeBSD$</pubdate>
-
- <releaseinfo>$FreeBSD$</releaseinfo>
- </articleinfo>
-
- <note>
- <para>This is not an official statement from core, but rather one
- core member's personal interpretation of core's position, both
- as a sitting member of core and as a former security
- officer. This is only a guideline, not as a cudgel for
- grievances. Much like &man.style.9; is a guideline for the
- source code, this document is not intended as an absolute
- straight jacket.</para>
- </note>
-
- <para>When core appoints someone to a hat, they expect that person
- to be responsible for an area of the source code tree. Core
- expects that person to be the final authority in that area of the
- tree, or have enough self knowledge to know that they are not and
- to seek qualified help. Core expects that person to guide
- development in that area of the tree. Sometimes this means taking
- an pro-active role in day to day affairs, while other times this
- means taking a reactive role in reviewing committed code.</para>
-
- <para>When people submit patches that potentially impact this area
- of the tree, core expects the hat or his appointed deputies to
- review the patches appropriately. Core expects that the hat will
- work with the patch submitter to correct issues that there may be
- with the patches. Core expects the hat to offer solutions and
- work with the submitter to reach a compromise. Core expects the
- hat to be courteous. It is reasonable for hats to request that
- normal project rules be followed when reviewing patches (e.g., that
- they generally conform to &man.style.9; or the prevailing style of the
- file, that style and content changes be separated.).</para>
-
- <para>When a dispute arises, core expects the hat to make his or her
- best efforts to compromise or otherwise resolve the dispute. The
- hat is expected to be courteous to all parties involved. In
- extreme cases, core recognizes that hats may need to wield a big
- stick and say <quote>no, that is not acceptable and cannot go in
- (or must be backed out).</quote> Core views this last power as one
- of last resort, and would frown on hats using that either too
- often or as the first response.</para>
-
- <para>Often real life interferes with a hat's ability to perform their duties. A
- condition that core generally imposes upon the hats of the world
- is that they have a deputy that can act in their absence. This
- deputy is expected to be an active participant in the team that
- the hat puts together and should be conversant with all the issues
- that surround the part of the tree that the hat is guiding. The
- deputy is expected to be able to act in the absence of the hat.
- For example, the security officer deputies send out security
- advisories when the SO is not around. In extreme cases, the
- deputy can defer an issue until the hat returns, but that is
- expected to be the exception rather than the rule, especially if
- the hat's return is far in the future.</para>
-
- <para>Hats are answerable to core. If they are doing good jobs,
- core will leave them alone. If they are doing a bad job, core has
- the option to remove them. Hats are expected to work with core if
- core has issues with their performance of their duties. They serve
- at the pleasure of core.</para>
-
- <para>Core sometimes will impose additional, specific requirements
- for a given hat that do not apply to all hats. These conditions
- may change over time.</para>
-
- <para>Committers and others working with hats are expected to use
- common sense, and be polite to the hats. They are expected to
- work with the hat and his team to come to a solution acceptable to
- everybody. In the event that no compromise can be reached, the
- committers are expected to accept the decisions of the hat with
- good grace. In exceptional cases, these decisions can be appealed
- to core. However, core generally will not override the decisions
- of the hats that it appoints unless the hat acted in bad faith or
- arbitrarily. Core is not a technical review board, and has
- created the hats as mini-TRBs to give dispute resolution a proper
- framework.</para>
-
- <para>If a committer feels that a hat is abusing his or her power,
- or being regularly rude to contributors, then they should bring
- the matter to core. This problem can be technical, social,
- procedural, or some combination or subset of these. Core will hear
- the case and reach a decision, and expects both sides to abide by
- their decision. Core appreciates specific complaints rather than
- general ones as those are easier to resolve.</para>
-
- <para>Core expects committers to work together in the appropriate
- mailing lists to resolve their issues. The hat and his team
- should be relatively rarely involved in their role as hat, and
- instead should usually be just another committer. (The one
- exception to this is the security officer hat, which needs to
- secretly solve vulnerabilities before they are announced.) The
- hat should be a <quote>first among equals,</quote> not a chairman.</para>
-
-</article>
diff --git a/en_US.ISO8859-1/htdocs/internal/Makefile b/en_US.ISO8859-1/htdocs/internal/Makefile
index 34f2c1ca39..ec16654774 100644
--- a/en_US.ISO8859-1/htdocs/internal/Makefile
+++ b/en_US.ISO8859-1/htdocs/internal/Makefile
@@ -25,6 +25,7 @@ DOCS+= policies.sgml
DOCS+= releng.sgml
DOCS+= resources.sgml
DOCS+= statistic.sgml
+DOCS+= working-with-hats.sgml
INDEXLINK= internal.html
diff --git a/en_US.ISO8859-1/htdocs/internal/internal.sgml b/en_US.ISO8859-1/htdocs/internal/internal.sgml
index 1bbebea1ab..67e67b731e 100644
--- a/en_US.ISO8859-1/htdocs/internal/internal.sgml
+++ b/en_US.ISO8859-1/htdocs/internal/internal.sgml
@@ -55,6 +55,10 @@ the globe, there have to be some
hosted at FreeBSD.org, as well as some
<a href="../multimedia/tag-photos.html">photos from social events</a>.</p>
+<p>You can read here core's <a href="hats.sgml">Hat Term Limits Policy</a>
+ and some guidelines from &a.imp; on <a href="working-with-hats.sgml">how
+ to work with hats</a>.</p>
+
<h2>Resources</h2>
<p>Here is a list of some
diff --git a/en_US.ISO8859-1/htdocs/internal/working-with-hats.sgml b/en_US.ISO8859-1/htdocs/internal/working-with-hats.sgml
new file mode 100644
index 0000000000..d7a507a27a
--- /dev/null
+++ b/en_US.ISO8859-1/htdocs/internal/working-with-hats.sgml
@@ -0,0 +1,108 @@
+<?xml version="1.0" encoding="iso-8859-1"?>
+<!DOCTYPE html PUBLIC "-//FreeBSD//DTD XHTML 1.0 Transitional-Based Extension//EN"
+"http://www.FreeBSD.org/XML/doc/share/sgml/xhtml10-freebsd.dtd" [
+<!ENTITY title "Working with Hats">
+]>
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <title>&title;</title>
+
+ <cvs:keyword xmlns:cvs="http://www.FreeBSD.org/XML/CVS">$FreeBSD$</cvs:keyword>
+ </head>
+
+ <body class="navinclude.docs">
+
+ <p>&a.imp;, member of the core team as of the writing of the lines
+ below, points out the following considerations and practices
+ when working with hats:</p>
+
+ <p>This is not an official statement from core, but rather one
+ core member's personal interpretation of core's position, both
+ as a sitting member of core and as a former security
+ officer. This is only a guideline, not as a cudgel for
+ grievances. Much like style(9) is a guideline for the
+ source code, this document is not intended as an absolute
+ straight jacket.</p>
+
+ <p>When core appoints someone to a hat, they expect that person
+ to be responsible for an area of the source code tree. Core
+ expects that person to be the final authority in that area of the
+ tree, or have enough self knowledge to know that they are not and
+ to seek qualified help. Core expects that person to guide
+ development in that area of the tree. Sometimes this means taking
+ an pro-active role in day to day affairs, while other times this
+ means taking a reactive role in reviewing committed code.</p>
+
+ <p>When people submit patches that potentially impact this area
+ of the tree, core expects the hat or his appointed deputies to
+ review the patches appropriately. Core expects that the hat will
+ work with the patch submitter to correct issues that there may be
+ with the patches. Core expects the hat to offer solutions and
+ work with the submitter to reach a compromise. Core expects the
+ hat to be courteous. It is reasonable for hats to request that
+ normal project rules be followed when reviewing patches (for example,
+ that they generally conform to style(9) or the prevailing style of the
+ file, that style and content changes be separated.).</p>
+
+ <p>When a dispute arises, core expects the hat to make his or her
+ best efforts to compromise or otherwise resolve the dispute. The
+ hat is expected to be courteous to all parties involved. In
+ extreme cases, core recognizes that hats may need to wield a big
+ stick and say "no, that is not acceptable and cannot go in
+ (or must be backed out)." Core views this last power as one
+ of last resort, and would frown on hats using that either too
+ often or as the first response.</p>
+
+ <p>Often real life interferes with a hat's ability to perform their
+ duties. A condition that core generally imposes upon the hats of
+ the world is that they have a deputy that can act in their absence.
+ This deputy is expected to be an active participant in the team that
+ the hat puts together and should be conversant with all the issues
+ that surround the part of the tree that the hat is guiding. The
+ deputy is expected to be able to act in the absence of the hat.
+ For example, the security officer deputies send out security
+ advisories when the SO is not around. In extreme cases, the
+ deputy can defer an issue until the hat returns, but that is
+ expected to be the exception rather than the rule, especially if
+ the hat's return is far in the future.</p>
+
+ <p>Hats are answerable to core. If they are doing good jobs,
+ core will leave them alone. If they are doing a bad job, core has
+ the option to remove them. Hats are expected to work with core if
+ core has issues with their performance of their duties. They serve
+ at the pleasure of core.</p>
+
+ <p>Core sometimes will impose additional, specific requirements
+ for a given hat that do not apply to all hats. These conditions
+ may change over time.</p>
+
+ <p>Committers and others working with hats are expected to use
+ common sense, and be polite to the hats. They are expected to
+ work with the hat and his team to come to a solution acceptable to
+ everybody. In the event that no compromise can be reached, the
+ committers are expected to accept the decisions of the hat with
+ good grace. In exceptional cases, these decisions can be appealed
+ to core. However, core generally will not override the decisions
+ of the hats that it appoints unless the hat acted in bad faith or
+ arbitrarily. Core is not a technical review board, and has
+ created the hats as mini-TRBs to give dispute resolution a proper
+ framework.</p>
+
+ <p>If a committer feels that a hat is abusing his or her power,
+ or being regularly rude to contributors, then they should bring
+ the matter to core. This problem can be technical, social,
+ procedural, or some combination or subset of these. Core will hear
+ the case and reach a decision, and expects both sides to abide by
+ their decision. Core appreciates specific complaints rather than
+ general ones as those are easier to resolve.</p>
+
+ <p>Core expects committers to work together in the appropriate
+ mailing lists to resolve their issues. The hat and his team
+ should be relatively rarely involved in their role as hat, and
+ instead should usually be just another committer. (The one
+ exception to this is the security officer hat, which needs to
+ secretly solve vulnerabilities before they are announced.) The
+ hat should be a "first among equals," not a chairman.</p>
+ </body>
+</html>