I'd suggest that we identify the top documentation contributors and reviewers to seed the fabric docs repository maintainer list in the coming weeks (including Chris and Joe), rather than pulling the trigger in the Fabric repository this week.

Are there separate maintainer pools for different fabric-* repos? 

If so, I can understand the argument, coming from a world where the precautionary principle would apply, and where prior version control systems (and even earlier versions of git) allowed for a dangerous degree of repository damage if someone made the wrong set of changes. I also of course get the point for different maintainers for different Hyperledger projects, e.g. Fabric vs Sawtooth. 

But for the same project, which is arguably the same "community" of contributors and representatives of end-users, you may want to consider a single pool of maintainers across all fabric-* repos.  The easy case is to argue for the ability for anyone who's a maintainer on the main code repos to also be able to merge in changes into docs-related repos.  The harder case is for people who come in as solid contributors to docs, but aren't (yet!) code contributors.  There, I'd still argue for it - the boundary between docs and code is rarely so hard, as changes to error messages/logging or admin/user interfaces often are driven by a docs-level view of what would be easier to explain.  And, I've seen great core developers on projects come in first through a docs-related role.  Also, just for simplicity: I'll counter your precautionary principle with an Occam's Razor, which makes understanding the project easier for newcomers.  I bet reversing any mistaken merges is a lower cost than the value of contributions you might not otherwise see.

Up to you all,

Brian

-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf