Project 1 · The Pew Data Brief

Part 1 capstone · M01–M05 · Proposal due Fri Sep 25, 5 PM · Brief due Fri Oct 23, 5 PM · Presentations October 26–30

Working in a team of 2–3, you will conduct a focused, reproducible descriptive analysis of one Pew Research Center American Trends Panel (ATP) wave on a topic your group genuinely cares about.

You will choose a substantive question, procure the survey microdata yourselves, document how your key variables were measured, wrangle the raw file into an analysis-ready dataset, and use descriptive statistics and visualization to answer the question.

Your two final products are:

a polished Quarto HTML data brief that communicates the analysis; and
a shared GitHub repository that makes the project understandable and reproducible.

You will also give a presentation in a 30-minute slot — roughly 20 minutes presenting plus 10 minutes of discussion. In it you explain the question, walk us through the evidence, show one important analytic decision behind the scenes, and discuss what the data can and cannot establish. Rehearse to 20 minutes, not 30.

How it is graded: 100 points across six dimensions, set out in the Project Rubric. Please read it early in the process, not the week it is due — several dimensions reward habits and decisions you need to build in from the start.

Start here: download project-1-starter.zip. It contains your repository skeleton — folders, .gitignore, and every documentation template described on this page — so you begin with the structure already in place rather than building it. Project setup and reproducibility walks you through it.

What you’ll build

Here is the whole thing on one screen. Everything below this box is how to accomplish it.

Question	One focused descriptive question, answered with one ATP wave
The brief	800–1,200 words, rendered from `programs/p1_data_brief.qmd`
Measurement	The construct → measure → variable chain, plus one measurement limitation
Sample	Analytic-sample description with denominators and weighting status stated
Table 1	One `gtsummary` table, 4–7 characteristics
Figures	Two `ggplot2` figures; at least one is your team’s own analytic contribution
Limitations	One measurement limitation and one sampling/data limitation
Repository	`README.md`, `data-provenance.md`, `codebook.csv`, shared Git history, clean-clone test passed
Presentation	30-minute slot — about 20 minutes presenting, 10 for questions

Why this project

Modules 1–5 have given you the pieces of a professional descriptive-analysis workflow. This project asks you to put them together on data your team selected.

Module	What you will demonstrate	Where you learned it
M01 · Measurement	Trace an important construct from survey question to analytic variable and identify a measurement limitation.	M01 module
M02 · Tools	Work reproducibly with R, Quarto, `here()`, Git/GitHub, and a shared repository.	M02 module · M02 lab
M03 · Visualization	Build truthful, readable, communication-oriented figures with `ggplot2`.	M03 module · M03 lab
M04 · Wrangling	Select, filter, recode, group, summarize, and create justified derived variables.	M04 module · M04 lab
M05 · Description	Describe an analytic sample, track denominators and missingness, build a Table 1, and compare groups descriptively.	M05 module · M05 lab

Nothing in this project requires a new statistical method. The analysis tools are all from M01–M05, and if one feels unfamiliar, the column on the right is where to look first — especially the lab, since that is the version where you typed the code yourself.

What is new is putting them together more independently: procuring and preparing your own data, documenting the decisions you make along the way, and keeping a shared reproducible project in working order. Those are the skills this project adds.

Project 1 asks:

What do these data show?

The next part of the course will add the machinery for a different question:

What can we infer beyond the sample we observed?

The four weeks · what to do, and when

This is the whole project on one screen. Everything below this table explains how to do a row; come back here whenever you lose the thread.

Week	What you are doing	Due
1	Form the team, choose a wave, set up the repository, and fill in `documentation/project-plan.md` — the proposal template in your starter	Proposal — Fri Sep 25, 5 PM
2	Procure the `.sav`, document provenance, identify analytic variables, start the codebook, first wrangling pass	—
3	Analytic dataset stable; Table 1 and both figures drafted; interpretations written from the actual results	—
4	Polish the brief, finish the README, pass the clean-clone test, rehearse	Brief — Fri Oct 23, 5 PM
5	Presentations, October 26–30 — 30-minute slot per team	—

