18F and FS review and ensure that all documentation is up to date

[cmajel]

Background This relates to success criteria 15: A team member wants to make a change to the current application and wonders what went into the initial decision. They find and access documentation from earlier phases of the project that informs their decision to make a different sort of change and they update the documentation accordingly (Box drive, GitHub wiki, etc.).

The goal is for us to be updating documentation regularly. This is an issue to review our current wiki documentation and identify what, if any, adjustments are needed before the vendor team comes on board.

Timing of this depends on when a vendor comes on board, and may pair nicely with #385

We'll know we're done when...

• [x] We've reviewed our documentation and edited, added, or removed documentation so that our documentation feels honest, clear and up to date.
• [x] Future team members have explanation and direction on where to find user stories and where to pick up them up.
• [x] Future team members know where the project stands

Tasks

• [ ]
• [ ]

[cmajel]

Documenting this thought. As I was looking for past work on share of agreements by type, I thought that a short primer on grants and agreements and surface some key research artifacts that we found useful in addition to artifacts we've created.

A few things I'm thinking of

• Short write up on what's currently handled by the system (grants, agreements of various types) and what is not (contracting).
• G&A User guide
• Agreement decision tree
• Distribution of agreements by type
• Defining some key terms/systems (provision, grant vs agreement, FMMI, RACA, iWeb)

This also relates to #299

[neilmb]

I believe this is done and the Google doc at https://docs.google.com/document/d/1VcitXr5MZ1J6_EcMk4WSJYtz6VchxtigxsSliaCE49k is where future 18F team members would look to know where the project stands.