3b. Push the update

Recording the context is good. If gameplay is gonna continue in someone else's hands, decide what qualifies as active context, and push it to the next player.

Documentation-free email

We send a lot of email. Documentation belongs in public, where it can be re-used. It doesn't belong in email. If you're creating new information, record it publicly, and link to it in your email.

If you find yourself writing a long paragraph in your email, or annotating screenshots to add to the email, switch gears and put it in the docs instead.

There are reasons for this!

• Keeping it DRY (Don't Repeat Yourself - it's a programming thing). You (or someone) already wrote out the answer once in the docs, so don't write it again. If you find yourself tempted to rewrite it for the customer, scratch that itch by updating/improving/expanding/reorganizing the documentation itself instead.

• Sending a documentation link reinforces the idea that The Docs are the place to go for authoritative information, teaching the user that they can go get help on their own timeline without having to wait and talk to us.

• Sending them to our docs creates a chance that they'll discover additional useful information while they're there.

• The more you do this, the less often you'll have to do it. (Don't think about that too hard.)

• Reading is hard! Every word you add to your email increases the risk of the reader missing a detail.

Example

[greeting]

[brief brief brief BRIEF summary of actions taken]

[documentation links (3 max)]

[asks (3 max, but 1 is best)]

[sign-off]

For example:

Hey there,

I looked into it, and wasn't able to fully address [the thing]. However, I did [the other thing], which helped in [these ways].

You can learn more about this here:

• https://example.com/here-is-some-documentation

If you'd like me to dig in further, please send me [the things I need in order to continue].

Thanks,

[me]