@Webb.Peter Maybe we’re not thinking about this in the same way.
Where I’m coming from is that I’ve worked on teams that used github to maintain code and documentation as part of developing and releasing software products over time. Keeping code and docs together in github helped make things smooth and productive.
On the other hand, I’ve experienced lots of friction and difficulty in the past around documentation that lives outside of a version control system. The core difficulty has to do with maintaining documentation for a stable branch and a development branch–it gets messy to document more than one branch at a time with a wiki, but it’s easy with version controlled text files. I could go on about why wikis have been a problem for me, but I’d probably just irritate people who’ve had wonderful experiences with wikis and horrible experiences with git. For many things, wikis are a good fit. If using git tools is a problem for people on the team, that affects the balance. Git is weird–I can sympathize. But, if you want to keep your sanity maintaining a software-centric project over time, learning to use git can be totally worth it.
Anyway, my interest here is in offering a potential way to make things run more smoothly and remove obstacles to participation for evolving your MVP design. If you would like to pursue a simple, lightweight github centric workflow of the sort I’ve had positive experiences with in the past, I could help you do that. If you’d prefer to go about things some other way, that’s fine be me.
You might like this article: http://www.writethedocs.org/guide/writing/beginners-guide-to-docs/
[edit: To clarify what I mean by a “simple, lightweight…workflow”, I’m concerned about setting up a situation that would place additional time demands on the OpenAg team at MIT. They seem to already have a lot on their plate. I don’t see where they would get the time to be actively involved in merging and reviewing pull requests, making releases, etc. for the MVP. That’s why I suggested you might be a good owner for the code. If things veer off into the territory of extensive discussions of copyright, licenses, and lawyers, I may need to bail out. As far as I’m concerned, the MIT license on your existing code is great, and it’s very compatible with commercial use. I don’t care what the name of the repo/project/product is so long as it does not become a source of distraction. I just wanna get down to the business of making some stuff that works well for growing plants and is easy for people to use.]