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.