3a. Record what's new
Saving your game starts by taking everything out of your head and putting it down as new passive context for next time, putting it in as useful a place as possible.
Hint: Be generously kind to whoever loads the game next. That's basically it. It could be you, it could be someone else. Save the game such that it could easily be either. The more kind to the future you are, the better the odds of your (and our) future good health, which in turn improves things for the good health of all across the timeline.
GitHub for updates to application code
GitBook for documentation about the customer-facing product as it exists right now
Canny for anything about the customer-facing product as it may exist
A potential future truth about the product is always motivated by a current truth about the product interface as it exists right now. Therefore, whenever you log something in Canny, add links to it in the appropriate areas of GitBook as well.
GitHub Issues for anything about the internal-facing product
Do it now
Write the documentation. Update the code. Do whatever it means to take the new knowledge you have and move it out of your head, putting it somewhere that the world can reach it.
Do it. Right now, no waiting, with all the facts as they exist right now, even if the fact is that something is incomplete or in progress or never gonna happen.
Seriously, go do it now. In one session, and publish it before you get up. Do not trust yourself to remember later. Whatever you were going to do next can wait a minute.
This seems hard!
Run through the list below. If you're still stuck, ask Isaac.
If there's nothing to do, the thing they asked just isn't possible...
Easy! Document that! And look forward to spending less time on this question in the future!
If the problem is knowable but the solution changes every time...
Write documentation describing the process to find a solution. Even if the solution has to be invented each time, you can at least improve the situation by layout out debugging/diagnosing/design steps.
If you don't have time to do it to your own satisfaction...
That's okay! Compromise!
Do a short/incomplete version, and label it "incomplete" with a note asking people to write to support for more information.
Or, post the notes you have to Slack, and skip GitBook entirely.
Better to have incomplete but usable information out there than no information at all. If people need more information, they can write in, and we'll all have a head start on the situation because of the partial documentation you accomplished.
Consider also that this game is about playing for health on behalf of the product. Health is in the moment; it's not a speed thing. It's okay to slow down your pace and your output in service of health.
But, you know, don't compromise your own health in the process. :) If your pace is important to you, factor that in as you decide how to use your time.
If the information you have is uncomfortably incomplete...
That's okay! Publish it anyway! The information that we-the-product-authorities have examined this thing and have come up short (or even empty) is useful information to have out there in the world.
Publish what you have, with a highlighted "if you need more information, write to team@[whatever]" info block at the end. That way, you're effectively signing yourself up for push notifications whenever someone needs more than what's there.
If the specifics are sensitive...
Enable yourself to go more public by generalizing the information (and then generalize it again, if needed) until you get to some public-friendly representation of the thing, no matter how vague it ends up being.
As an exercise, really push yourself here - generalize until you have something publishable. Keep generalizing until you either create something publishable, or until you end up with something that's already published. (If you end up with something that's already published, good job! You now have a documentation link to send someone, and your work is done!)
If it involves a change to product code...
If it's quick and you can do it yourself, do it yourself
Otherwise, file it in Canny (for customer-facing bugs or possible enhancements) or GitHub Issues (for internal-facing bugs or possible enhancements)
Write (or update) GitBook documentation, describing the context and then linking to Canny
Last updated