Clarifies how fields in about.yml files are used

[gboone]

Adds information about specific ways the Dashboard implements each field. @leahbannon this incorporates the changes you made earlier plus adds some clarification based on the questions you asked while editing 18F/openFEC's about.yml file.

@arowla @mbland I'm unsure of whether to incorporate these changes over to 18F/about_yml. They're important clarifications for the dashboard. I wonder if something so specific to how the API is implemented in one instance will be universally useful. Happy to do the porting if it is but wanted to flag it for discussion in case.

[ultrasaurus]

Still feels pretty "repo" -centric -- the dashboard isn't about repos, it's about projects. We should omit anything from about.yml which is not yet implemented in the dashboard (or move them into a separate section)

[ultrasaurus]

I wonder if at this point we should just link to the about.yml doc and improve that and highlight the few things that comms feels are really important for the dashboard, along with links to some good examples.

Also, we should mention that data-private works for projects that don't have a repo, and takes precendent over informaton in a repo.

[mbland]

Rather than remove things wholesale from about.yml that aren't implemented in the Dashboard (after all, the Dashboard is but one user), @jmcarp and the rest of the Testing Grouplet folks started bouncing around the idea of having separate schema components that can be embedded for different type of projects. One of those components could be "everything needed by the dashboard", and not every .about.yml need include it.

Also re: data-private, if a project does have a repo, updates to the repo's .about.yml will take precedence.

[arowla]

Agreed that we may want to have separate schema components in a future version. However, I think that should track more closely to the type of project being described, and less to particular consumers of the data. Where we might want to tailor things more to the data consumer is in creating separate template generators or CLI advisors tailored toward the particular use that's in mind. .about.yml itself needs to remain unopinionated about how the data therein will be used.

I think perhaps the short-term solution here is to have these docs only list .about.yml fields that are implemented in the Dashboard, while linking to the full spec.

[mbland]

Let's fold the questions from 18F/about_yml#39 into the schema and update this PR once that's done.

[gboone]

This is obsolete with #318 and #317