A good idea may also be to start a “best practices of software engineering” tutorial or wiki page. There could for example be an article on boost::mpl and its plusses/minuses. From my experience by the time you figure out how to do it with mpl, it would have been faster to just write a new method which would compile faster (see previous comments about #include’s)


If there's broad consensus about warning/disallowing certain headers from boost or elsewhere, I'll happily have roslint provide the appropriate output.

I could envision the wiki checkmarks for released, documented, etc, including at some point metrics for test coverage, linter coverage, etc. These things are markers which signal to a potential user the level of maintenance and stability in a package, but they also provide that gamification incentive for maintainers— cover all the bases, get all the green checkmarks.

M.