I) Accept proposals for new boost tools into the review queue. Such tools might be just Cmake templates or things like that. Encourage members of the developer's list to submit proposals to support efforts by library developers to (for example): a) CMake for building and testing libraries b) Creation of Find(library) to help boost users who use CMake c) Creation of CMakePackage(Library) (actually I don't know what this is but it has been mentioned. d) Addition of continuation integration testing via appveyor, travis or whatever Note that above ideas would be likely installed on a library by library basis. Also note that above ideas not much dependent upon each other. There is not requirement that they be installed all at once. Such proposals would be added to the "Boost proposal review queue" and be addressed via a similar procedure to that used to decide acceptance of proposed libraries. Since most of these proposals take the form of "best", "suggested" or "required" practices they would take the form of explicit requirements and procedures described in a document in a common format. This document would be posted as part of the Boost web page. Obviously, such proposals would have to be specific enough for library developers to "paste in" or otherwise implement without a lot of investment of effort. In the past, Naill posted his "best practices" and I've made my own personal recommendations on the boost library incubator pages, but these don't have any "official" acceptance. The above would build consensus for what we might think of as boost best practices, boost requirements, or something like that. II) Accept proposals for new boost tools. These would be code. There are already a few tools such as bcp, boost dependency analysis, library_test and perhaps others. I propose that tool proposals be accepted and reviewed just as libraries are. Examples of things I would like to see coming out of this might be: a) better discussion and concensus on what "Dependency" means in the context of boost libraries and a tool which reflects that concensus. e) Dashboard for test results from CI systems similar to or perhaps integrated into the current test matrix. Actually, I would like to see this dashboard include tests run by users similar to the way that CTest/CDash is supposed to work. f) Serious enhancements to existing tools. Of course proposals for such tools would have to include (mostly) working code so that a proposal can be actually evaluated. Note that the above focuses on evaluating specific proposals which are (more or less) ready to implement. There's not much point in spending a lot of time discussing ideas which have yet to arrive to this stage of development I had a lot to say about all this in my boost 2.0 presentation at CPPNow back in 2015. Unfortunately, the presentation wasn't recorded but the slides are available at http://rrsd.com/software_development/boost/C++Now2015/index.html Robert Ramey