WIP: qasp template

[stvnrlly]

TODO:

• [x] Update accessibility standard
• [ ] Clarify acceptable code coverage reporters
• [ ] Specify branch or statement coverage rather than line coverage
• [x] Remove language requirements
• [ ] Mention .about.yml
• [ ] Mention system-security-plan.yml
• [ ] Mention opencontrol.yaml

For those last three, they are covered by the "before you ship" guide that we link, but I don't think that it hurts to separately call out those required files.

[stvnrlly]

Looks like @mgwalker's comment about code coverage got lost to an outdated diff:

The biggest problem with hard metrics like this, I think, is that it encourages vendors to focus on those numbers rather than quality code. Squishier metrics take more time to evaluate on our end, though.

We may be well-served to spend some time figuring out metrics that describe technical debt, too. Things like cyclomatic complexity, statement depth, and function length?

That seems true. On a certain level, though, I think that if we want something simpler we should use a metric (or metrics) that provides some predictability, even if it isn't the ideal one. But we could probably put together a more in-depth guide to how we evaluate code coverage that would allow us to use a more accurate metric but apply it consistently to provide that predictability. We might want to involve 18F in that, if we wanted to go that route.