52f6d56540
- Replace /XML/{doc,www}/ with /XML/ in SysId.
- Remove empty stylesheets in share/xsl and point share/xml/empty.xsl via
XML catalog instead.
- Change the L10N layer in freebsd-*.xsl not to use localized XSLT
stylesheets directly.
- Move share/xsl/* to share/xml and remove share/xsl.
- Remove obsolete share/web2c/pdftex.def.
108 lines
5.7 KiB
XML
108 lines
5.7 KiB
XML
<?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/share/xml/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>
|