                               Working with Hats

  Warner Losh

   Copyright (c) 2002 by Warner Losh

   $FreeBSD: doc/en_US.ISO8859-1/articles/hats/article.sgml,v 1.4 2002/08/31
   16:42:19 keramida Exp $

     ----------------------------------------------------------------------

     Note: 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.

   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.

   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 style(9) or the prevailing
   style of the file, that style and content changes be separated, etc).

   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.

   Often times real life happens in the life of a hat. 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.

   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.

   Core sometimes will impose additional, specific requirements for a given
   hat that does not apply to all hats. These conditions may change over
   time.

   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.

   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.

   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.

     ----------------------------------------------------------------------

               This, and other documents, can be downloaded from
                    ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

     For questions about FreeBSD, read the documentation before contacting
                            <questions@FreeBSD.org>.
       For questions about this documentation, e-mail <doc@FreeBSD.org>.
