Proposal: Collect MVP code & docs into one github repo


#1

@Webb.Peter What do you think about setting up a github repo for collecting the MVP code and documentation all in one place? The idea would be to organize what you’ve got now to lay the foundation for making changes and improvements in a way that’s easier to keep track of going forward.

It sounds like @webbhm would prefer not to be on the hook for maintaining the MVP repo long-term. So, perhaps I could help you set up a code and documentation repo under your github account.

I can help you get the repo started, and I’d also be interested in helping transcribe your existing documentation from the google doc & powerpoint stuff into markdown documents in the github repo.

[edit: If you like the general concept, let me know, and I’ll follow up with more details about how we might get a github workflow up and running.]


$300 Food Computer - MVP
#2

Is there a problem with starting to compile in the Wiki (we already have)?: https://wiki.openag.media.mit.edu/mvp_1

In terms of GitHub - let me give it some thought, I’d rather not reinvent the wheel here from what @rbaynes has already outlined here: https://wiki.openag.media.mit.edu/contributing/start

There was also a discussion/RFC regarding GitHub workflow here: https://github.com/OpenAgInitiative/openag_brain/issues/272

In my ideal world, the MVP GitHub would be “owned” by the OpenAg Foundation, though I understand after the Mozilla case there are regulations regarding a 501c3 managing open-source software. I do intend to sell commercial kits of the MVP and I worry that my ownership of the GitHub repo might jeopardize the integrity of the open-source software.

Im all for consolidating documentation and following a more defined GitHub workflow for the MVP. I do have a desire to personally be more involved in GitHub administration, and would be willing to own the repo. I’ll wait for others to reply and do some more research into GitHub repo management before I speak to this further.


#3

@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.]


#4

@wsnook, to be clear: I would be willing to run (with @webbhm’s help) a Git and transfer MVP documentation to it, and would really appreciate your help.

I am not challenging the value of Git, I absolutely understand and agree with you it’s the right path. I just am trying to keep the community best interests in mind about how we actually set this up.

I will reply in more detail later. I am in complete agreement let’s get more deliberate about Git and transfer ownership away from a singular individual. Also, I’ve been wanting to move away from Google docs and planned to for next iteration. I’m Swamped or I’d reply now (Ironically I’m doing MVP documentation photos) but I’ll continue this more over the weekend as I get time.


#5

@Webb.Peter Great. Sounds like we’re on the same page or close enough. This next suggestion might be more trouble than help, so I won’t act on it without your say so, but…

If you think it would be beneficial, I could fork https://github.com/webbhm/OpenAg-MVP, begin merging existing documentation into it, and plan to transfer ownership of my fork to you or some other organization as soon as you reach a decision about where it should live. [edit: Alternately, I could make a pull request to merge my changes back into @webbhm’s existing repo. In that case, he could add you as a collaborator to help manage it (see https://help.github.com/articles/inviting-collaborators-to-a-personal-repository/ )]

It might be better for me to just occupy myself with other things until you’ve had a chance to think it over and talk to more folks. Your call.

Here are some docs on transferring repo ownership–it’s fairly simple: