Greg, Quite a bit of the discussion since I started this reply seems to hinge on git being useful because of github and cloudiness. I'm going to go back to your original two questions and ignore the cloud, if I may?
For your question 1, I might comment that LD50 isn't usually given all at once, and it varies from patient to impatient (if you'll pardon the attemp at humor). Some people have a higher tolerance for being clumsy at new things than others. I think for many beginners, frustration mounts, and there is usually some 'tipping point', some one thing that convinces them that it is or is just not worth continuing. For example, try to imagine that you're using git as a raw beginner, you change file A on Fri. The following week you come back into work, you change 5 files a day through Thu. You now realize that you want the version of file A from the previous Thu back. How do you restore one file to it's last version? How much git do you need to know to get that one file back? Would a straight 'git revert A' work? For your question 2, perhaps making a list of the functions that version control provides that you consider essential, then having new people rank them in order of importance and figuring out what new people want might be a good start. If we think of beginners as being on a continuum from those who want to write simple control scripts to run other programs, to people who write occasional programs to munge data, to people who write simple software for a particular problem, to the people who end up writing full-blown software projects, then where on that continuum are most of the people who show up to a boot camp? Picking a set of clearly stated functions that a first-time version controller is most likely to want to use and showing them, step-by-step, how easy each of those functions is would be a good first step toward convincing people that it's a good idea. If it isn't easy, well, now the problem has changed to convincing them that the not-easy way is still worth it. Restoring the last version of a single file from some way back seems to me like it would high on a beginner's list of functionality. Not long ago, you asked for some real-world workflow scenarios, and I think the information gleaned from those might apply here, too. Many of the labs I have worked with often work with only a very few files. Those files are likely driver scripts for some other piece of software (or several other pieces of software), and typically what changes are external program parameters and the number of subjects or files on which to run things or their location. Every once in a while, someone will pull a file out of a Matlab toolbox and change something in it to accommodate some local preference. If you are just trying to keep track of, at most, a dozen files in a shared directory on a shared file system, a lot of the power of git simply isn't useful. A lot of science is done without any sophisticated software development. Much of what many researchers want from version control could be had from RCS. Some will continue on and get involved in more complicated software and software projects, but is that the majority? What population are we targeting with SWC, what do they do, and how can we help them, incrementally, get better at what they do? Are those the questions we're trying to answer? I hope that was all germane, sorry for the length. -- bennet On Tue, Mar 1, 2016 at 8:23 AM, Greg Wilson <[email protected]> wrote: > Re-reading Arjun Raj's post > (http://rajlaboratory.blogspot.ca/2016/02/from-reproducibility-to-over.html), > I've got a couple of thoughts. First, I think some of the disparaging > comments on Twitter and elsewhere were unhelpful: they're unlikely to get > the author to change his mind, and it discourages other people from talking > about what they do. > > Second, we all make the same decision he does most of the time. For > example, people tell me I'd be more productive if I used Haskell instead of > Python, or the Atom editor, or Slack, or blah blah blah. In almost every > case, I compare the time I have to make the change, the time it'll take for > the change to pay off, and the likelihood of the technology's fans being > right about the benefits, and decide "nope" - and I'm willing to bet you do > too. I'm probably wrong in some cases, but with so many new things flying > around, I can't be certain which ones, and hey, deadlines... > > So here are my questions: > > 1. What's LD50 [1] for version control, i.e., how long would people have to > use it (or watch someone else use) for half of them to be convinced it's > worth adopting? I think LD50 for the Unix shell is less than an hour, > because that's how long it takes us to introduce pipes and loops, which most > workshop participants find compelling. At what point do at least half of > workshop participants find Git compelling enough to actually adopt it? > > 2. What should we say to someone like Arjun? It's clear from his post that > he knows the arguments in favor of version control, and has actually tried > it. It's also clear that he cares about doing things well - what can we do > to convince someone like that? > > Thanks, > Greg > > [1] https://simple.wikipedia.org/wiki/LD50 > > -- > Dr Greg Wilson > Director of Instructor Training > Software Carpentry Foundation > > > _______________________________________________ > 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
