Might be useful to roughly order learners from novice -> expert.
Step 1: Concept Map
Nice diagram, but I'm not sure who it is for or where it would be used. My first reaction was "wow this is complicated", but after exploring it, it makes very good sense.
Step 2: Summative Assessment
I had to get Rasmus to explain the definitions of summative and formative assessments. My interpretation of his explanation is "summative assessments are the end goals for the course, and formative assessments are the steps that you need to get there".
Fixing mangled repositories is a great skill. Might be worth having a goal to rollback a repository back to a previous state.
Will the course cover configuring git? Setting up your email address is a useful thing.
Do you want to include a blame goal? That is, extend goal 2 to include finding out who made the changes.
I think that you can probably sneak some non-git advice into this course. Things like teaching good file naming strategies, and directory management (separate raw data from processed data, try to reuse directory names between projects), maybe some more general advice on project management or working with other people.
Step 3: Formative Assessments
Viewing differences
Do you need to distinguish between seeing which fils have changed (git status) and how they have changed (git diff)?
Saving changes
Possibly worth splitting this into adding all files (git add .) and adding files one at at time.
Course outline
Basic operations
Also "Basic concepts", hopefully.
No git status?
Setting up a new project
I think cloning ought to come in this chapter.
Collaborating
Branch-per-feature development
I think this belongs in the previous chapter, and I don't think it should be the only branch strategy you teach - it's overkill for single person projects. I guess its worth talking about several different strategies and when each is appropriate.
For 1 person projects, I think the easiest approach is "work on master unless you are doing something risky, in which case create a branch".
For small teams of data scientists, branch per feature sounds ideal.
Step 0: Learner Profiles
Who is Catalina? Head of a lab?
Might be useful to roughly order learners from novice -> expert.
Step 1: Concept Map
Nice diagram, but I'm not sure who it is for or where it would be used. My first reaction was "wow this is complicated", but after exploring it, it makes very good sense.
Step 2: Summative Assessment
I had to get Rasmus to explain the definitions of summative and formative assessments. My interpretation of his explanation is "summative assessments are the end goals for the course, and formative assessments are the steps that you need to get there".
Fixing mangled repositories is a great skill. Might be worth having a goal to rollback a repository back to a previous state.
Will the course cover configuring git? Setting up your email address is a useful thing.
Do you want to include a blame goal? That is, extend goal 2 to include finding out who made the changes.
I think that you can probably sneak some non-git advice into this course. Things like teaching good file naming strategies, and directory management (separate raw data from processed data, try to reuse directory names between projects), maybe some more general advice on project management or working with other people.
Step 3: Formative Assessments
Do you need to distinguish between seeing which fils have changed (
git status) and how they have changed (git diff)?Possibly worth splitting this into adding all files (
git add .) and adding files one at at time.Course outline
Basic operations
Also "Basic concepts", hopefully.
No
git status?Setting up a new project
I think cloning ought to come in this chapter.
Collaborating
I think this belongs in the previous chapter, and I don't think it should be the only branch strategy you teach - it's overkill for single person projects. I guess its worth talking about several different strategies and when each is appropriate.
For 1 person projects, I think the easiest approach is "work on master unless you are doing something risky, in which case create a branch".
For small teams of data scientists, branch per feature sounds ideal.
For bigger projects, I think it's worth explaining that software developers often have elaborate systems with many branches and complex naming schemes. I think it's nice to show you can do this, but you probably won't need to.
Advanced features
typo
Do
regionalandreportcontain any data sciency content? I think that the types of projects that are commonly dealt with areWould be nice to have an example of each.