Do not postpone the data work until Week 3. Most project problems are much easier to solve when you discover them early.

Week 2 is the week teams find out what their data actually contain, and it is reliably the bumpiest. A variable turns out to be coded differently than the questionnaire implied, or the missing-value codes are not what you expected, or the subgroup you wanted has eighty people in it. Every version of that is normal, and every version is easier with two of us looking at it. That is the week to come to office hours — not the week before it is due.

The professional workflow both projects use

Both PSY 652 projects follow the same basic workflow. If you keep these seven habits in view, most of the logistics become much easier.

1 · Start with a clear question or target

Know what you are trying to learn before writing analysis code.

2 · Preserve the raw data

The original file goes in data/raw/ and stays exactly as it arrived.

Every change to the data happens in code — no hand edits, and nothing opened in Excel. If a value needs recoding, a missing-value code needs converting, a variable needs collapsing into groups, or a column needs renaming, that change is written as a line of R.

This one is worth explaining rather than simply asserting, because opening the file in a spreadsheet is genuinely the faster-feeling option in the moment. The trouble is that a hand edit exists only on the laptop where it happened. Your teammates re-download the file and get something different. The change leaves no trace of what it was or why you made it, so a reader — including you, three weeks later — cannot reconstruct it. And if you ever need to redo the analysis on a corrected file, every hand edit has to be remembered and repeated from scratch.

A line of R costs about the same effort and gives all of that back: everyone gets the identical dataset, the reasoning sits right there in the code, and re-running it is one click. So when you hit something that needs fixing, the answer is always a line of code — and if you are not sure how to write it, that is exactly the kind of question to bring to lab or office hours.

3 · Document provenance

A reader should be able to tell where the data came from, which version or wave you used, when you obtained it, and how to obtain it again.

4 · Document the analytic variables

Your documentation/codebook.csv explains every variable that enters the analysis and traces recoded or derived variables back to their raw source.

See the Analytic Codebook Guide.

5 · Make the analysis reproducible

Use project-relative paths with here(). Do not depend on files outside the project, manually created objects in the R Environment, or numbers copied from the Console.

6 · Use Git as a record of the work

Commit meaningful increments throughout the month. Pull before beginning work, push after a work session, and keep data and credentials out of Git.

7 · Test the project from a clean start

Before submitting, a teammate who was not the primary data-prep person should clone the repository into a new folder, follow the README, place the raw data where instructed, restart R, and render the main .qmd from beginning to end.

If that clean-clone render fails, the project needs more work before it is ready to submit.

The central rule · question first, claim second

Do not begin by deciding what you want the data to prove.

Your workflow is:

Choose a substantive topic and descriptive question.
Identify an ATP wave that can answer it.
Read the questionnaire, codebook, and methodology.
Procure the microdata.
Decide which variables and respondents your analysis requires.
Analyze the data.
Decide what conclusion the evidence actually supports.
Communicate that conclusion clearly.

What counts as a good Project 1 question?

Good descriptive questions sound like:

*How common is ___?*
How does ___ vary across age, education, party, gender, or another substantively meaningful group?
Among people who , how common is ?
What does the distribution of ___ look like?
*Which groups show the largest descriptive differences in ___?*

Questions requiring causal or inferential machinery are outside the scope of Project 1:

Does X cause Y?
Is X a statistically significant predictor of Y?
Is the difference statistically significant?

This project is about doing description well.

No uncertainty estimates are required — or wanted

Project 1 does not ask you to quantify sampling uncertainty. Do not report confidence intervals, margins of error, error bars, p-values, or significance tests. Those are the subject of Part 2 of the course, and Project 2 is where you will use them.

Note where that line falls. It is drawn around quantifying uncertainty, not around describing a population:

If you work unweighted, describe the respondents in your analytic sample.
If you use the appropriate survey weight, you may report weighted point estimates for the population that weight is designed to represent.

Either way, Part 1 asks you to report the result; later modules teach you how to say how precise it is.

Choose your ATP wave

You have procured an ATP wave before. The M05 lab walked you through registering with Pew, accepting the terms, downloading a .sav, and reading it with read_sav() — plus what Pew’s 99 codes mean and why zap_labels() matters before analysis. This is the same workflow on a wave you choose.

