Our github workflow

[fosterlynn]

Hey hey, our first issue, I'm honored! :smile:

@christroutner you may have some better ideas based on your experience at KeystoneJS. But here are some thoughts based on our work in ValueFlows (team of 5 basically). And in NRP, Bob and I don't do pull requests (PR), we just branch and merge, as a local team of 2, but have other people issue a PR. So that is my experience, which is not a lot.

I do know we have to decide between fork-and-PR and branch-and-PR or github can't handle it. Or we could just branch and merge for now if we want. Between the first two, we at ValueFlows decided we liked branch-and-PR best because it was less ceremony for a small team in close communication. And for files that are not code, we just edit in place and commit directly. Although PRs are nice for explicitly asking for feedback on a change if the committer is unsure.

So, who will be coding? Chris will be the main person for now? Bob and I will need to do API's to support Chris. But hopefully we will attract others on the UI side. And then we will have Maria and others putting out mockups or other designs.

So what do you all think? I'm leaning towards branch-and-PR for code, edit in place for other files, but I'm good with whatever Chris wants. We could easily go simpler and just merge in, since nobody will be working on overlapping code for now.

[fosterlynn]

As a reference, here is documentation of the branch-and-PR method:

From the "GitHub Flow" workflow

• Anything in the master branch is deployable
• To work on something new, create a descriptively named branch off of master (i.e. fairy-princess-use-case)
• Commit to that branch locally and regularly push your work to the same named branch on the server
• When you need feedback or help, or you think the branch is ready for merging, open a pull request
• After someone else has reviewed and signed off on the feature, you can merge it into master
• Once it is merged and pushed to ‘master’, you can and should deploy immediately

[christroutner]

Lynn, I like your idea about branch-and-PR. I have very limited experience with any options, so going with whatever you are more comfortable with is probably best at this point.

I'll definitely plan on doing coding. I'd love to hear more about the plans for the API. I've been playing around a lot with the KeystoneJS API, which provides an indirect way of querying the CMS database. Ultimately I have it hand over a JSON string (of key-value pairs) through an AJAX GET or POST request. If our API can do something similar, that will make the front-end JavaScript a lot easier to implement.

[bhaugen]

We have a limited set of APIs now, but that's what they do. For example, in this file, find def json https://github.com/Sensorica/valuenetwork/blob/master/valuenetwork/valueaccounting/views.py

I figure we will create more as the UI/UX project needs them. No need for you to dive into the Django code at all.

[fosterlynn]

Chris, agreeing with Bob, and adding: I would like to work with you directly and support your efforts specifically. We can generalize later if need be.

[fosterlynn]

that will make the front-end JavaScript a lot easier to implement

That will be our goal.

[fosterlynn]

OK, so let's do branch-and-PR then.

Bob and I had a discussion this morning about API code. We are thinking we will code the APIs in our original version, and the UI/UX fork can get it from there. Bob understands this better than I do, and can add to this.

[bhaugen]

https://help.github.com/articles/working-with-forks/

Especially:

• https://help.github.com/articles/configuring-a-remote-for-a-fork/
• https://help.github.com/articles/syncing-a-fork/

[fosterlynn]

P.S. The UI/UX fork will want reasonably frequent updates from the original anyway I think, for now.

Those instructions look quite complete, thanks @bhaugen !

[fosterlynn]

Moved the decisions and references to the wiki page called Developer Workflow, closing.