Pre DocOps Steps

[cloudjumpercat]

• (Requires a GH account) Introduction to GitHub GH course (learn how to use issues, branches, PRs, PR reviews, make commits, etc.)
• (Requires a GH account) Communicating using Markdown GH course. This is super basic formatting but gets you used to using Markdown content in GH and publishing it in GH Pages.
• Really, most of the GH courses in the learning lab will only be beneficial, so you can do more of those if you want.
• Pick a template or decide kind of what you want the site to look like/what capabilities you want it to have. Make sure it's written in a language you can support (most DocOps people will know HTML/CSS/JavaScript at least, if you want to make the site from scratch front-end devs will know more languages/have more capabilities). And make sure it can support the file format you want your content in (likely markdown).
• Do you plan to do any content overhauls/re-architecting before the migration? If so, I would make a plan to get that completed as the last step will be the migration itself (so you don't have to work out of two systems).
• Are there any Markdown formatting exceptions you want to make? If so, make a list of those.
• (Optional, kind of future looking) Do you still plan to use Splunk for your style guide? If you're open to switching, consider picking one that is already created for Vale (see their GitHub repo for more info).
• (Optional, kind of future looking) If you don't have it already, come up with a list of LM specific terms/style guide that you want to use in addition to your base style guide.
• Bonus points if you can find a way to make the content conversion from WP to MD easier. Right now, WP exports to one XML file which is then converted into MD files for each "post"/page (if you convert content using something similar to what I've been doing). So it's doable to sort through all the converted posts and put them back into the correct "folders"/file structure. Using tags on the content could make it easier because then you can filter based on tag when you export, so DocOps could export folder by folder so it's not so chaotic.