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:
|
|
|
|
- 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:
- 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
- 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)
- Institutions may start charging us for space if any money changes hands
- Have people to register in groups/teams
- 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
- 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
- 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
- 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
- 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
- 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)
- 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
- Our mission is not to teach Python (or Bash, or Subversion), but to teach scientists how to think like programmers:
- 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
- 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
- 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
- Independently of the workshop sprint, bring people together for a one-week sprint on content
- Deferred
- IPython Notebooks experience report
- Git experience report
- What to do about Windows?
- Badging
- Try out team signup at upcoming workshops. [pending new workshops]
- Find out if we can charge for attendance without being charged in turn. [all]
- Incorporate licensing agreement into web site. [GVW]
- Get retroactive signoff for existing material. [GVW]
- Experiment with pre-assessments for upcoming workshops. [pending design and new workshops]
- Collect names/email addresses of actual workshop participants to contact later. [all]
- Design lightweight post-workshop instrument for use 3 months after. [WC, MH]
- Find examples of people doing collaborative course development using Git. [any?]
- Produce short A-or-B position statements on Git organization by Nov 7 for vote. [KH + AA, MD, TG, TK, CS, JS]
- Experiment with online office hours. [KH, others?]
- Create "Software Carpentry" tag on Stack Exchange. [volunteer?]
- Re-launch our own forums. [deferred]
- Try using R instead of Python. [TH, JK, LTB]
- Try using C or Fortran without teaching the language itself. [AA, KH]
- Find out who's available when for workshop sprint. [GVW]
- Find budget for workshop sprint. [GVW]
- Find out who's available when for content sprint. [GVW]
- Find budget for content sprint. [GVW]
| 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 |