The Boost Community Maintenance team (CMT) was created in January 2014 to provide maintenance for libraries where the author is unable to provide it.

The [http://lists.boost.org/mailman/listinfo.cgi/boost-maint boost-maint] mailing list is where the team holds discussions and makes decisions.

This is a public group; all people who wish to contribute are welcome to join the mailing list and help out.

== Goals of the CMT ==
1. Keep things building on all the supported compilers (and as many others as possible)
2. Get the test matrix “all green” and keep it that way.
3. Fix the accumulated bugs; drive the bug count to zero, and keep it there.
4. Improve the documentation for the libraries maintained by the CMT.
5. Add new features.

Also, a long term goal of the CMT is to find maintainers for these libraries.

== Libraries maintained by the CMT ==

* [https://github.com/boostorg/assign boostorg/assign]
* [https://github.com/boostorg/concept_check boostorg/concept_check]
* [https://github.com/boostorg/disjoint_sets boostorg/disjoint_sets]
* [https://github.com/boostorg/dynamic_bitset boostorg/dynamic_bitset]
* [https://github.com/boostorg/interval boostorg/interval]
* [https://github.com/boostorg/iostreams boostorg/iostreams]
* [https://github.com/boostorg/logic boostorg/logic]
* [https://github.com/boostorg/mpl boostorg/mpl]
* [https://github.com/boostorg/pool boostorg/pool]
* [https://github.com/boostorg/property_map boostorg/property_map]
* [https://github.com/boostorg/ptr_container boostorg/ptr_container]
* [https://github.com/boostorg/rational boostorg/rational]
* [https://github.com/boostorg/signals boostorg/signals] (deprecated since 1.54.0 and scheduled for removal in 1.69.0 - please migrate to signals2)
* [https://github.com/boostorg/statechart boostorg/statechart]
* [https://github.com/boostorg/tokenizer boostorg/tokenizer]

== Procedures for the CMT ==

The CMT will operate on a "propose and review" process, where a change goes through the following phases.

1. Someone decides to work on a bug/test failure/etc and announces this on the mailing list.
2. Discussion may ensue on the ML about the best way to proceed.
3. The code is developed and a pull request is made (on the list).
4. The request is reviewed by other members of the list. (repeat steps 3 and 4 as necessary)
5. The request is committed to the "develop" branch by a CMT manager.
6. The person who made the pull request is responsible to watching the test results, and notifying the CMT manager when it is ready to be merged to "master"

For this to work, we need several people who are willing to review other people's pull requests (as well as developing their own patches).