How to fit "reveiw requested" and refreshing beta server into workflow

[kdahlquist]

Due to issue #382 and #388, we've sorted out the mechanics of our workflow, i.e., work on forks of code, merge beta into your fork before a work session, manage merges back to beta with pull requests. Also, everybody now has access to the server to make their changes "live" so @kdahlquist can see.

However, as I noted in issue #393, there needs to be some notification that changes have, in fact, been pushed to the beta server other than the date last modified on the web page. I think that we should use the patch numbers for this and that the next person to push to the beta server should call it 2.0.1 and count up from there. According to the web page, beta hasn't been refreshed since 9/16/16, but that can't be right...

However, I want to also make sure that we go through the review requested process, which means that for changes to functionality or anything a user will see, it needs to be pushed to the beta server so that @kdahlquist can look at it before we close it. For example, #285 got closed without me being able to review it.

If there is a reluctance to refresh the beta server, then our process isn't really working and we need to figure out what will work.

[kdahlquist]

Upon discussion between @NAnguiano, @dondi, and @kdahlquist, here are some revisions to our process.

1. You cannot accept your own pull request.
   • A second team member must independently run the tests, and they should pass.
   • The second team member must also independently make sure that the code actually runs on a local version of the site.
   • If both of these work, then the pull request can be accepted.
2. Step 1 is critical because we want the code to be working when the beta server gets refreshed. After beta gets refreshed, check that the live version of the site works (loading a few demo graphs).
   • When refreshing beta, bump the third (patch) version number. For example, 2.0.1 will get bumped to 2.0.2.
   • Also change the last modified date on the beta page to the current date.
3. After beta gets refreshed, make a comment in issue Comment on this issue when beta is refreshed. #406 so that everyone gets notified.
4. Mark whatever issue the change pertained to as "reveiw requested" and assign to @kdahlquist. Issues will be closed after it passes the final check by @kdahlquist (or she delegates to someone else).

Everyone, please sign off on this new process:

• @kdahlquist
• @dondi
• @NAnguiano
• @anuvarsh
• @yshin4
• @mihirsamdarshi
• @ebachoura
• @eileenchoe

[NAnguiano]

I just learned that if you make absolutely any commits to your forked beta branch before the pull request is accepted, it adds them to your pull request. So if you want to begin working on a different issue before your PR is accepted, make sure to do it in a different branch, then merge that branch into beta once the PR is accepted.

[dondi]

Yes, pull requests are “live”—they accrue more commits if you push to them. This can go both ways. On the one hand, like @NAnguiano said, if you are moving on to a new project, you’ll want to start working in a branch first. On the other hand, if you notice something that needs a fix, then you can just work and commit (and push) to the same branch, and this will be reflected in the pull request.

[dondi]

I’ve been meaning to post this for a while and am finally getting around to it. The workflow we have right now is nearly the same as Atlassian’s “Gitflow Workflow,” except that we don’t (yet) have the concept of release branches. I think it will be useful for the team to look at the process described here:

https://www.atlassian.com/git/tutorials/comparing-workflows#gitflow-workflow

You will recognize that this is almost nearly what we’re doing now, except that we call our development branch beta, and we don’t do release branches. The rules for when to push/pull/merge are also more precise in Gitflow (e.g., Gitflow actually does not recommend pulling from development while work progresses; instead, all reconciliation is done in develop/beta). We can match our process more closely to Gitflow if the team thinks this is a better way to work.

[kdahlquist]

I took a look at this and it looks promising. However, I don't want to implement anything new to our workflow at this point in the semester. Let's revisit this during our summer sprint.

[kdahlquist]

Backlogging this to the summer.