Vale notes #2: Talk to experts and stakeholders

In addition to eating my own dogfood, I started finding and talking to experts and stakeholders.

For experts, I went to folks inside and outside Red Hat. At Red Hat, I talked to Fabrice Flore-Thebault and Yana Hontyk. Last year, they presented on using Vale with their documentation sets: Eclipse Che and CodeReady Workspaces. I talked to them about their workflow, the issues they had fixed, and results.

Outside Red Hat, I pulled together an unconference session at Write the Docs Portland conference with Mike Jang from GitLab and Jodie Putrino at NGINX. They spoke about their differing approaches to rolling it out at their organizations. Lynette Miles at TAG1 Consulting also contributed.

For stakeholders:

  • I talked with my manager, who was supportive.
  • I arranged a meeting for Yana and Fabrice to present their work to a small group of writers, content strategists, and managers who had expressed an interest in rolling out Vale. The group expressed a lot of interest, and we agreed there should be some follow-up actions, like additional pilot programs.

As an aside, Fabrice and Yana’s presentation included the following impressive graph. It shows how they iterated on both the documentation and Vale style rules to achieve nearly zero errors, both real errors and false positives, over the course of almost two years:

To prepare for the follow-up, I have created a repo that contains a preliminary set of Vale config files and styles: https://github.com/rolfedh/studious-fortnight (definitely a work-in-progress).

Vale notes #1: Eating my dog food

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:

Typical feedback from Vale CLI

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.

How to learned to love my email inbox

Stop using your email as a holding pen for I should do’s and somedays.

Me, thinking to myself 🙂

My email inbox was a bottomless pile of messages seen and considered but not resolved. Having so many small choices increased my stress and reduced my ability to get things done.

Then, about a month or so ago, I heard “inbox zero” mentioned. I intuitively grasped the concept and set about finding a better way to process my email that reduces my effort, stress, and mess. It’s most obvious feature is that you have zero emails in you inbox.

Now (Feb 20th) I’ve been doing this for over a month and have gotten faster and better at it. Here’s my updated system, which I call zero inbox.

Before you practice zero inbox, train Gmail to sort your messages.

  • Scan and delete the messages that don’t matter.
    • In Gmail, this includes everything in your Social and Promotions tabs.
  • Scan and read the messages that matter. Do the following and then archive these.
    • Respond briefly, if needed
    • Forward messages that require attention or action from others. Include a note saying what you want them to notice or do.
    • If writing this note takes more than a few minutes, schedule a 10-minute videoconference or call with them.
    • Make to-do tasks from messages require further action. (Don’t let yourself start working on this things now.)

When you’re done every message should be deleted or archive. Your inbox should be empty.

It helps to know what your focus/responsibilities/goals/interests are. Don’t waste time on messages that fall outside of these. Don’t get sucked into email threads that don’t concern you or your work.