I appreciate the contribution by Bjoern Roald and Patrick Horgan and I am going to use Bjoern's variant of the "proposed by" logo for the next updates of my own library docs. As with boost libraries as a whole, I think we should strive to foster a consistent style, simplicity and elegance. This implies to have (1) as few additional logos as possible and (2) logos that try to seamlessly and artistically integrate into the typographical style that is currently used in boost and boost quickbook. Because of (2) I think that the red colored additions of Patrick's logo are less suitable because they add a new (and a very strong) color to the logo and to the color family of the whole quickbook style. 2010/2/1 Thomas Klimpel <Thomas.Klimpel@synopsys.com>:
Patrick Horgan wrote:
LOL! I can't imagine anyone would proudly proclaim "my software was rejected by boost!"
Well, not exactly "proudly proclaim". But the library author might take a "time off" [...] it would be used rarely anyway.
If they are rejected by boost though, they have no business showing a boost logo associated with their software
It's not so easy. That they were rejected during a formal boost review doesn't necessarily mean that they are no longer associated with boost. The current agreement is to limit the number of different logos, especially no special logo for rejected libraries.
I agree with both points. My suggestion is this: * Only two additional logos (1) proposed for boost (2) compliant to boost Libraries that have been proposed on the list and generated interest can use logo (1). In order to be acceptable for a formal review, the library has to become boost compliant. * Boost centric directory structure * Implementation of various boost conventions * Portability * Dependent on std and boost libs only * Sufficient documentation. * Sufficient tests ... to mention only the most important ones. A library that is not boost compliant will not reach a formal review because the review manager should check and reject any non boost compliant submission. The process from the first RFC to the formal review implies already a great amount of work and an evolutionary process that greatly improves the libraries quality. This is (1) first of all an achievement of the library author, (2) an achievement of other developers through discussion and (3) an achievement of the boost community that produces standards and guidelines. So a library that reaches the state of formal review, even if rejected has gained quality and usefulness by the process of becoming boost compliant. A library that has been rejected in a formal review can stay "proposed for boost" if there is a chance for resubmission that the author wants to pursue or can be labeled "boost compliant", a state reached by committing the library to the boost review process. An accepted library simply carries the original boost logo. Cheers Joachim