Reorganizing
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:
A. | During the week of Nov. 4-9,
I'll merge the snippets in the _includes directory
into the lessons directory
and move image files into more rational places. |
B. | The repo will have a directory for each topic (shell, Git, etc.).
Each will contain sub-directories called novice (for absolute beginners)
and intermediate (for people with some previous experience).
The lessons for each topic will be independent
because running intermediates through novice material at triple speed doesn't work well. |
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.
See also:
- Find and/or build tools to help manage lesson material.
- What structure and metadata should lessons have?
- Unix Shell: novice and intermediate
- Git: novice and intermediate
- Python: novice and intermediate
- R: novice and intermediate
- SQL: novice and intermediate