2
0
mirror of https://github.com/boostorg/website.git synced 2026-01-19 16:52:15 +00:00
Files
website/community/policy.html
2024-09-01 08:56:16 -07:00

467 lines
22 KiB
HTML

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<title>Boost Discussion Policy</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<link rel="icon" href="/favicon.ico" type="image/ico" />
<link rel="stylesheet" type="text/css" href=
"/style-v2/section-community.css" />
<!--[if IE 7]> <style type="text/css"> body { behavior: url(/style-v2/csshover3.htc); } </style>
<![endif]-->
<script defer data-domain="original.boost.org" src="https://plausible.io/js/script.js"></script></head><!--
Note: Editing website content is documented at:
https://www.boost.org/development/website_updating.html
-->
<body>
<div id="heading">
<!--#include virtual="/common/heading.html" -->
</div>
<div id="body">
<div id="body-inner">
<div id="content">
<div class="section" id="intro">
<div class="section-0">
<div class="section-title">
<h1>Boost Discussion Policy</h1>
</div>
<div class="section-body">
<p>Email discussion is the tie that binds boost members
together into a community. If the discussion is stimulating and
effective, the community thrives. If the discussion degenerates
into name-calling and ill will, the community withers and
dies.</p>
<ul class="toc">
<li><a href="#acceptable">Acceptable Topics</a></li>
<li><a href="#unacceptable">Unacceptable Topics</a></li>
<li><a href="#effective">Effective Posting</a><ul class="toc">
<li><a href="#well-crafted">Well-Crafted Posting is Worth the Effort</a></li>
<li><a href="#subject-line">Put the Library Name in the Subject Line</a></li>
<li><a href="#tabs">Don't Use Tabs</a></li>
<li><a href="#longlines">Limit Line
Length</a></li>
<li><a href="#quoting">Don't Overquote, Don't Top-Post, and Do
Use Inline Replies for Readable Quotations</a></li>
<li><a href="#formatting-quotations">Keep the Formatting of Quotations Consistent</a></li>
<li><a href="#summarizing-referring">Summarizing and Referring to Earlier Messages</a></li>
<li><a href="#discussion-threads">Maintain the Integrity of Discussion Threads</a></li>
<li><a href="#max-size">Keep The Size of Your Posting Manageable</a></li>
<li><a href="#email-footers">Avoid Corporate and Confidentiality Footers in Your Emails</a></li>
</ul>
</li>
<li><a href="#behavior">Prohibited Behavior</a><ul class="toc">
<li><a href="#flame-wars">Flame wars</a></li>
<li><a href="#third-party-attacks">Third-party attacks</a></li>
<li><a href="#off-topic-posts">Off-topic posts</a></li>
</ul>
</li>
<li><a href="#culture">Culture</a></li>
<li><a href="#effective-discussions">Guidelines for Effective Discussions</a></li>
<li><a href="#lib_names">Library Names</a></li>
</ul>
<h2><a name="acceptable" id="acceptable"></a>Acceptable
topics</h2>
<ul>
<li>Queries to determine interest in a possible library
submission.</li>
<li>Technical discussions about a proposed or existing
library, including bug reports and requests for help.</li>
<li>Formal Reviews of proposed libraries.</li>
<li>Reports of user experiences with Boost libraries.</li>
<li>Boost administration or policies.</li>
<li>Compiler specific workarounds as applied to Boost
libraries.</li>
</ul>
<p>Other topics related to boost development may be acceptable,
at the discretion of moderators. If unsure, go ahead and post.
The moderators will let you know.</p>
<h2><a name="unacceptable" id="unacceptable"></a>Unacceptable
Topics</h2>
<ul>
<li>Advertisements for commercial products.</li>
<li>Requests for help getting non-boost code to compile with
your compiler. Try the comp.lang.c++.moderated newsgroup
instead.</li>
<li>Requests for help interpreting the C++ standard. Try the
comp.std.c++ newsgroup instead.</li>
<li>Job offers.</li>
<li>Requests for solutions to homework assignments.</li>
</ul>
<h2><a name="effective" id="effective"></a>Effective
Posting</h2>
<p>Most Boost mailing lists host a great deal of traffic, so
your post is usually competing for attention with many other
communications. This section describes how to make sure it has
the desired impact.</p>
<h3><a name="well-crafted"></a>Well-Crafted Posting is Worth the Effort</h3>
<p>Don't forget, you're a single writer but there are many
readers, and you want them to stay interested in what you're
saying. Saving your readers a little time and effort is usually
worth the extra time you spend when writing a message. Also,
boost discussions are saved for posterity, as rationales and
history of the work we do. A post's usefulness in the future is
determined by its readability.</p>
<h3><a name="subject-line"></a>Put the Library Name in the Subject Line</h3>
<p>When your post is related to a particular Boost library,
it's helpful to put the library name in square brackets at the
beginning of the subject line, e.g.</p>
<blockquote>
<p>Subject: [Regex] Why doesn't this pattern match?</p>
</blockquote>
<p>The Boost developers' list is a high-volume mailing list,
and most maintainers don't have time to read every message. A
tag on the subject line will help ensure the right people see
your post.</p>
<h3><a name="tabs" id="tabs"></a>Don't Use Tabs</h3>
<p>If you use tabs to indent your source code, convert them to
spaces before inserting the code in a posting. Something in the
processing chain usually strips all the indentation and leaves
a mess behind.</p>
<h3><a name="longlines" id="longlines"></a>Limit Line
Length</h3>
<p>If you put source code in your postings and your mailer
wraps long lines automatically, either keep the code narrow or
insert the code as an (inline, if possible) attachment. That
will help ensure others can read what you've posted.</p>
<h3><a name="quoting" id="quoting"></a>Don't Overquote, Don't
Top-Post, and Do Use Inline Replies for Readable Quotations</h3>
<p>Please <strong>prune extraneous quoted text</strong> from
replies so that only the relevant parts are included. It will
save time and make your post more valuable when readers do not
have to find out which exact part of a previous message you
are responding to.</p>
<p>Don't <a href=
"http://en.wikipedia.org/wiki/Posting_style#Top-posting">top-post</a>;
inline replies are the appropriate <a href=
"http://en.wikipedia.org/wiki/Posting_style">posting style</a>
for Boost lists.</p>
<p>The common and very useful inline approach cites the small
fractions of the message you are actually responding to and
puts your response directly beneath each citation, with a blank
line separating them for readability:</p>
<pre><var>Person-you're-replying-to</var> wrote:
&gt; Some part of a paragraph that you wish to reply to goes
&gt; here; there may be several lines.
Your response to that part of the message goes here. There may,
of course, be several lines.
&gt; The second part of the paragraph that is relevant to your
&gt; reply goes here; again there may be several lines.
Your response to the second part of the message goes here.
...
</pre>
<p>For more information about effective use of quotation in
posts, see <a href=
"http://www.netmeister.org/news/learn2quote.html" class=
"external">this helpful guide</a>.</p>
<h3><a name="formatting-quotations"></a>Keep the Formatting of Quotations Consistent</h3>
<p>Some email and news clients use poor word wrapping
algorithms that leave successive lines from the same quotation
with differing numbers of leading "<code>&gt;</code>"
characters. <strong>Microsoft Outlook</strong> and
<strong>Outlook Express</strong>, and some web clients, are
especially bad about this. If your client offends in this way,
please take the effort to clean up the mess it makes in quoted
text. Remember, even if you didn't write the original text,
it's <em>your</em> posting; whether you get your point across
depends on its readability.</p>
<p>The Microsoft clients also create an unusually verbose
header at the beginning of the original message text and leave
the cursor at the beginning of the message, which encourages
users to write their replies before all of the quoted text
rather than putting the reply in context. Fortunately, Dominic
Jain has written a utility that fixes all of these problems
automatically: <a href=
"http://home.in.tum.de/~jain/software/outlook-quotefix/" class=
"external">Outlook Quotefix</a> for Outlook Users and <a href=
"http://home.in.tum.de/~jain/software/oe-quotefix/" class=
"external">OE QuoteFix</a> for users of Outlook Express.</p>
<h3><a name="summarizing-referring"></a>Summarizing and Referring to Earlier Messages</h3>
<p>A summary of the foregoing thread is only needed after a
long discussion, especially when the topic is drifting or a
result has been achieved in a discussion. The mail system will
do the tracking that is needed to enable mail readers to
display message threads (and every decent mail reader supports
that).</p>
<p>If you ever have to refer to single message earlier in a
thread or in a different thread then you can use a URL to the
<a href="groups.html#archive">message archives</a>. To help to
keep those URLs short, you can use <a href="http://tinyurl.com"
class="external">tinyurl.com</a>. Citing the relevant portion
of a message you link to is often helpful (if the citation is
small).</p>
<h3><a name="discussion-threads"></a>Maintain the Integrity of Discussion Threads</h3>
<p><strong>When starting a new topic, always send a fresh
message</strong>, rather than beginning a reply to some other
message and replacing the subject and body. Many mailers can detect the thread you started with and will show the
new message as part of the original thread, which probably
isn't what you intended. Follow this guideline for your own
sake as well as for others'. Often, people scanning for
relevant messages will decide they're done with a topic and
hide or kill the entire thread: your message will be missed,
and you won't get the response you're looking for.</p>
<p>By the same token, <strong>when replying to an existing
message, use your mailer's "Reply" function</strong>, so that
the reply shows up as part of the same discussion thread.</p>
<p><strong>Do not reply to digests</strong> if you are a digest
delivery subscriber. Your reply will not be properly threaded
and will probably have the wrong subject line. Instead, you can
reply through the <a href=
"http://news.gmane.org/gmane.comp.lib.boost.devel" class=
"external">GMane web interface</a>.</p>
<h3><a name="max-size"></a>Keep The Size of Your Posting Manageable</h3>
<p>The mailing list software automatically limits message and
attachment size to a reasonable amount, typically 75K, which is
adjusted from time-to-time by the moderators. This limit is a
courtesy to those who rely on dial-up Internet access and let's
face it, no one wants to read a posting that consists of 75K of
error message text.</p>
<h3><a name="email-footers"></a>Avoid Corporate and Confidentiality
Footers in Your Emails</h3>
<p>Remember that mailing lists are publicly viewable, including
by people not subscribed to the list. The responsibility of not
posting any confidential information is always on the sender,
and any confidentiality notice you may have in your email is void.
Sending an email with a confidentiality footer is a one-way action
by the sender, and the receiver has no way to accept or reject the
terms specified in the footer. As such, the footer is not binding,
but may come across as imposing on the receiver. This negative
reception will reduce the likelihood of your message being
answered.</p>
<p>Additionally, if your footer contains corporate information,
such as company name, logo, marketing slogans, contacts, and your
position within the company, this may be taken as advertisement,
which is explicitly forbidden. If your message requires you to
expose your corporate affiliation, please include this information
in the body of your message instead of attaching it to your every
post in the corporate footer.</p>
<p>If the footer is a mandatory corporate policy then please avoid
using corporate email accounts for sending posts to the mailing
lists. Use a non-corporate email account instead.</p>
<h2><a name="behavior" id="behavior"></a>Prohibited
Behavior</h2>
<p>Prohibited behavior will not be tolerated. The moderators
will ban postings by abusers.</p>
<h3><a name="flame-wars"></a>Flame wars</h3>
<p>Personal insults, argument for the sake of argument, and all
the other behaviors which fall into the "flame war" category
are prohibited. Discussions should focus on technical
arguments, not the personality traits or motives of
participants.</p>
<h3><a name="third-party-attacks"></a>Third-party attacks</h3>
<p>Attacks on third parties such as software vendors, hardware
vendors, or any other organizations, are prohibited. Boost
exists to unite and serve the entire C++ community, not to
disparage the work of others.</p>
<p>Does this mean that we ban the occasional complaint or wry
remark about a troublesome compiler? No, but be wary of
overdoing it.</p>
<h3><a name="off-topic-posts"></a>Off-topic posts</h3>
<p>Discussions that stray from the acceptable topics are
strongly discouraged. While off-topic posts are often well
meaning and not as individually corrosive as other abuses,
cumulatively the distraction damages the effectiveness of
discussion.</p>
<h2><a name="culture" id="culture"></a>Culture</h2>
<p>In addition to technical skills, Boost members value
collaboration, acknowledgment of the help of others, and a
certain level of politeness. Boost membership is very
international, and ranges widely in age and other
characteristics. Think of discussion as occurring among
colleagues in a widely read forum, rather than among a few
close friends.</p>
<p>Always remember that the cumulative effort spent by people
reading your contribution scales with the (already large)
number of boost members. Thus, do invest time and effort to
make your message as readable as possible. Adhere to English
syntax and grammar rules such as proper capitalization. Avoid
copious informalism, colloquial language, or abbreviations,
they may not be understood by all readers. Re-read your message
before submitting it.</p>
<h2><a name="effective-discussions"></a>Guidelines for Effective Discussions</h2>
<p>Apply social engineering to prevent heated technical
discussion from degenerating into a shouting match, and to
actively encourage the cooperation upon which Boost
depends.</p>
<ul>
<li>Questions help. If someone suggests something that you
don't think will work, then replying with a question like
"will that compile?" or "won't that fail to compile, or am I
missing something?" is a lot smoother than "That's
stupid - it won't compile." Saying "that fails to compile for
me, and seems to violate section n.n.n of the standard" would
be yet another way to be firm without being abrasive.</li>
<li>If most of the discussion has been code-free
generalities, posting a bit of sample code can focus people
on the practical issues.</li>
<li>If most of the discussion has been in terms of specific
code, try to talk a bit about hidden assumptions and
generalities that may be preventing discussion closure.</li>
<li>Taking a time-out is often effective. Just say: "Let me
think about that for a day or two. Let's take a time-out to
digest the discussion so far."</li>
</ul>
<p>Avoid <i><strong>Parkinson's Bicycle Shed</strong></i>.
Parkinson described a committee formed to oversee design of an
early nuclear power plant. There were three agenda items - when
to have tea, where to put the bicycle shed, and how to ensure
nuclear safety. Tea was disposed of quickly as trivial. Nuclear
safety was discussed for only an hour - it was so complex,
scary, and technical that even among experts few felt
comfortable with the issues. Endless days were then spent
discussing construction of the bicycle shed (the parking lot
would be the modern equivalent) because everyone thought they
understood the issues and felt comfortable discussing them.</p>
<h2><a name="lib_names" id="lib_names"></a>Library Names</h2>
<p>In order to ensure a uniform presentation in books and
articles, we have adopted a convention for referring to Boost
libraries. Library names can either be written in a compact
form with a dot, as "Boost.<var>Name</var>", or in a long form
as "the Boost <var>Name</var> library." For example:</p>
<blockquote>
<p><strong>Boost.Python</strong> serves a very different
purpose from <strong>the Boost Graph library</strong>.</p>
</blockquote>
<p>Note that the word "library" is not part of the name, and as
such isn't capitalized.</p>
<p>Please take care to avoid confusion in discussions between
libraries that have been accepted into Boost and those that
have not. Acceptance as a Boost library indicates that the code
and design have passed through our peer-review process; failing
to make the distinction devalues the hard work of library
authors who've gone through that process. Here are some
suggested ways to describe potential Boost libraries:</p>
<ul>
<li>the proposed Boost <var>Name</var> library</li>
<li>the Boost.<var>Name</var> candidate</li>
<li>the <var>Name</var> library (probably the best choice
where applicable)</li>
</ul>
<p>Note that this policy only applies to discussions, not to
the documentation, directory structure, or even identifiers in
the code of potential Boost libraries.</p>
</div>
</div>
</div>
</div>
<div id="sidebar">
<!--#include virtual="/common/sidebar-common.html" -->
<!--#include virtual="/common/sidebar-community.html" -->
</div>
<div class="clear"></div>
</div>
</div>
<div id="footer">
<div id="footer-left">
<div id="revised">
<p>Revised $Date$</p>
</div>
<div id="copyright">
<p>Copyright Beman Dawes, Rob Stewart, David Abrahams, 2000-2005.</p>
</div><!--#include virtual="/common/footer-license.html" -->
</div>
<div id="footer-right">
<!--#include virtual="/common/footer-banners.html" -->
</div>
<div class="clear"></div>
</div>
</body>
</html>