Developer workflow

The master branch contains the latest stable version of the project. During the week, all check-ins are made to an intermediate branch called dev. On Fridays, we merge dev to master. The dev branch is the only branch that is allowed to merge directly to master.

Some other conventions:

• All work in Iris is tracked via GitHub issues. No code is checked in without one.
• Each branch must be named for the issue that it addresses, e.g. issue_250.
• Requests for review - and code approvals - are done in the GitHub issue or the pull request.
• Commit messages should be descriptive and follow proper spelling and grammar. -- The commit message should ideally be phrased to finish the statement "Applying this patch will ________" Using that format will also encourage you to write your commit message in the present tense: “Fix bug” and not “Fixed bug.”

Getting your code into Iris

If you are not a direct contributor to this repo, then you will be working from your own fork of Iris. Either way, the steps below are the same.

1. Have an issue assigned to you to work on.
2. Sync to the latest dev branch.
3. Create a local branch from dev, named for the issue that you are working on, e.g. issue_2002.

git checkout dev
git checkout -b issue_2002

4. Do your work.
5. When you are finished, rebase to the upstream dev branch to minimize merge problems.
   Note:
   We generally rebase commits rather than squash them, to retain original authorship information. If you have multiple commits that you want to eliminate, be sure to clean those up before final submission.
6. Request a review by creating a pull request against the dev branch. Specify the type of review you'd like. See below for important information about code review.
7. Once approved, your code will be landed by the sheriff on duty.
8. Issues are generally closed on Fridays when we merge.

---

Code review

Like most software, code in Iris is reviewed by a project developer. However, we are offering a new type of review that we feel can help beginners get their code landed faster, and hopefully eliminate some of the barriers to becoming a community member. We call this process revision.

Just as it sounds, revision means that the reviewer will, in addition to review, make direct edits to code to correct it for any logical or style problems. After a revision, the reviewer may or may not pass it back to the contributor for more work. They may also just choose to land it.

Advantages to the revision process:

• Code does not have to be perfect to be considered a submission.
• Moves faster than the standard review process due to less back-and-forth iterations.
• Contributor can learn from a working example and improve.
• Multiple people working on the same code motivates all parties to create the best result.

Submitting code for revision does not mean a submission will be guaranteed to be accepted as such. If the code needs substantial work, the reviewer may send it back without edits to request changes. The goal of revision is to accelerate the process and optimize the efforts of all parties involved.

Potential disadvantages to revision:

• Loss of ownership of code. Technically speaking, more than one person is writing it.
• Depending on Git usage, statistics on code authorship may be inaccurate when it finally lands. This is a concern for some people.

When your submission is ready, specify if you'd like a standard review, or a revision.