Minutes from 2012-10-29 All-Hands Meeting

This post originally appeared on the Software Carpentry website.

We held our first online all-hands meeting yesterday (Monday, October 29), and despite Hurricane Sandy, 28 people were able to attend. Minutes from the meeting are given below; we have a lot to do, but we're very excited to be doing it.

In attendance:

Aron Ahmadia Carlos Anderson Azalee Bostroem Erik Bray Steve Crouch Matt Davis Ross Dickson

Justin Ely Julia Gustavsen Tommy Guy Steve Haddock Ted Hart Konrad Hinsen Katy Huff

Emily Jane McTavish Trevor King Justin Kitzes Ian Langmore Ian Mitchell Aleksandra Pawlik Ariel Rokem

Anthony Scopatz Chang She Joshua Smith Laura Tremblay-Boyer Ben Waugh Ethan White Greg Wilson

Minutes

1. Attendance and no-shows
   • Attendance ranges from less than 50% to over 100% of those who register
   • Former case is disappointing (to instructors) and unfair (to those left on the wait list)
   • Options:
     1. Have people to register in groups/teams
        • Worked well at UC London and elsewhere
        • Difficult to implement on EventBrite
        • Try out team signup at upcoming workshops
     2. Try a registration charge (e.g., $20) which we keep, return after attendance, or give to charity
        • Institutions may start charging us for space if any money changes hands
          • Find out if we can charge for attendance without being charged in turn
        • Returning money to attendees is difficult (getting credit card number and only charging for no-show is equally fraught)
        • What charity would we donate to? (Software Carpentry isn't a non-profit)
2. Licensing
   • Existing content is CC-BY / MIT licensed
   • Do not want to have to manage content with multiple licenses
   • Need sign-off from contributors
   • Linux Submitting Patches guide and GitHub's Contributing Guidelines are both examples we can copy.
   • Incorporate licensing agreement into web site
   • Get retroactive signoff for existing material
3. Workshop/participant level mismatch
   • Most common complaints about workshops are "too fast" and "too slow"
   • describes our target
   • Telling people what we expect as background hasn't worked
     • People who don't know enough to absorb what we teach show up in the hopes that they'll get something, and are then lost
     • People who know much of what we're teaching show up in the hopes of learning something new, and are bored
   • Having people send us material for evaluation (e.g., code sample) doesn't scale
     • "I think the people in my field able to produce a code example are way ahead of the group that needs the most help."
   • Use a self-assessment?
     • People will still undershoot/overshoot and show up anyway
     • Pre-tests scare away some of the people we most want to help
   • Ask them to work through a free online course before coming to us?
     • MOOCs work best for people who already understand concepts and want to add information...
     • ...which isn't our audience...
     • ...and many people who are willing to try a two-day workshop probably won't commit to a full course (up front)
   • Experiment with pre-assessments for upcoming workshops
     • Make completion of the pre-assessment a condition for getting a ticket
4. Impact Assessment
   • We don't know what impact we're having (but funders would really like to)
   • Collect names/email addresses of actual workshop participants to contact later
   • Design lightweight post-workshop instrument for use 3 months after
5. Migrating the Software Carpentry repository to GitHub
   • Find examples of people doing collaborative course development using Git
   • Need to reach consensus on one-big-repo vs. lots-of-little-repos
   • Produce short A-or-B position statements on Git organization by Nov 7 for vote
6. Online Lessons
   • Broadcast video tutorials didn't work well
   • Forums hosted at Software Carpentry didn't do well in 2010
   • SciComp Stack Exchange isn't intended for novice questions about shell, version control, etc.
   • Local learning groups (once-a-week lunchtime sessions) seemed to work well
     • And when video tutorials did work, it was partly because participants were co-located, e.g., watching a single screen in a small group and talking amongst themselves out of band
   • Experiment with online office hours
   • Create "Software Carpentry" tag on Stack Exchange
   • Re-launch our own forums
     • Given how many workshops we're running, and how closely they're scheduled, maybe this time there would be critical mass
7. Targeting Specific Audiences
   • Our mission is not to teach Python (or Bash, or Subversion), but to teach scientists how to think like programmers:
     • to grow programs in a structured, repeatable way (create and combine lots of little tools)
     • to manage and share what they build (version control, readable code, provenance)
     • to be confident that it's right (defensive programming, testing, debugging)
     • to automate, automate, automate (build system, and the very idea of programming)
     and to do this using open source tools as far as possible.
   • Using R instead of Python fits this mission (see Justin Kitzes' summary)
   • Teaching MPI doesn't
   • What about teaching these concepts in C or Fortran to people who already speak the language?
   • Try using R instead of Python
   • Try using C or Fortran without teaching the language itself
8. Workshop Sprint in 2013
   • Initial idea: bring Europeans over to help run a bunch of workshops in North American in late March 2013, then send North Americans over to help teach another bunch in late June
     • Good for publicity
     • A good way for people to meet each other and build ties
   • Are (some) people able to take 2-3 weeks to do this? Yes.
     • Particularly if they give academic talks at the same time as teaching workshops, which everyone should.
   • Does the timing work? Exams, people leaving to work at field stations, etc.
   • Find out who's available when for workshop sprint
   • Find budget for workshop sprint
9. Content Sprint in 2013
   • Independently of the workshop sprint, bring people together for a one-week sprint on content
     • Or possibly 2-3 sites (e.g., London, Toronto, Mountain View) connected by virtual presence
   • Find out who's available when for content sprint
   • Find budget for content sprint
10. Deferred
    • IPython Notebooks experience report
    • Git experience report
    • What to do about Windows?
    • Badging

Actions

1. Try out team signup at upcoming workshops. [pending new workshops]
2. Find out if we can charge for attendance without being charged in turn. [all]
3. Incorporate licensing agreement into web site. [GVW]
4. Get retroactive signoff for existing material. [GVW]
5. Experiment with pre-assessments for upcoming workshops. [pending design and new workshops]
6. Collect names/email addresses of actual workshop participants to contact later. [all]
7. Design lightweight post-workshop instrument for use 3 months after. [WC, MH]
8. Find examples of people doing collaborative course development using Git. [any?]
9. Produce short A-or-B position statements on Git organization by Nov 7 for vote. [KH + AA, MD, TG, TK, CS, JS]
10. Experiment with online office hours. [KH, others?]
11. Create "Software Carpentry" tag on Stack Exchange. [volunteer?]
12. Re-launch our own forums. [deferred]
13. Try using R instead of Python. [TH, JK, LTB]
14. Try using C or Fortran without teaching the language itself. [AA, KH]
15. Find out who's available when for workshop sprint. [GVW]
16. Find budget for workshop sprint. [GVW]
17. Find out who's available when for content sprint. [GVW]
18. Find budget for content sprint. [GVW]

Note: GVW would really appreciate a volunteer to tackle #15-18.

AA	Aron Ahmadia
WC	Warren Code
MD	Matt Davis
TG	Tommy Guy
MH	Mike Hansen
TH	Ted Hart
KH	Konrad Hinsen
KH	Katy Huff
JK	Justin Kitzes
TK	Trevor King
CS	Chang She
JS	Joshua Smith
LTB	Laura Tremblay-Boyer
GVW	Greg Wilson