Add maintenance guide to the documentation

[eloquence]

There are some tasks a SecureDrop team should perform regularly, for example:

• Creating and testing workstation backups
• Creating and verifying server backups
• Clearing out old submissions on the server (may be a journalist responsibility)

Admins will also need to perform tasks in response to certain events, for example:

• After releases: Updating Tails and the SecureDrop code on the workstations
• After staff off-boarding: Rotating shared credentials, updating support portal membership
• After staff on-boarding: Updating support portal membership
• After security or maintenance advisories: Performing server administration tasks

Let's add a guide to regular maintenance tasks to the documentation, so administrators can add recurring tasks to their calendar, and put processes in place for tasks triggered by certain events.

User Story

• As a SecureDrop administrator, I would like to know what I have to do to keep my SecureDrop maintainable and secure, once I've set it up.

[ninavizz]

I really like the idea of not doing this as a standard section w/in RTD, and instead beginning to break-out things as stand-alone artifacts—as discussed in the meeting (obvs they'd also get redundantly documented in RTD, but RTD would not be a user access dependency).

Could we maybe create a different GH label to begin tracking such things (including the SourceGuide) so they're clearly identified as opportunities to be explored outside RTD? Maybe "LearningMaterials" or "ServiceDesign" or "NewsroomEd" or "UserGuides"?

[ninavizz]

(not suggesting the docs tag be abandoned for the other tag, but that they'd exist in tandem—only so the other tag could exist to track the non-RTD stuff)

[eloquence]

There are a couple of artifacts referenced in the docs already:

• Downloadable equipment labels: https://docs.securedrop.org/en/release-0.12.2/hardware.html#labeling-equipment
• Installation worksheet linked from: https://docs.securedrop.org/en/release-0.12.2/before_you_begin.html
• Sample privacy policy: https://docs.securedrop.org/en/release-0.12.2/deployment/sample_privacy_policy.html

I think the right answer here is probably is a combination of a docs section and potentially similar artifacts like an example GCal. IMO having a "Maintain SecureDrop" section (after "Install SecureDrop") would be a logical way to organize some existing topic guides, and a new guide to regular maintenance tasks. (Thanks to @pierwill for suggesting that.)