Develop checklist for protocols code review

[ctb]

Now that several people are regularly making changes to the protocols, I'd like to start doing slightly more formal pull requests and code reviews. Please add your own thoughts!

Necessary:

• the changes have been reviewed by someone other than the original author;
• the changes show correct formatting when built with Sphinx;

Recommended but not required:

• the changes work under our literate-resting tests with a small data set;

[ctb]

@mr-c thoughts?

[ctb]

• the changes show correct formatting when built with Sphinx;
• the changes have been reviewed by someone other than the original author;
• the changes work under our literate-resting tests with a small data set (suggested but not required)

[mr-c]

Is the reviewer locally building the pull request or shall we have Jenkins do so?

Any guidelines for the scripts and shell code?

[ctb]

On Sun, Jul 06, 2014 at 09:56:38AM -0700, Michael R. Crusoe wrote:

Is the reviewer locally building the pull request or shall we have Jenkins do so?

For now, the reviewer.

Any guidelines for the scripts and shell code?

Nope, not yet. TBDeveloped :)

--t

C. Titus Brown, ctb@msu.edu

[ctb]

@mr-c, what do you think about setting up a standing "test" branch that ReadTheDocs will pull down and build? Then we don't always have to run sphinx locally. We could do this for khmer, too. Bad idea?

[mr-c]

Good idea. I have played around with this before but got stuck on getting
Jenkins to expose the docs through the web interface. I'm sure it is doable
and deserving of another try.

On Sun, Jul 6, 2014 at 2:13 PM, C. Titus Brown notifications@github.com
wrote:

@mr-c https://github.com/mr-c, what do you think about setting up a
standing "test" branch that ReadTheDocs will pull down and build? Then we
don't always have to run sphinx locally. We could do this for khmer, too.
Bad idea?

—
Reply to this email directly or view it on GitHub
#118 (comment)
.

[ctb]

I was thinking of just having it be something you manually push to; we can always automate it later, no?

[mr-c]

They are the same amount of work. shrug
On Jul 6, 2014 2:16 PM, "C. Titus Brown" notifications@github.com wrote:

I was thinking of just having it be something you manually push to; we can
always automate it later, no?

—
Reply to this email directly or view it on GitHub
#118 (comment)
.