On Tue, Nov 28, 2023 at 8:45 AM Andrea Bocci
Since you seem pretty eager to ask opinionated questions, what do these three points have to do - if anything at all - with the quality of the library?
I'm evaluating the author's library development hygiene. A formal review is as much about reviewing the author as it is about reviewing the library. For example, the very last thing we want is for an author to have a library accepted, and they promptly abandon the library with no support. This is a contrived example, I'm not saying it applies to this author, but I have seen cases where people just cook up a library with no support and hastily expel it onto the mailing list for a review. Andrey is a good Boost author with many contributions so this is sort of a formality. From now on I will be asking these questions of any author submitting a library for a review. The questions also serve as a subtle hint: if you are writing a library with the goal of submitting for a review, doing these things can't hurt and they can only possibly help: 1. Ask Peter Dimov to weigh in on the library 2. Consult other talented engineers regularly to help shape the public interface 3. Join the C++ Language Slack Workspace for enrichment and collaboration 4. Find stakeholders ahead of the review who would benefit from your library, and are willing to integrate it into their code to provide feedback There is also another benefit to collaborating with others during development: you can tap in to experts to get help on important areas such as documentation toolchains, cmake integration, continuous integration (per-commit testing), code coverage, and writing comprehensive tests. Thanks