Re: [boost] [logo] Boost logo variants for use in unofficial or unreleased boost documentation - was C++ Networking Library Release 0.5

Subject: Re: [boost] [logo] Boost logo variants for use in unofficial or unreleased boost documentation - was C++ Networking Library Release 0.5
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-01-31 09:29:17

On 31.01.2010 16:48, Thomas Klimpel wrote:
> Andrey Semashev wrote:
>> IMHO, the "rejected" logo makes a disservice for the library, as it
>> marks it as something of inappropriate quality for Boost in eyes of
>> users.
>
> I think the original proposal comes from
> http://lists.boost.org/Archives/boost/2010/01/161356.php and the
> changes to the original proposal were explained in
> http://lists.boost.org/Archives/boost/2010/01/161386.php
>
> The original proposal described two different use cases for the
> logos. The first use case was:
>> Any library or system using boost may use the "powered by" or
>> "using" variants.
> The second use case was:
>> A standard set of logo designs used at various stages in a proposal
>> life-cycle may be good
>
> So the "rejected proposal for boost" or "rejected by boost" logos
> (which you summarized by "rejected") are meant to describe a specific
> stage in a (possible) proposal life cycle. An example of a library in
> this stage is Boost.Utility/Singleton:
> http://lists.boost.org/Archives/boost/2008/01/132777.php

Yes, I read that post, but it misses one (quite common, I believe) case, 
when the rejected library continues to live outside of Boost, with 
little or no intention to resubmit the review. It is still designed to 
fit into Boost infrastructure, so I don't think that "powered by" or 
"using" variants are adequate.

>> Therefore I'd like it to be rephrased to something more neutral,
>> such as "unofficial extension" or something of that kind.
>
> I guess "unofficial extension" tries to communicate the same meaning
> as "designed for", but it is hard for me to nail down what it exactly
> wants to communicate. But I agree that this also describes a specific
> stage in a (possible) proposal life cycle.

For the reasons I outlined, I don't think that "designed for" is 
accurate, but it's better than "rejected".

> I guess an example of a
> proposal in this stage is Boost.CMake. But lets face it, this
> specific stage in a life cycle is not something that boost currently
> encourages or is able to handle specifically well. (This is different
> from the "rejected" stage of the life cycle, which is not so
> extraordinary for boost proposal after all.)

IMHO, Boost does not (and should not) discourage development of other 
libraries (or, in case of Boost.CMake, toolsets), whether or not they 
were initially targeted for inclusion into Boost. At least, I don't 
remember a single act of discouragement.

My whole point is that the logo should not render a library as a 
second-class thing.