117 lines
5.7 KiB
Text
117 lines
5.7 KiB
Text
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
|
|
<!ENTITY % articles.ent PUBLIC "-//FreeBSD//ENTITIES DocBook FreeBSD Articles Entity Set//EN">
|
|
%articles.ent;
|
|
]>
|
|
|
|
<article>
|
|
<articleinfo>
|
|
<title>Working with Hats</title>
|
|
|
|
<authorgroup>
|
|
<author>
|
|
<firstname>Warner</firstname>
|
|
<surname>Losh</surname>
|
|
<contrib>Contributed by</contrib>
|
|
</author>
|
|
</authorgroup>
|
|
|
|
<pubdate>$FreeBSD$</pubdate>
|
|
|
|
<copyright>
|
|
<year>2002</year>
|
|
<year>2003</year>
|
|
<holder role="mailto:imp@FreeBSD.org">Warner Losh</holder>
|
|
</copyright>
|
|
</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>
|