svn commit: r39584 - in head/en_US.ISO8859-1: articles
articles/hats htdocs/internal
Gabor Kovesdan
gabor at FreeBSD.org
Thu Sep 20 09:34:40 UTC 2012
Author: gabor
Date: Thu Sep 20 09:34:39 2012
New Revision: 39584
URL: http://svn.freebsd.org/changeset/doc/39584
Log:
- Move the hats article to internal/ [1]
- Add a link to the new page and another one to core's hat term limits
policy while here
Discussed with: imp [1]
Added:
head/en_US.ISO8859-1/htdocs/internal/working-with-hats.sgml (contents, props changed)
Deleted:
head/en_US.ISO8859-1/articles/hats/
Modified:
head/en_US.ISO8859-1/articles/Makefile
head/en_US.ISO8859-1/htdocs/internal/Makefile
head/en_US.ISO8859-1/htdocs/internal/internal.sgml
Modified: head/en_US.ISO8859-1/articles/Makefile
==============================================================================
--- head/en_US.ISO8859-1/articles/Makefile Thu Sep 20 01:26:24 2012 (r39583)
+++ head/en_US.ISO8859-1/articles/Makefile Thu Sep 20 09:34:39 2012 (r39584)
@@ -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
Modified: head/en_US.ISO8859-1/htdocs/internal/Makefile
==============================================================================
--- head/en_US.ISO8859-1/htdocs/internal/Makefile Thu Sep 20 01:26:24 2012 (r39583)
+++ head/en_US.ISO8859-1/htdocs/internal/Makefile Thu Sep 20 09:34:39 2012 (r39584)
@@ -25,6 +25,7 @@ DOCS+= policies.sgml
DOCS+= releng.sgml
DOCS+= resources.sgml
DOCS+= statistic.sgml
+DOCS+= working-with-hats.sgml
INDEXLINK= internal.html
Modified: head/en_US.ISO8859-1/htdocs/internal/internal.sgml
==============================================================================
--- head/en_US.ISO8859-1/htdocs/internal/internal.sgml Thu Sep 20 01:26:24 2012 (r39583)
+++ head/en_US.ISO8859-1/htdocs/internal/internal.sgml Thu Sep 20 09:34:39 2012 (r39584)
@@ -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
Added: head/en_US.ISO8859-1/htdocs/internal/working-with-hats.sgml
==============================================================================
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/en_US.ISO8859-1/htdocs/internal/working-with-hats.sgml Thu Sep 20 09:34:39 2012 (r39584)
@@ -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>
More information about the svn-doc-all
mailing list