Your team may choose any American Trends Panel wave that:

contains a topic you genuinely want to understand,
has documentation you can read,
contains variables that can support one focused descriptive question,
and is feasible to analyze in roughly one month.

Finding your way in

The easiest way to find that wave is the Pew report library. The topic range is wide — politics, religion, technology and social media, work and family, race and ethnicity, science attitudes. Each report sits on a specific ATP wave, and that wave’s .sav is the file you procure. A report is a useful signpost to a wave; your brief is not a rebuild of that report.

Or search the datasets directly. Pew publishes a browsable American Trends Panel dataset index listing every wave with its field dates and topic. If you already know roughly what you want to study, this is often the faster route — you can scan waves by subject without working backwards from a report.

Read the documentation before you commit. By the end of this step you should be able to name the wave number and field dates, the primary survey question(s), one likely comparison, and the wave-specific weight.

Before proposing the wave

Your team should be able to identify:

the ATP wave number and field dates,
the Pew report or topic page that led you to it,
the primary survey question(s) you want to analyze,
one likely grouping variable or comparison,
and the wave-specific survey weight, even if you ultimately conduct the core project unweighted.

Week 1 proposal · scope the project before analysis

Due Friday, September 25 at 5 PM, at the end of the project’s first week.

Before you do much coding, pause and scope the project. The proposal is meant to keep your team focused early, while the project is still easy to redirect — and it lets us catch a wave that will not support the question before you have spent two weeks on it. Approval is a scope check, not an endorsement of a particular conclusion.

Where it goes. The proposal lives in your repository as documentation/project-plan.md, and it is submitted by pushing it. Your repository needs to exist and be shared with us by this deadline — but the data do not. Week 1 is for settling on a question, finding a wave that asked about it, and setting up the repository; downloading the .sav and documenting its provenance is Week 2 work.

So by 5 PM on September 25 we should be able to open your repository and find documentation/project-plan.md filled in, with both graders added as collaborators.

Your starter already contains the template. Open documentation/project-plan.md and fill in each section — the proposal is that file, kept in the repository and updated as the project develops. Its sections are:

Section	What to provide
Team	Names, and who is taking first responsibility for which section
Topic	The substantive issue your group wants to study
Research question	One focused descriptive research question
Intended reader	Who would benefit from understanding the result
ATP wave	Wave number + the associated Pew report or topic page
Focal variables	Raw Pew variable names, with short descriptions
Planned comparison	One subgroup, cross-tab, or second descriptive dimension
Survey weight	The wave-specific weight variable’s name, even if you plan to analyze unweighted
Measurement question we already have	One honest uncertainty about how the construct was measured
Feasibility	One sentence explaining why the project fits M01–M05

The template has one more section, Changes to this plan, which you leave empty for now. It is append-only: as the project develops and decisions change, you date each change and say why. A documented change is a sign of a thoughtful team.

Getting the file into R

Pew distributes ATP waves as SPSS .sav files. The haven package reads them while preserving variable labels — you did exactly this in the M05 lab with read_sav(). When a wave carries hundreds of columns, labelled’s look_for() is the fastest way to find the variables you actually want.

The .sav you download goes in data/raw/ and is never edited by hand. Once the file is in R and your code has made its recoding decisions, write the result to data/derived/analytic.rds — that is your analytic dataset, and it is what your codebook documents, not the raw multi-hundred-column download.

Your audience

Write the data brief for a specific reader who could reasonably care about the findings, such as:

behavioral-science researchers,
clinicians or service providers,
school or university administrators,
public-health professionals,
nonprofit staff,
policymakers,
or another clearly defined professional audience.

The audience should shape what you explain and foreground. It should never change what the data say — only how you help the reader understand it.

What the final data brief contains

Aim for approximately 800–1,200 words of prose, plus one table and two required figures. A third figure is optional.

The easiest way to keep the brief readable is to think of it as answering one question clearly, not as trying to show every interesting thing you found.

1 · The question

Open with:

the substantive question,
why it matters,
and who the intended reader is.

