doc/en_US.ISO8859-1/articles/hats/article.sgml

<!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 (eg, that
    they generally conform to &man.style.9; or the prevailing style of the
    file, that style and content changes be separated, etc).</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 does 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>