"You are free to change your library in any way you wish". Ok...
BTW: Should this paragraph possibly get an update to refer to Github (PRs, issues, ...) and how to handle patches from others? It says "peer review is an important part of the Boost process" but only relates to interface changes, not to internal changes although they might break things or are supposed to fix them. "and to participate as needed in discussions of your library on the boost mailing lists." could be extended to include Github(?)
As someone trying to work my way up to take over as the graph maintainer, having a maintainer do this rubs me the wrong way. If this kind of excitement is going to be stirred up, can you tell us the subproject so we can figure out what is happening?
I'd rather not, the discussion is already heated enough there I feel. I just wanted to know where Boost (or other members/maintainers/...) stand in this to reevaluate my expectations. Being on the other site (contributor, not maintainer) it puzzled me, that maintainers can simply ignore changes and actively avoid reviews when doing own changes. Note that CMT maintained libs are much more like I thought it would work: https://svn.boost.org/trac10/wiki/CommunityMaintenance - Changes proposed - Changes reviewed - Changes merged