Process for Reviewing Internal Technical Documentation

Service integrations are reviewed whenever someone leaves the team to ensure that they are not responsible for a particular service.

Of our technical documentation, these pages are the most likely to require updating:

• https://github.com/programminghistorian/jekyll/wiki/Making-Technical-Contributions
• https://github.com/programminghistorian/jekyll/wiki/Technical-Tutorial-on-Search
• https://github.com/programminghistorian/jekyll/wiki/Technical-Tutorial-on-Setting-Up-a-New-Language
• https://github.com/programminghistorian/jekyll/wiki/Technical-Tutorial-on-Translation-Links
• https://github.com/programminghistorian/jekyll/blob/gh-pages/_layouts/crossref.xml
• https://github.com/programminghistorian/jekyll/wiki/How-to-Request-a-new-DOI

But by far the most difficult changes will be those that come from outside the team, as when the GitHub interface changed. The most likely page to need review, then, is the "Making Technical Contributions" wiki - https://github.com/programminghistorian/jekyll/wiki/Making-Technical-Contributions. When reviewing them for necessary updates, these principles should be kept in mind.

1. Aesthetic changes in the screenshots can probably be ignored. GitHub switched to rounded corners, for example, but that is unlikely going to throw people off on its own.
2. Any icon changes or more minor changes to the interface should be noted in the running text.
3. Any substantial changes to the interface probably require a new screenshot. Otherwise, older screenshots can probably still serve.

It's probably a good idea to review these pages once annually. If pressed for time, that particular page could be broken up into two tasks and assigned to different people:

1. "Editing the site using GitHub through responding to a review"
2. "developing this site locally" through the end

Technical documentation last reviewed by @walshbr 7/10/2020