Workshop

Docendo discimus.

Your task this semester: design and run a 60-minute workshop on a particular statistical model.

You will complete this task in (ideally) teams of two.¹

¹ If we have an odd number, I will likely want one team of three person rather than one person work alone, but we should discuss.

Why?

I designed this project to help you develop as a researcher and teacher.

1. As PhD students, you aren’t just learning statistical models so you can pass my exams. You’re preparing to explain them to others, whether in conference presentations, your job talk, or classroom lectures.
2. Teaching a concept deepens your own mastery. It forces you to develop a thorough understanding of an idea and constantly re-engage with your understanding.
3. The workshop also mirrors important professional activities: conference presentations and job talks, teaching, collaboration, and reproducible research. It’s easy to think of a polished presentation as “mere aesthetics,” but communication is important for scientists!

Topics

I suggest the following topics:

1. Modeling binary categorical outcomes.
2. Modeling unordered categorical outcomes.
3. Modeling ordered categorical outcomes.

Materials

Your workshop should consist of the following materials:

A Read-Ahead Document

A document (HTML or PDF) that participants can read and code they can run in 5-10 minutes before attending the workshop.

This document serves two purposes.

1. First, it orients participants to the material and sparks interest and curiosity.
2. Second, it describes how to install any software needed for the workshop so that folks can set up their computers before attending. You should give instructions for installing the software and code they can use to test the installation (i.e., “make sure the following code runs and produces _____”.)

You should write a script and ask them to run it so that it sets up their computer with everything they need. For example, if you want to use {crdata}, then you need to have them run:

install.packages("devtools")
devtools::install_github("carlislerainey/crdata")

Be aware that some students might use RStudio via Posit Cloud rather than locally.

This document is not a substitute for the workshop. It is lightweight document that reduces friction and builds interest.

Slides

A set of slides to show during the presentation.

The slides should support a roughly 15-minute conceptual lecture portion of the workshop.

The slides do not need to be comprehensive.² Perhaps 6-8 slides are enough. Use slides to emphasize the big ideas concepts or show visuals.³ (It’s fine to use an analog or digital chalkboard for portions of the lecture!)

² The take-home notes can include the supporting details.

³ Again, reserve complicated equations for handouts.

Two Examples

Two diverse examples from political science.

1. Use the first example as a live-coding example for your workshop. Introduce all the code for the second example here.
2. Use the second example as a hands-on exercise for your participants. Participants should be able to adapt the code from the first example here.

Given that you only have a few minutes, these examples need to be simple.

The bit below seems about right for the Cox model, for example. Regardless, it cannot be 300 lines of R code or 10+ commands. Fit, EV, and FD seems about right.

I want to replace this Cox PH model with a logit model.

# load packages
library(tidyverse)
library(survival)
library(marginaleffects)

# load data
cancer <- survival::cancer |> 
  glimpse()

Rows: 228
Columns: 10
$ inst      <dbl> 3, 3, 3, 5, 1, 12, 7, 11, 1, 7, 6, 16, 11, 21, 12, 1, 22, 16…
$ time      <dbl> 306, 455, 1010, 210, 883, 1022, 310, 361, 218, 166, 170, 654…
$ status    <dbl> 2, 2, 1, 2, 2, 1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, …
$ age       <dbl> 74, 68, 56, 57, 60, 74, 68, 71, 53, 61, 57, 68, 68, 60, 57, …
$ sex       <dbl> 1, 1, 1, 1, 1, 1, 2, 2, 1, 1, 1, 2, 2, 1, 1, 1, 1, 1, 2, 1, …
$ ph.ecog   <dbl> 1, 0, 0, 1, 0, 1, 2, 2, 1, 2, 1, 2, 1, NA, 1, 1, 1, 2, 2, 1,…
$ ph.karno  <dbl> 90, 90, 90, 90, 100, 50, 70, 60, 70, 70, 80, 70, 90, 60, 80,…
$ pat.karno <dbl> 100, 90, 90, 60, 90, 80, 60, 80, 80, 70, 80, 70, 90, 70, 70,…
$ meal.cal  <dbl> 1175, 1225, NA, 1150, NA, 513, 384, 538, 825, 271, 1025, NA,…
$ wt.loss   <dbl> NA, 15, 15, 11, 0, 0, 10, 1, 16, 34, 27, 23, 5, 32, 60, 15, …

# fit cox model
f <- Surv(time, status) ~ age + sex + pat.karno
fit <- coxph(f, data = cancer)
summary(fit)

Call:
coxph(formula = f, data = cancer)

  n= 225, number of events= 162 
   (3 observations deleted due to missingness)

               coef exp(coef)  se(coef)      z Pr(>|z|)    
age        0.011793  1.011863  0.009331  1.264 0.206269    
sex       -0.519262  0.594959  0.168967 -3.073 0.002118 ** 
pat.karno -0.019061  0.981120  0.005638 -3.381 0.000722 ***
---
Signif. codes:  0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1

          exp(coef) exp(-coef) lower .95 upper .95
age          1.0119     0.9883    0.9935    1.0305
sex          0.5950     1.6808    0.4272    0.8285
pat.karno    0.9811     1.0192    0.9703    0.9920

Concordance= 0.639  (se = 0.025 )
Likelihood ratio test= 24.33  on 3 df,   p=2e-05
Wald test            = 23.72  on 3 df,   p=3e-05
Score (logrank) test = 24.23  on 3 df,   p=2e-05

# generate predictions
p <- predictions(
  fit, 
  variables = list(time = unique, pat.karno = c(50, 100)), 
  newdata = datagrid(grid_type = "mean_or_mode"),
  type = "survival"  # <---- this is important!
  )
ggplot(p, aes(x = time, 
              y = estimate, 
              ymax = conf.high, 
              ymin = conf.low)) +
  geom_ribbon(fill = "grey80") + 
  geom_line() + 
  facet_wrap(vars(pat.karno))

# generate comparisons
c <- comparisons(
  fit,
  variables = list(pat.karno = c(50, 100)), 
  newdata = datagrid(time = unique),
  type = "survival"
  )
ggplot(c, aes(x = time, 
              y = estimate, 
              ymax = conf.high, 
              ymin = conf.low)) +
  geom_ribbon(fill = "grey80") + 
  geom_line()

A Take-Home Handout

Take-home handout that summarizes all the content from the workshop. This document is a substitute for the workshop. You can easily write a reproducible document in Quarto.

1. It should cover the conceptual and mathematical ideas from the lecture, but in somewhat greater detail. Something like two pages of text seems about right, excluding large equations, figures, and tables.
2. It should include the two examples worked out in detail. In Quarto, it’s easy to mix the prose, code, equations, and figures, so use those features to clearly explain the concepts and software. Make sure to focus on the important points—it’s easy to make pages and pages of relatively unimportant code and output. The length of this section will depend heavily on the nature of the examples, but each example should load and inspect data, fit models, compute quantities of interest, and plot the quantities of interest.
3. It should include a few references in case participants want to learn more. For each references, write a few words about why participants might use that resource.

Time and Place

I want to students to take the lead on choosing the exact time and place for the workshop and a rehearsal, reserving the space, and recruiting participants (e.g., first-year PhD students, other PhD students, RIBC students, students from other departments, etc.). We want about 10 participants of similar background.

Suggested Workshop Structure

1. 5 min: Opening. Introduce good example. Give the audience a question.
2. 15 min: Lecture. Discuss any important conceptual ideas.
3. 15 min: Example 1. Cover a numerical example in detail. Discuss concepts, R code, and substantive conclusions. Recommend live coding. Remember to do relatively little here, but do it thoroughly. Fit a model, do one predictions(), and do one comparisons(). That’s five minutes per tasks, which seems about right if you explain things slowly and carefully.
4. 20 min: Example 2. Allow the audience to work through an example on their own. You’ll need to keep this example minimal, simple, and brief so that participants can ask questions, troubleshoot, and still finish. Perhaps supply starter or skeleton code. This example should be adaptable from Example 1.
5. 5 min. Wrap. Revisit and reemphasize the big ideas.

Scaffolding, Due Dates, and Weights

• Oct. 21: Initial outline (10%). Sketch out the take-home handout. Have 2-3 ideas for examples. Summarize the material you plan to include (and, implicitly, exclude). Graded as pass/fall.
• Oct. 28: Submit drafts of all materials (25%). Read-ahead document, slides, and take-home handout. Graded using rubric below (where applicable).
• Nov. 04: Rehearsal (15%). Before class on Nov. 5, arrange for a rehearsal of your workshop. I suggest recruiting some or all of your classmates. Graded as pass/fail.
• Nov. 25: Workshop (50%). Give your workshop before Thanksgiving break, ideally between Nov. 05 and Nov. 19. Graded using rubric below.

Workshop Rubric

The rubric below characterizes an excellent (100% credit), acceptable (80%), and poor (60%) workshop.

Dimension	Excellent	Acceptable	Poor
Conceptual Clarity	Accurately explains the model, including key details, intuition, and interpretation. Accessible but rigorous. Audience leaves knowing when and why to use the method.	Mostly correct explanation with minor gaps or over-reliance on technical detail. Audience may grasp mechanics but not the “why.”	Explanation is confused, incomplete, or incorrect. Audience unclear on what the model is or when to use it.
Examples (Live Coding & Hands-On)	Two well-chosen, diverse political science examples. Live coding is clear and reproducible and links model, code, and conclusions. Hands-on exercise is achievable in ~15–20 minutes with starter code/data.	Relevant but uneven examples (one strong, one weak; too complex; or loosely tied to political science). Coding works but may be hard to follow. Hands-on exercise somewhat too hard or easy.	Poorly chosen, irrelevant, or not reproducible. Coding fails or confuses. Hands-on exercise missing or unusable.
Materials (Read-Ahead, Slides, Handout)	Read-ahead is short, engaging, and practical. Slides emphasize big ideas and visuals. Handout is reproducible, integrates text/code/figures/references, and works as a standalone resource.	Materials are present but uneven (too long read-ahead, overly dense slides, incomplete or cluttered handout). Some reproducibility issues.	Materials missing, incoherent, or cannot be followed independently.
Delivery	Workshop stays on time and follows structure. Delivery is confident, clear, and interactive. Live coding is smooth with backup plan. Audience is engaged and participates.	Delivery understandable but uneven (rushed, monotone, or overly technical). Some interaction but limited engagement. Minor coding/timing issues.	Workshop disorganized, unclear, or off schedule. Little to no interaction. Technical failures derail session.
Professionalism	Teamwork is balanced. Materials are polished and proofed. Overall presentation mirrors professional standards (conference/job talk quality).	Teamwork uneven or materials lack polish (typos, sloppy figures, unclear code). Still functional overall.	One person carries the work or team uncoordinated. Materials unprofessional, incomplete, or sloppy.

Comments on Tools

• You may use whatever software helps you design and run an excellent workshop.
• I highly recommend Quarto rendered to HTML or PDF for your take-home handout.
• It’s easier to make excellent slides with a WYSIWYG program like PowerPoint, but harder to update and maintain those slides. Software like Revealjs make it really easy to convert a take-home handout written in Quarto to an easy to create and maintain set of slides.
• You can post materials to the web (HTML or PDF) or share materials (data, scripts, and documents) in a zipped directory via email.

Be aware that some RIBC students might use RStudio via Posit Cloud rather than locally.

Resources

• Tufte’s “The Cognitive Style of PowerPoint.” [pdf]
• Asher’s Even a Geek Can Speak [Amazon] and 15 Minutes Including Q&A [Amazon]