Document pull request builds.

[smashwilson]

Fixes #223.

[smashwilson]

If you want to double-check your formatting, check the preview.

[smashwilson]

Note to future self: the GitHub status plugin doesn't seem to be firing. I'll need to investigate on Monday.

[smashwilson]

The organization of the "Authoring Content" section is not great right now. We have:

• "Opening blurb that's probably too technical"
• "Adding a new repository, the happy path"
• "Over-detailed explanation about content mapping that you probably don't need to know yet"
• "Tiny pull request builder section"
• "Way too much information about setup for non-happy paths"
• Then: "Links to specialized info about Jekyll/Sphinx."

I'd like to break it up and shuffle things around a little to be more useful. Here's what I'm thinking now:

• "Setting Up"
  • Summarize the prerequisites. A GitHub account, knowing where the control repository is, that kind of thing.
  • Existing "Adding a new repository" section.
• "Actually Writing"
  • Specialized Jekyll/Sphinx sections
  • Tips and command cheatsheet for git and GitHub workflow
  • Using the pull request builder
  • Troubleshooting: build failures, preparer failures, ...
• "Publishing"
  • "Where your content will live"
• "Special Cases"
  • "Custom Content Repositories" and other things that don't fit the happy path.

@meker12: does this sound a bit more useful? Is there anything else that I should try to add here?

[meker12]

@smashwilson I like your proposed restructuring. It's useful to have the more detailed, technical stuff for people who want to have a deeper understanding of the system for troubleshooting and such. So, I wouldn't get rid of the existing content. I see the content you propose as the layer on top that's more functional for people who are using deconst for authoring, build, and deploy.

[smashwilson]

:mag_right: Preview

[smashwilson]

@smashwilson I like your proposed restructuring.

:+1: Cool, I'll move ahead with it as part of this PR. (This is also useful for me to identify and chase down any issues with the Strider PR builds.)

It's useful to have the more detailed, technical stuff for people who want to have a deeper understanding of the system for troubleshooting and such. So, I wouldn't get rid of the existing content. I see the content you propose as the layer on top that's more functional for people who are using deconst for authoring, build, and deploy.

Yeah, I don't think I'm deleting anything, just shuffling it around and adding a section or two. The sections about custom builds and special cases is especially important for anyone adding content that doesn't fit our "easy path" criteria, for example. I was just re-skimming it with a critical eye and realizing that it was much too front-and-center for the most common reader right now, who does meet those criteria.

[smashwilson]

Your content preview is now ready. :bow:

[smashwilson]

To elaborate, you can see the log for the latest Strider pull request build after clicking "Show all checks":

Or by clicking on the green check or red X on any specific commit:

[smashwilson]

I'm going to split the general restructuring out into its own issue, then merge this as-is so we have something in the short term, especially now that pull request builds are live.