The 'Reviewer' Role
Set up advanced workflows and documentation cultures with more diverse member roles.
Good to know: The 'Reviewer' role and advanced permissions are Business Plan features.
We've revamped permissions in GitBook. There's a lot to the new permission model, and we'd encourage you to read the docs on permissions if you want a full deep dive, but today, we're highlighting one role in particular: the reviewer.
What is it?
The reviewer role is a new role in GitBook that allows users to merge other people's (and their own!) Change Requests.
How does it work?
To understand the benefits of the reviewer role, it's best to look at it in context with its companion, the editor role, and how both of these roles work when a space is locked or unlocked for live edits.
If you have an editor role in a space, you'll be able to:
If the space is unlocked for live edits: edit content directly using live edit.
If the space is locked for live edits: create and submit change requests.
If you have a reviewer role in a space, you'll be able to:
If the space is unlocked for live edits: edit content directly using live edit.
If the space is locked for live edits: create, submit, and merge change requests.
This lets you create whatever workflow dynamic you need. Want everyone to just keep contributing content, merging whenever they like, and generally have hands-off workflow/review management? Just make them all reviewers and forget about it. Prefer more hands-on workflows, or want to create a dynamic where you have lots of editors and only a few reviewers? Super simple, just set the roles accordingly at the space, collection, or organization level.
Best practices
There really are no hard-and-fast rules with the reviewer role, it's more about the workflow and writing culture you're trying to create and maintain. Remember that permissions can be inherited or overridden at any level of the content tree, so feel free to experiment with different approaches and see what works best for your team or organization!
Last updated