On Sun, Sep 21, 2014 at 12:04:12AM -0400, Marianne Corvellec wrote: > Plus, I concur with Titus that it wouldn't be manageable to > add/include/append to the SWC materials any and every other tool > that might be used out there.
I certainly focus *my* efforts on the Shell/Git/Python side of our standard lessons, because I don't know, or really care, about R/Mercurial/…. Does that mean I think the folks who are working on those lessons are wasting their time and should be contributing to the lessons for my tools? No. There's a niche for just about every too (although I think Python has a bigger niche than, say, Matlab ;). Will explain to the curious why I use the tools I do? Absolutely. Will I treat them as second-class citizens if they want to teach/learn other tools? No [1]. > We want to focus our efforts indeed; for instance, I can't imagine > how instructor training would remain consistent and manageable, if > we don't have a somewhat standard, small enough curriculum/toolset. As I understand it, instructor training is mostly about pedagogy. For example: $ git log -p -G 'git ' origin/master..origin/pr/703 shows no mention of a Git command in the current version of the instructor course (see also [2]). The best-practices paper doesn't force a particular toolset [3,4,5,6], so and I think that pitching that big tent is important. For example [6]: “Many good VCSes are open source and freely available…. As with coding style, the best one to use is almost always whatever your colleagues are already using.” If instructors are already comfortable with some tool that fits the bill, I'm happy letting them use that. I'm also happy pointing the ones that *don't* come in with tools in their box towards our favorites, and helping bring them up to speed there. If a diversity of tools makes it slightly harder to collaborate on lesson development (and Git-vs-Mercurial is not going to make things that much different), I think the costs are outweighed by the benefits of having a larger pool of potential instructors and students. Porting the lesson on modular, testable development from Python to Excel is not something *I* know how to do, but I'm not going to stand in the way of anyone who does want to do that. Anything that gets our best-principles in front of students is going to make their science better. Cheers, Trevor [1]: The equal-standing for any tool is part of the reason I've been pushing for isolated, per-lesson branches [7], because I don't want folks working on lessons for some oddball tool to clutter swcarpentry/bc, and (fair's fair) that means the core tools should be in their own branches too. Then we don't even have to agree on what's core. Greg can pull the stuff *he* thinks is core into swcarpentry/bc (and we'll mostly use that assembly), but it's easy for folks with different sets of core tool to collect their own assembly. [2]: http://lists.software-carpentry.org/pipermail/discuss_lists.software-carpentry.org/2014-August/001958.html [3]: http://software-carpentry.org/blog/2012/10/best-practices-for-scientific-computing.html [4]: http://arxiv.org/abs/1210.0530 [5]: http://software-carpentry.org/blog/2014/01/best-practices-has-been-published.html [6]: http://www.plosbiology.org/article/info%3Adoi%2F10.1371%2Fjournal.pbio.1001745 [7]: https://github.com/swcarpentry/bc/issues/102 -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
