- What exactly would I be leading? A project? Many projects?
- What is the commitment to leading a domain of inquiry?
- What is the overall structure of the 2 quarter sequence?
- How do I know my "domain of inquiry" is appropriate for students?
- How do students decide on a domain?
- How do students decide on projects?
- How much leeway do students have in choosing a project?
- What is the weekly structure in the course?
- How much course preparation is required for hosting a domain?
- What do students turn in throughout the sequence?
- How much time can I expect to spend grading?
Domain experts host "domains of inquiry" that can support multiple projects clustered around a specific domain. The scale of the Capstone Sequence (200 - 250 students/year) necessitates opening mentorship mutiple teams of 2-4 students. However, the structure of the Capstone Sequence encourages group discussion and teams within a domain to loosely work together, reducing the number of 1-on-1 meetings. The size of your domain may vary (from 1-5 teams), but stucturing the Capstone Sequence in this way ensures:
- there are adequate guard-rails for students new to independent work,
- students have material to follow and learn from when developing their own work,
- the scope of projects remain manageable for the time frame and appropriate for the level of the students.
The Capstone Sequence is a two quarter commitment.
- One hour per week is spent in discussion sections answering questions students have on the weekly readings and tasks.
- Approximately one hour per week holding Office Hours (either drop in, or by appointment).
- Quarter 1 consists of a "result replication" to acquaint students with the domain and take students through a dry run of putting together a larger project in code. They also form their project groups and write/present their project proposal.
- In Quarter 2, students execute on their project.
Choosing a known, doable, result for students to replicate ensures that it's scoped narrowly enough for students to succeed, while being broad/relevant enough to support investigations from numerous groups. The project template is meant to ensure this balance is achieved.
Domains are advertised ahead of the first quarter and students enroll in their preferred domain. During the first week, students may also change domains.
After 6 weeks of learning their domain individually, students form groups (or are placed into groups) and write project proposals in their domain area, with the guidance of their domain expert. Groups then work on these projects in Quarter 2.
- Ideally, students formulate their own project closely related to the result-replication in Quarter 1. Formulating questions is a valuable skill, while hewing close to the result-replication will allow students to reuse their code.
- However, you may approve any project you are comfortable advising as a domain expert. However, other students in the domain will be required to follow along and peer review their classmates, so a project too far afield may hinder those interactions.
- Fixing the project ahead of time and requiring students to work on a specific coordinated task in the area is ok. In fact, typically students want such guidance. You should make these expectations clear at the beginning of the course.
- Lecture (1 hour/week).
- Quarter 1: students learn methodological standards for a data science project (software development, reproducibility, environment independence).
- Quarter 2: students learn approaches to project/team management and effective (written, visual, oral) communication.
- Discussion (1 hour/week)
- Quarter 1: Guided self-learning of a domain through replication of a known result. Section consists largely of introducing the reading student's will do the following week and answering questions students may have about the reading.
- Quarter 2: Project teams report on their progress from the previous week as well as plans for the following week. The class helps teams solve issues they may be having ("weekly check-ins").
- Lab (2 hour/week)
- 1 hour/week of lab is "methodology" office hours (associated with the lecture).
- 1 hour/week of lab is "domain" office hours (help with the domain).
Not as much as it may seem; the sequence is designed to reduce the overhead required to scale mentorship across multiple groups. The following list the main class-prep tasks:
- Q1: Weekly plan (readings + tasks).
- Q1: Questions for topics each week.
See example weekly plans from this quarter (there are 5 domains lists; visit each page to see the plan for that domain).
Quarter 2 requires no course preparation, only student/group meetings with feedback.
Students work on many assignments to both keep them on-track as well as to structure regular instructor feedback for student work. These assignments are largely pre-made and consistent across domains (with content specific to each domain).
- Weekly questions / check-ins / peer reviews.
- Project checkpoints (for replication and project).
- Finished products (e.g. reports, code pipelines, presentation)
The sequence is structured to minimize grading, while still giving thorough, actionable feedback.
- Weekly assignments are meant to be delivered in person (e.g. a verbal update); this is where you give feedback. The corresponding written assignments are turned in only for completion.
- Grades are given with a coarse precision (letter grade A/B/C/F with no plus/minus), with feedback in writing or given in office hours. This both helps maintain consistent grades across wildly different domains, as well as eases the grading. The letter grade assignment is typically "obvious". However, it is very important that students receive actionable feedback from their assignments, as that is the very point of the checkpoint.
- Grading does not (need to) involve code. You should be able to generally assess the correctness of the code from the figures in the report. The methodological standards of the code are graded by the lecture staff. (You can grade code, however, if you so desire).