Keep this concise. This is a data brief, not a literature review.

2 · Measurement

This is the M01 move — construct, operationalization, and the gap between them — now applied to a survey item you chose rather than one we chose for you.

For the one or two constructs most important to the project, show the chain from meaning to data.

A compact table works well:

Construct	Pew operationalization	Raw ATP variable	Analytic representation
Trust in AI	Survey item asking…	`AI4_Wxxx`	Ordered factor with four levels

Then identify one measurement limitation that matters for interpretation.

Your full analytic-variable documentation belongs in documentation/codebook.csv; this smaller table keeps the construct → measure → variable reasoning visible in the report.

3 · Data and analytic sample

Briefly report:

ATP wave and field dates,
the target population of the survey,
starting sample size,
final analytic sample size,
exclusions or missing-data decisions that changed the denominator,
and whether the reported estimates are unweighted sample descriptions or survey-weighted population estimates.

Then answer:

Who does this analysis describe, and how far can the findings reasonably generalize?

4 · Table 1

You built one of these in the M05 lab, on Pew data, with tbl_summary(). Same tool, your variables. The M05 module covers labelling variables so the table reads in words rather than column names.

Create one compact Table 1 with gtsummary.

Include roughly 4–7 characteristics that help the reader understand the analytic sample. Do not include every variable simply because it is available. A smaller, more purposeful table is usually stronger than a crowded one.

Report the analytic sample overall. You saw stratified Table 1s in M05, so it is worth being explicit: stratify by your focal grouping variable only if that comparison is central to your question and the resulting table stays readable. by = is not secretly required.

5 · Figure 1 · headline descriptive result

Everything you need is in the M03 module and M03 lab: choosing a geometry that fits the variable types, titles that state a finding, and the truthfulness checks on axes and encodings.

Your first figure should provide the clearest descriptive answer to the primary question.

It must:

be built in R with ggplot2,
use a finding-oriented title,
have complete labels,
identify the ATP wave and weighting status in the caption,
and follow the M03 principles of truthful and functional visualization.

6 · Figure 2 · comparison or qualification

Your second figure should extend, qualify, or complicate the answer in Figure 1 — it stays on the same question rather than opening a new one. Useful forms include:

a subgroup comparison,
a cross-tabulation,
a distribution,
or another view that puts the headline result in context.

At least one figure must represent your team’s own analytic contribution rather than directly reproducing a figure or breakdown from the Pew report that led you to the wave.

7 · Optional Figure 3

Include a third figure only if it contributes genuinely different evidence.

8 · What the findings mean — and do not mean

Close by:

stating the main descriptive takeaway,
connecting the findings into one coherent story,
naming one measurement limitation,
naming one sampling/generalizability or data limitation,
and identifying one question the descriptive analysis raises but cannot answer.

Survey weights

You learned in M05 why a weighted population estimate and an unweighted respondent summary are different claims.

Pick one and apply it to the whole brief. Do not weight some numbers and not others — a reader comparing your Table 1 against your headline figure has no way to tell which is which, and the two would be describing different populations.

Two defensible briefs · choose one

Unweighted — describing your respondents. Every number describes the people in your analytic sample. tbl_summary() for Table 1, ordinary dplyr summaries for the figures, and prose that says “53% of respondents in this wave…” This is completely acceptable, and it is the path that requires nothing beyond M01–M05.

Weighted — estimating the population. Every number uses the wave-specific Pew weight. That means tbl_svysummary() for Table 1 — the survey-aware sibling of the function you already know — and weighted estimates behind the figures, with prose that says “an estimated 53% of U.S. adults…” The M05 lab’s Going further section works this through on a Pew wave, including the survey::svydesign() object both the table and the estimates share.

Say which one you chose in your Data and analytic sample section. One sentence.

What is not required

To keep the project feasible, you are not required to:

conduct hypothesis tests,
calculate p-values,
fit regression models,
build a psychometric scale from scratch,
reproduce every analysis in a Pew report,
or use advanced reproducibility infrastructure.

Your repository

Your team works in a shared GitHub repository, separate from your PSY652_project folder. Download project-1-starter.zip and you begin with the whole structure already built — folders, .gitignore, and the documentation templates.

Project setup and reproducibility is the walkthrough: what the structure is, how to make it a repository and publish it, what each documentation file is for, and how to run the clean-clone test. Work through its first section in Week 1.

Two things about it are worth understanding here, because they shape your analysis rather than just your folder. (The third — why raw and derived data live apart — gets its own section immediately below.)

Your codebook has two columns the course codebooks don’t. source and derivation trace each analytic variable back to the raw Pew variable it came from. The course datasets arrived already prepared, so their codebooks did not need them. Yours does the preparing, so nobody can reconstruct your recoding decisions from the data alone — those two columns are where that reasoning lives. See the Analytic Codebook Guide.

The clean-clone test is the real check. Before submitting, a teammate who was not the primary data-prep person clones the repository fresh, follows the README, and renders the report from a restarted R session. If that works, the project stands on its own rather than on one person’s laptop. If it does not, you have found something worth fixing while there is still time.

The data folders · raw stays raw

Why your project folder looks different from your course project

Your PSY652_project folder has a single flat data/ directory, and that was the right shape for it. Every dataset in there arrived already prepared — someone else downloaded the raw file, made the recoding decisions, and handed you nhanes.Rds ready to analyze. Your job in the labs was the analysis.

This project is the first time you do that preparation yourselves. You will download a raw survey file that nobody has cleaned for you, decide which respondents belong in the analysis, convert Pew’s missing-value codes, recode measures into analysis-ready form, possibly build new variables, and save the result as the analytic dataset every figure and table is then built from.

That one change is why two things look new:

data/raw/ and data/derived/ exist so the file you downloaded and the file you built can never be confused, and so the second can always be rebuilt from the first.
Your codebook adds source and derivation — the two columns the course codebooks don’t have. Nobody reading your project can reconstruct your recoding decisions from the data alone, because you made them. Those columns are where they live. (See the Analytic Codebook Guide, which explains the five-versus-seven-column difference.)

Both are the same idea: once you are the one transforming the data, the transformation itself becomes something you have to document.

`data/raw/`

Contains the file exactly as you downloaded it — the same bytes Pew sent you, at the end of the project as at the start.

In practice that means the raw file is never edited in a spreadsheet, never has values overwritten or columns renamed inside it, never has rows deleted by hand, and never has a “fixed” copy saved over it. If the raw data need changing, the change is written as R code in your .qmd, where it is visible, repeatable, and shared with your teammates.

Keeping the original untouched is also what makes the rest of the project recoverable: however tangled the wrangling gets, you can delete data/derived/ and rebuild it from a file you know is pristine.

`data/derived/`

The moves that get you here are the ones from the M04 module and M04 lab — select(), filter(), mutate(), case_when(), group_by(), summarize() — applied to a file nobody has cleaned for you.

Contains the analysis-ready dataset your code creates, for example:

data/derived/analytic.rds

The main .qmd should be able to rebuild this file from the raw data.

Both raw and derived data remain local unless the instructor explicitly tells you that redistribution is permitted.

`data/README.md`

This small tracked file explains what belongs in the local data folders and points the reader to documentation/data-provenance.md.

Getting help, and using AI

You are encouraged to get help. Ask a teammate, ask in lab, ask us, search, read Stack Overflow, use an assistant. None of that is discouraged, and pretending otherwise would just make people quiet about it.

There is one standard, and it is simple.

The rule · you must be able to explain and defend every line

If you cannot say what a line does, why it is there, and what would change if you removed it, it does not belong in your brief. That is the standard regardless of where the line came from — a classmate, a forum, a model, or your own head an hour ago.

This is not a rule about detection. We are not going to try to work out whether a line came from you or from a model. We are going to ask you about it — in the presentation, you walk us through a piece of your own code.

If you used an assistant, note briefly in your README.md what you used it for. That is a professional habit, not a confession.

Where an assistant genuinely helps

Used well, it is closer to a patient teaching assistant than a code vending machine. These uses make you better at R:

“Explain this error message to me.” You have read it, you are still stuck, and you want it in plain language.
“What does the .groups argument in summarize() actually do?” Looking up an argument is what practising analysts do all day.
“Here is the code I wrote. Is there a clearer way to express it?” You wrote it, it works, and you want to learn the idiom.
“Why might my percentages not sum to 100?” — as a source of hypotheses to check, not an answer to paste.

Where it substitutes for the learning

“Write the code that makes Table 1 from this data.” Now you have code you cannot defend.
Pasting an error into a chat before you have read it yourself.
Asking for the interpretation, the limitations, or the scope paragraph — those are the parts we are actually grading.
In-editor completion that writes whole pipelines before you have decided what the pipeline should do.

Project 2 tightens this. There, reconstructing an unfamiliar analysis is itself the skill being assessed, so you will be asked to attempt each step yourself before looking anywhere else. The standard here — understand and defend every line — is the foundation that one builds on.

The Quarto report is the analysis

Keep the core workflow in programs/p1_data_brief.qmd.

A recommended structure is:

# The question

# Measurement

# Data and analytic sample

# Table 1

# What we found

## Finding 1

## Finding 2

# What the findings mean

# Reproducibility information

The document should:

import the raw data,
perform the required wrangling,
create or save the analytic dataset,
produce the Table 1,
generate every figure,
and compute the numbers reported in the prose.

In other words, the report should not just describe the analysis — it should actually be the analysis.

Numbers that come from your analysis should generally be generated by R rather than manually copied from Console output. The mechanism is inline R — a backtick, the letter r, an expression, and a closing backtick — evaluated when the document renders and replaced by its value.

Compute the number in a chunk, give it a name, then call that name in your sentence:

```{r}
#| label: headline-numbers
pct_daily  <- atp |> summarise(p = mean(uses_daily)) |> pull(p) * 100
n_analytic <- nrow(atp)
```

Then in your prose, write:

Among the r n_analytic respondents in the analytic sample, r round(pct_daily, 1)% reported daily use.

That renders as “Among the 1,502 respondents in the analytic sample, 38.4% reported daily use.” Change the filter, re-render, and both numbers update themselves.

Why it matters more than it looks. A typed number is correct only until the next time you change the wrangling — and nothing warns you. Every mismatch between a report’s prose and its own tables started as someone typing a number that was true at the time. It is also the reason your reviewers can trust the brief: the sentence and the table are computed from the same object.

You have seen this, but this is the first time you write it. The M04 lab’s example prose is written this way — the numbers in that sample paragraph are inline R, not typed digits. What you did in M04 was write your own prose around the two cross-references; the inline values in the example came from objects the lab had already built behind the scenes, so copying that sentence into your own file would not have worked.

Here it is the real thing: you create the object, then you call it. The two-step pattern above — a chunk that computes and names the value, then a sentence that calls it — is the whole technique. Use inline R for every result derived from your data. Fixed contextual facts you are not computing — the wave number, the field dates, a scale’s range — can simply be typed.

End with a folded sessionInfo() chunk:

Code

sessionInfo()

R version 4.5.2 (2025-10-31)
Platform: aarch64-apple-darwin20
Running under: macOS Tahoe 26.6

Matrix products: default
BLAS:   /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib 
LAPACK: /Library/Frameworks/R.framework/Versions/4.5-arm64/Resources/lib/libRlapack.dylib;  LAPACK version 3.12.1

locale:
[1] C.UTF-8/C.UTF-8/C.UTF-8/C/C.UTF-8/C.UTF-8

time zone: America/Denver
tzcode source: internal

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

loaded via a namespace (and not attached):
 [1] htmlwidgets_1.6.4 compiler_4.5.2    here_1.0.2        fastmap_1.2.0    
 [5] rprojroot_2.1.1   cli_3.6.6         tools_4.5.2       htmltools_0.5.9  
 [9] otel_0.2.0        yaml_2.3.12       rmarkdown_2.30    knitr_1.51       
[13] jsonlite_2.0.0    xfun_0.56         digest_0.6.39     rlang_1.3.0      
[17] evaluate_1.0.5

This records the R and package versions used. It does not freeze the computing environment, and that is fine for this course.

The presentation · 30 minutes

Every team member must speak and be prepared to answer questions about the full project.

Format · remote, and the choice of medium is yours

Presentations are delivered remotely over Microsoft Teams, across the two class meetings of presentation week (October 26–30) — two teams on Monday, two on Wednesday. You will know your slot in advance. One person shares their screen; you decide how to hand off between speakers.

How you present the material is up to you. Slides are one option, not a requirement. A rendered Quarto report scrolled through deliberately, a live notebook, or a small set of figures shown full-screen can all work — often better than slides, since your figures already exist and re-making them as slide images only invites version drift.

Whatever you choose, two things matter more than the medium:

Everything is legible at screen-share resolution. Test it by sharing to a teammate first — axis labels and table text that read fine on your own monitor frequently do not survive Teams compression.
You can move to a specific figure on request. Questions will not arrive in your running order, so know how to jump to Figure 2 without scrolling past everything else.

Have one person hold a backup copy of whatever you are presenting, in case the presenter’s connection drops.

Part 1 · The question and data · about 4 minutes

What did you want to know?
Why did you choose this ATP wave?
How was the focal construct measured?
Who is in the analytic sample?

Part 2 · What you found · about 8 minutes

Walk the class through:

the most useful part of Table 1,
Figure 1,
Figure 2,
and the single main descriptive takeaway.

Do not narrate every number.

Part 3 · Behind the analysis · about 5 minutes

Put your code on screen and walk us through a piece of it — a wrangling step, the Table 1 build, one of the figures. Explain what it does and why you wrote it that way, and expect follow-up questions about your choices.

This is where the standard set out in Getting help, and using AI gets tested: you should be able to explain and defend every line in your report, whatever its source.

Then teach one transferable analytic decision:

a recode,
a denominator choice,
a missing-data decision,
why you chose one graph instead of another,
or how you found a breakdown Pew did not publish.

Show enough code or a before/after output for the class to understand the move.

Part 4 · Scope and limitations · about 3 minutes

What can the analysis establish?

What can it not establish because of measurement, sampling, missingness, or the descriptive design?

Part 5 · Questions and discussion · about 10 minutes

Ten minutes, and they are not a formality — this is where you get to show what your team understood, what you noticed, and how you handled the hard parts.

Everyone should expect to answer something. Questions come from the class first, then from us, and they will be aimed at whoever did the part being asked about. Reasonable things to be ready for: why did you exclude those cases? · what would change if you had kept them? · why that denominator? · why that grouping variable, and not another? · why unweighted? · what did you get wrong the first time?

That last one is worth preparing deliberately. “Here is what we got wrong and how we found it” is the most useful thing a team can give the rest of the class, and it is the answer that most convinces us you did the work.

What to submit

Your repository is the submission. There is no separate file to upload — we grade the GitHub repo directly, at the state it is in when the deadline passes.

Add both graders as collaborators before the deadline. On github.com, open your repository → Settings → Collaborators → Add people, and add KimberlyHenry (instructor) and alliekom (lab instructor). Type the usernames exactly rather than searching by name — GitHub’s search will happily offer you someone else entirely.

Do this early, not on the last day

Your repository is private, which is correct — but it also means that until the invitations are accepted, nobody but your team can see a thing. If you add the graders an hour before the deadline and something is wrong with the invitation, there is no submission to grade.

Add both of us now — KimberlyHenry (instructor) and alliekom (lab instructor) — and confirm in Settings → Collaborators that each appears. Adding us early costs nothing: we look at the repository after the deadline, not before.

Two consequences of grading the repo rather than a file, both in your favour once you know them:

The commit history is visible, and that is the point. It is the evidence that the work was shared. A single last-minute commit cannot demonstrate the ongoing, shared workflow this part of the project is designed to assess.
What is not committed does not exist. Anything sitting only on someone’s laptop — a figure, a fixed typo, the final render — is not part of what we see. Push before the deadline, then check the repository on github.com in a browser and confirm what you expect is actually there.

Data files excluded by your .gitignore are meant to be absent; that is the design, not an omission. data/README.md and documentation/data-provenance.md are what tell us how to obtain them.