--- In boost@[...].. , Ed Brey <brey@[...]..>  wrote:
>  From: David Abrahams <abrahams@[...]..>
>  > The only excuse for these acronyms, AFAICT, is that it gets
cumbersome to
>  > refer to a library as The Boost Foo Library over and over
within the
>  > library's own documentation. I didn't want an acronym for the
Python lib,
>  > but eventually found it hard to make the docs read easily without
one. Can
>  > anyone think of a good alternative?
> 
>  We can take advantage of being within the Boost namespace within
our docs
>  and just say things like See the Test library for me details, and
look at
>  the cool Python library. I thinking capitalizing the name of the
library
>  will make things clear enough.
> 
>  Data point: When I posted my review with subject Review: Test
library , was
>  there any ambiguity regarding what the review was of?

Within the Boost eGroup I'd expect there to be zero confusion. This
may or may not be the case within the libraries. Many Boost
libraries exist both as a part of Boost, and as seperately available
libraries from other sites. Even within the Boost archives, many
users are searching for only a single library and are pointed to
Boost where they d/l the package with the intention of only using the
one library. If the documentation for that library references
another library within Boost and shortens the name by removing
Boost from the title, this user may be confused by what library is
being referred to. Worse still, not all Boost libraries go by the
name Boost _____ Library , which will lead to further confusion when
not using the full and proper library name.

In the case of the Boost Thread Library, the documentation has to
referrence other thread libraries from time to time, so referring to
itself as the Thread Library in the docs is still likely to cause
confusion despite the capital letters (which a simple typo could
cause to be an even worse problem).

I'm not sure what the proper solution should be, but it doesn't
seem to be a simple one to me.

Bill Kempf