I don't know if the materials should cover this or not, but I wanted to mention some challenges I've seen when working with beginners.
Infrequent requests for review Submitting reviews is good, but make sure your contributors know to submit reviews often. Beginners might be worried about interrupting. I've assured people by giving them specific advice on how long they can go before interrupting. Unrelated changesets I see the materials that Titus linked to stress not submitting reviews with too many changes. In addition, I tell people not to submit a review for code that is not a logical changeset. Find better terminology than what I just used. On to general thoughts, and not things that go in the contributor docs or code review guidelines. When organizing contributing guidelines, you might want a very friendly, short version for novices so that they feel like erring on the side of making contributions rather than not. And perhaps you'll have another repo with guidelines for your experienced contributors on working with new contributors. Speaking from the context of an industry environment, I'd expect college-hires to make mistakes. I'd expect them to have knowledge gaps. This means that I'd expect to dedicate extra time to accepting sloppy contributions at first and using mistakes -- like unrelated changesets, too large of a code review, weird design decisions -- as lessons for explaining how to do better work. If there is a college hire on a team and the more experienced engineers didn't do that, it would be like they threw the poor kid under a bus. what the heck. On Mon, Sep 29, 2014 at 4: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 > -- [email protected]
_______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
