| Home | Libraries | People | FAQ | More

# 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

- 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

- Advertisements for commercial products.
- Requests for help getting non-boost code to compile with your compiler. Try the comp.lang.c++.moderated newsgroup instead.
- Requests for help interpreting the C++ standard. Try the comp.std.c++ newsgroup 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 which 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, acknowledgement 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.

## Guidelines for effective discussions

Apply social engineering to prevent heated technical discussion from degenerating into a shouting match.

- 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 really 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 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 where to put the bicycle shed (the parking lot would be a modern equivalent) because everyone understood the issues and felt comfortable discussing them.

Revised 08 January, 2001