> 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.