Stephen, Bill -- we've been developing a set of resources for khmer, here:
http://khmer.readthedocs.org/en/latest/dev/ that includes code review. --- These two links are probably the most pertinent: http://khmer.readthedocs.org/en/latest/dev/getting-started.html http://khmer.readthedocs.org/en/latest/dev/coding-guidelines-and-review.html with specific reference to the checklist in the latter, which we've found is key to keeping our heads on straight. --- We mostly use GitHub Flow, http://scottchacon.com/2011/08/31/github-flow.html https://guides.github.com/introduction/flow/index.html --- We've successfully run people through this whole procedure (the one in getting-started, above) at both a hackathon and now with people in my lab including some undergrads who started out with no knowledge of git. We wrote up the hackathon experience here, figshare.com/articles/Channeling_community_contributions_to_scientific_software_a_hackathon_experience/1112541 What I think is our clearest takeaway is that there's little point in proselytizing code review without giving people explicit procedural mechanisms - we run people through code review of THEIR code several times, making sure they understand the github stuff, before introducing the broader picture. (There are, of course, links if they want to go explore on their own.) To get all technical, I guess the cognitive challenge of learning a new workflow interferes with the cognitive challenge of embracing code review, so "pick 1". cheers, --titus On Tue, Sep 30, 2014 at 12:21:21PM +0000, Turner, Stephen D. (sdt5z) wrote: > Bill, > > Not sure if you want this kind of thing as an issue on GH or just over email, > but a suggestion: > > Having a knowledge of git/github that goes only slightly deeper than what we > teach in SWC bootcamps, I wouldn't call myself a Git expert by any means. I'm > never sure the best way to review a PR locally that comes in to SWC lessons > (or any other code for that matter). It is also seemingly more complicated > when multiple PRs come in against the same code, where even I may have my own > local changes that haven't been merged yet. I believe there was a helpful > protocol somewhere in the swcarpentry/bc repo, but I forgot where it is. A > discussion of the operational aspects like this would be helpful, depending > on your desired scope. > > Stephen > > > > On Sep 29, 2014, at 5:05 PM, Bill Mills <[email protected]> wrote: > > > Hey all, > > > > Just wanted to direct your attention to some content that I'll be pulling > > together over the next little while: > > https://github.com/mozillascience/codeReview > > > > I'm building lessons, exercises and content around the idea of code review > > for scientists, based on the pilot programs on the same that Mozilla > > Science Lab recently supported, research from the broader community, and my > > own experience in the wild. > > > > What's there now are just some super quick & dirty notes, but I'm hoping to > > clear my schedule and build some substantial content over the next week, > > and beyond; as always, MSL projects are CC-BY, so feel free to remix for > > SWC or any other purpose. Pull requests, issues & comments strongly > > encouraged, > > > > -- > > Bill Mills > > Community Manager, Mozilla Science Lab > > @billdoesphysics > > > > > > _______________________________________________ > > Discuss mailing list > > [email protected] > > http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org > > > _______________________________________________ > Discuss mailing list > [email protected] > http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org -- C. Titus Brown, [email protected] _______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
