Add MVP fields to models.

[toolness]

This is a work-in-progress attempt to add the MVP model fields as specified by @melodykramer.

Note: I added django-test-without-migrations to make it possible to experiment with models and run tests without having to generate new migrations every time one changes a model. This can be enabled by running python manage.py test --nomigrations.

Still to be done:

• [x] Need to somehow add a "list of links to live site(s)" field. This could just be a one-to-many field, or it could just be another field of Markdown-enabled text. I guess one benefit of having it be a list of links is that we can regularly test to see if those links are still up, and poke project maintainers to update the DB record if they're down for an extended period of time? Also, if this is a one-to-many field, we might want the corresponding LiveSite model to have an optional "description" field so that we can have human-readable description of what each link is, e.g. "staging", "documentation", "production", or whatnot?

  Alternatively, we could just have one link and expect any extra links to be linked-to from the GitHub README or the project description markdown or something?

• [ ] I've taken a stab at adding help_text for each field, which will show up in the admin UI. These should be something that non-technical admins can understand, so @melodykramer, if you have better descriptions for this help text, let me know!
• [x] I should probably add some kind of validation logic to the "GitHub URL" field, so that if someone pastes in a link that's not of the form https://github.com/{ORG}/{REPO}, we reject it. Spun this off into #9.
• [x] I'm unfamiliar with the "Tock ID" field. Should it be unique?
• [x] Decide how we want to process Markdown. In previous projects, I've stored unsanitized Markdown in the DB and sanitized it when rendering it to a view via Markdown and bleach, which has the benefit of never losing user data due to sanitization, and also allowing us to easily iterate on the sanitization algorithm. But I'm up for other suggestions!
• [x] Figure out if any of these fields are allowed to be blank.

[melodykramer]

For the links, I recommend just one, and then having the rest in the README.

The Tock ID is unique for each engagement - it's the field that we use internally for billing.

Will look at the help test.

Yes, some of the fields should be able to be left blank. Not every project has a link or a GitHub page. Every project should have a name, description, and impact statement....

[toolness]

Awesome!

I assume Tock ID should also be able to be left blank, too? Since a project might be so new that it doesn't yet have a Tock ID?

[toolness]

Oh, I just realized that another alternative to "live site URL" is to simply pull that from GitHub as well, since every repo can have a URL associated with it:

This won't work if the project has a live site URL but doesn't have a GitHub repo, though.

For that matter, I guess the tagline can be pulled from GitHub too, if we want to keep things DRY and the project has a repository...

[brendansudol]

I'd prefer us just explicitly adding these fields ourselves vs fetching from GitHub and relying on those being right and up to date and want we want to show

[brendansudol]

Yes, tock_id should be nullable

[brendansudol]

Totally agree with your approach on Markdown (storing raw and converting on render)!

[batemapf]

i disagree with https://github.com/18F/projects/pull/5#issuecomment-218799353 re: nullable tock_id. if it is something we are working on, it should be in tock and we should be tracking effort against it. if it is so new that no work has been performed on it, then it probably shouldn't be showing up here.

[melodykramer]

There will be things here that are not in Tock. Thinking of something like Bronto, which is a tool we created but was not an IAA or billable project.

[batemapf]

if it is something we are working on, regardless of billability, it should be in tock. goes to see if this project project is in tock :-/

[batemapf]

ah, Dashboard looks like the ticket.

[brendansudol]

i think it still needs to be nullable even if everything will eventually get in tock (for the case when we add a new project and before it syncs with tock which then triggers a new tock_id which would get picked up in /projects)

[batemapf]

ah good point @brendansudol. if workflow is projects ---> tock for establishing new projects then 👍

[brendansudol]

after the conflicts are resolved, this PR LGTM -- happy to punt on the github URL validation bit

[toolness]

Woot, thanks @brendansudol--just merged and added the db migration. Will commit as soon as travis is happy.

[brendansudol]

🎉