I have been maintaining Boost Phoenix for several weeks. To start with I was mainly attempting to fix as many bugs as possible and also sorting out things like missing copright and licence. I am now up to the more difficult bugs which take longer to fix. I also need some more information and some actions which I cannot take myself. I have asked about a number of these on this list and I am lacking answers to a good many of them, so I am going to summarise them here. I think it would be a great help to people undertaking maintenance for the first time, without having first been an originator of a library if some guidelines were in a document. 1. General guidelines on the responsibilities of a maintainer and who is responsible for the elements outside the developer's control. In particular, what happens when there is a release of boost? 2. General guidelines on the responsibilities for bugs and who to contact if a bug seems to be due to a different library. 3. Guidelines on the use of trac and how to get given the ability to record bugs as now fixed. 4. Where is the archive for boost-bugs? It would be useful to look at past fixes to find out what has gone on. Someone suggested searching but I cannot search until I know what is there. 5. A list of who is maintaining what. 6. Documentation. I am trying to get to grips with boostbook and quickbook. Some libraries are included in a section with indexed chapters and some are not. Is there a policy about this. When I asked how Phoenix could join the only reply I had was not to bother. Is there a documentation policy? It would be good to be able to generate the web pages myself to check them when I am making changes, which may be substantial. 7. More technical. How are things to be handled in relation to C++11. (a) Things which used to work which now don't with C++11? (b) Things which only work with C++11? (c) and what about C++14? I am fixing things in an adhoc way but it would be good to have a uniform approach. 8. Boost predef for version numbers. I have introduced this into Phoenix alongside the existing method. 9. Changelog. As a user I have found this useful in libraries I have used elsewhere, so I have put one into Phoenix following the style I found in wave. There is quite a lot here, but it has been building up for some time as I find I need more information to work effectively. John Fletcher P.S. Thanks to all those who have helped me get this far.