Start here: https://dl.dropboxusercontent.com/u/9897665/community-maintenance.html I have contacted the authors of the libraries listed in Beman’s proposals. Some have responded affirmatively; the rest have not responded. So, I thought I would put down some thoughts about how the Boost Community Maintenance Team (Boost.CMT) should work. Goals (in priority order): 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. Add new features. How I see this working: 0) We’ll set up a separate Boost.CMT mailing list. (the main developer list has too much traffic already) 1) People would pick a problem and post a note to the list that they were working on it. 2) {Optional] discussion ensues about the way to solve the problem. 3) A potential solution is implemented (and tested!) 4) A pull request is posted to the mailing list (with tests) 5) Discussion ensues. Repeat steps 3/4/5 as needed. 6) The pull request is merged to ‘develop’ 7) After test cycles, the change is merged to ‘master' Notes: 1) All of this should happen on the Boost.CMT ML. 2) Discussions _about_ the CMT should happen on the main Boost ML. 3) The person who lands the patch is responsible for checking the test results and merging to “master” (and closing out the bug report, if any). 4) The goal of the CMT will be the same as the Boy Scouts - “Leave the code cleaner than when you found it” Comments? -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki