I’ve heard complaints about the peer review process at a variety of organizations where I’ve seen it in use. To simplify, they sound like this:
- Writers: When I fix a set of issues and resubmit the PR, the reviewer(s) come up with a new set of issues.
- Reviewers: I keep flagging the same set of stupid !%$%*$# issues.
- Everyone: Ugh. This takes too much time and effort.
In some cases, the peer review process can be demoralizing and spark interpersonal conflicts.
Looking for a solution to this issue, I turned to Vale, a style linter that has been gained traction at a variety of organizations, such as GitLab, NGINX, and elsewhere. At Red Hat, a couple of doc projects have been using it for over a year and there seems to be growing interest in expanding its use.
My first step was to start using Vale to get hand-on experience using it: eat your own dog food, etc. In my enthusiasm, I popped $57 for a Vale Server license.
Installing Vale Server wasn’t hard. Finding and configuring the pair of plugins to make it work with my Atom editor was a little confusing. Setting up the single plugin for VS Code was easy.
I installed all the built-in styles for Vale Server, but then had trouble applying them to my docs. Installation is not enough. One must also create a project in Vale Server and configure it to use the styles.
Overall, the process was a bit tricky enough that I realized rolling it out to a team of writers would require documented procedures, tutorial videos, and live support.
It’s also unclear whether my organization would commit to purchasing Vale Server licenses at first. So, I would need to figure out how to roll out Vale, the CLI tool, instead of Vale Server. To make the distinction clear, I’ll refer to Vale as Vale CLI from now on.
Vale CLI is simpler to install and configure than Vale Server. However, I believe Vale CLI alone doesn’t integrate with editors like Atom and VS Code. With Vale CLI, you get all your feedback by running the vale command against your file or files from the CLI. For example:
$ vale README.md
The output looks something like this:
In some ways, it’s less distracting to get with this command line feedback after you write a block of content. Vale Server highlights issues in your text editor when you save your current text. In other words, with Vale Server, the feedback is both more immediate and in some ways distracting. Six one way, half-dozen the other.
Interesting piece. I find the success of peer review depends on everyone having a positive attitude. Or not. I am always happy to receive constructive feedback and will act on it or not depending on complexity, resourcing and benefit. However, I work with some people who take “you missed a space there” as a personal affront and start name calling.
We’ve recently adopted Acrolinx and that’s definitely having a positive impact, without the personality problems.
I’m grateful for your comment. Yes, having a shared positive attitude toward peer reviews requires having a common understanding that they are universally required, that giving them is a contribution, and that they do not “count against” the person receiving them. I love Acrolinx, too.