Boost Discussion Policy

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.

Acceptable Topics

Try to focus email discussion on the following:

Queries to determine interest in a possible library submission
Technical discussions about a proposed or existing library, including bug reports and requests for help
Formal Reviews of proposed libraries
Reports of user experiences with Boost libraries
Boost administration or policies
Compiler specific workarounds as applied to Boost libraries

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.

Unacceptable Topics

Posts on the following topics will probably not be accepted by the moderators:

Advertisements for commercial products
Requests for help getting non-Boost code to compile with your compiler (try Stack Overflow: C++)
Requests for help interpreting the C++ standard (try C++ FAQ)
Job offers
Requests for solutions to homework assignments
Any posting noted as Prohibited Behavior

Effective Posting

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.

Well-Crafted Posting is Worth the Effort

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.

Put the Library Name in the Subject Line

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.

Subject: [Regex] Why doesn't this pattern match?

The Boost developers' mailing 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.

Don’t Use Tabs

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.

Limit Line Length

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.

Don’t Over-quote, Don’t Top-Post, and Do Use Inline Replies for Readable Quotations

Prune extraneous quoted text 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.

Don’t top-post (where the original message is included verbatim, with the reply above it); inline replies are the appropriate posting style for Boost lists.

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:

Person-you’re-replying-to wrote:

> Some part of a paragraph that you wish to reply to goes
> here; there may be several lines.

Your response to that part of the message goes here.
There may, of course, be several lines.

> The second part of the  paragraph that is relevant to your
> reply goes here; again there may be several lines.

Your response to the second part of the message goes here.

For more information about effective use of quotation in posts, see How do I quote correctly in Usenet?.

Keep the Formatting of Quotations Consistent

Some email and news clients use poor word wrapping algorithms that leave successive lines from the same quotation with differing numbers of leading ">" characters. Microsoft Outlook and Outlook Express, 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 your posting; whether you get your point across depends on its readability.

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. Search online for "Quotefix" and you may find a utility that fixes this issue automatically for your email client.

Summarizing and Referring to Earlier Messages

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).

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 message archives. Citing the relevant portion of the message you link to is often helpful (if the citation is small).

Maintain the Integrity of Discussion Threads

When starting a new topic, always send a fresh message, 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.

By the same token, when replying to an existing message, use your mailer’s Reply function, so that the reply shows up as part of the same discussion thread.

Do not reply to digests if you are a digest delivery subscriber. Your reply will not be properly threaded and will probably have the wrong subject line.

Keep The Size of Your Posting Manageable

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.

Avoid Corporate and Confidentiality Footers in Your Emails

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.

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.

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.

Prohibited Behavior

Prohibited behavior will not be tolerated. The moderators will ban postings by abusers.

Flame Wars

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.

Third-party Attacks

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.

Does this mean that we ban the occasional complaint or wry remark about a troublesome compiler? No, but be wary of overdoing it.

Off-topic Posts

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.

Culture

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.

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.

Guidelines for Effective Discussions

Apply social engineering to prevent heated technical discussion from degenerating into a shouting match, and to actively encourage the cooperation upon which Boost depends.

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.
If most of the discussion has been code-free generalities, posting a bit of sample code can focus people on the practical issues.
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.
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."
Avoid Parkinson’s Bicycle Shed. 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.

Library Names

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.Name", or in a long form as "the Boost Name library." For example:

Boost.Python serves a very different purpose from the Boost Graph library.

Note: The word "library" is not part of the name, and as such isn’t capitalized and may not be necessary.

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:

"the Name library" (probably the best choice where applicable)
"the proposed Boost Name library"
"the Boost.Name candidate"

Note

This policy only applies to discussions, not to the documentation, directory structure, or even identifiers in the code of potential Boost libraries.