TL;DR: We're going to:
- split our lesson materials for absolute beginners and people with some previous experience;
- build some tools to manage those materials;
- update and clarify the guidelines for instructor training, Software Carpentry's scope, making contributions, and use of our name and logo; and
- use GitHub issues and blog posts to manage discussion of details rather than our mailing list.
It's been a busy couple of months, but also rewarding: we've welcomed two new batches of instructors, and more people have submitted lesson material in the last six weeks than in the preceding 18 months.
But it's clear we need to simplify and consolidate things:
- A lot of our material is too advanced for many scientists, which (a) isn't helpful and (b) doesn't fit Mozilla's focus on helping people take their first steps.
- My choice to break some lessons into small includable pieces has proven more confusing than helpful.
- There's a lot of redundancy in our material.
- We need a clearer guide for people who want to contribute and clearer metadata for the lessons themselves: what's covered, what level, prerequisites, etc.
- We need to explain where Software Carpentry stops and other things begin.
One reason for our current tangle is that we're not just teaching computing to scientists: we're also creating teaching materials using open source practices, which few people do. Even programmers who use version control daily don't have many sets of collaborative, code-reviewed lessons—certainly not using tools as young as the IPython Notebook.
That, rapid growth, the fact that most of us are scientists first and coders second, and the lack of a clear plan have muddled things. Here's how we'll clear it up:
During the week of Nov. 4-9,
I'll merge the snippets in the
The repo will have a directory for each topic (shell, Git, etc.).
Each will contain sub-directories called
|C.||I'll manage work on novice material for the next three months, and Ethan White will coordinate work on intermediate. We'll focus on instructor-led rather than self-study material (because it's what we need for bootcamps), and we'll decide whether to recycle existing material or write new stuff on a case-by-case basis.|
|D.||Matt Davis will coordinate discussion about what needs to be in each lesson: long-form vs. point-form vs. all-in-one, manifests and README's, etc.|
|E.||Aron Ahmadia will coordinate work on tooling for authors and instructors. A lot of our material is now in formats that version control doesn't handle well; we need to figure out how to manage them, how to slim down the starter repo for bootcamps, how to integrate lesson material into the main website, etc.|
|F.||We'll use GitHub issues to manage discussion about topics C-E so as not to flood our mailing lists.|
Finally, since I'm making lists, we're also going to:
|G.||Change the guidelines for instructor training so that participants must have taken part in a bootcamp, be planning to host one, or have taught coding previously.|
|H.||Write an explicit description of Software Carpentry's scope.|
|I.||Bring Software Carpentry's contribution guidelines into line with those of other Mozilla projects. (I'll post this and the scope descriptions separately; please discuss them there.)|
|J.||Clarify the rules on using our name and logo so that people must always get explicit permission before doing so. (Again, I'll blog, and please discuss in comments.)|
Our goal is to be ready for the rest of 2014—not least PyCon in April—by mid-January. We really want you to join the discussion, write stuff, review stuff, etc.—we have great momentum right now, and I hope that having a plan for the next couple of months will fuel that.
I look forward to seeing you in our next lab meeting at 11:00 am and 7:00 pm Eastern on Nov 14.