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

- Move the hats article to internal/ [1]

Browse source 
- Add a link to the new page and another one to core's hat term limits
  policy while here

Discussed with:	imp [1]
This commit is contained in:
Gabor Kovesdan 2012-09-20 09:34:39 +00:00
parent 73d15e8512
commit b1b33d86a4
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=39584
6 changed files with 113 additions and 138 deletions

1
en_US.ISO8859-1/articles/Makefile
View file

@ -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

16
en_US.ISO8859-1/articles/hats/Makefile
View file

@ -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"

121
en_US.ISO8859-1/articles/hats/article.sgml
View file

@ -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>

1
en_US.ISO8859-1/htdocs/internal/Makefile
View file

@ -25,6 +25,7 @@ DOCS+= policies.sgml
DOCS+= releng.sgml
DOCS+= resources.sgml
DOCS+= statistic.sgml
DOCS+= working-with-hats.sgml
INDEXLINK= internal.html

4
en_US.ISO8859-1/htdocs/internal/internal.sgml
View file

@ -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

108
en_US.ISO8859-1/htdocs/internal/working-with-hats.sgml Normal file
View file

@ -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>