DATA 510: Data Science Capstone
June 8, 2026
You will be able to:
deliverables/ tree..qmd with YAML, R chunks, figures, and citations; understand render commands for HTML and PDF (hands-on in the Git session).Week 2 covered what good capstone research prose argues. Today covers how you publish it. Your write-up rough draft (M4, week 12) and final write-up (M5) must read like online publication, not a pasted notebook dump.
In the MSDS program you have written R Markdown (.Rmd):
{r} chunksQuarto (.qmd) is the modern publishing engine built on that same habit. If you can read an .Rmd, you are one short migration away from a capstone write-up toolchain.
Rather than maintaining four separate documents, you should maintain one Quarto source and render the formats you need for me, peer POs, and employers.
Like a Jupyter notebook, a Quarto document can run code at render time and embed outputs:
Unlike Jupyter alone, Quarto is built for long-form technical writing with sections, cross-references, bibliographies, and multi-format export. That is exactly what a capstone write-up needs.
Your write-up rough draft must be:
Quarto gives you HTML for the web and PDF for Canvas from the same source. Your peer POs can open HTML without guessing which notebook cell mattered.
Everything at courses.lpcordova.phd/data510 is built with Quarto:
.qmd_quarto.ymlIf the toolchain works for an entire course site, it works for your one capstone report.
Quarto also runs Python, Julia, and other engines. Tonight we focus on R because that is what this cohort uses daily. The document structure is the same if you add a {python} chunk later.
The proposal is a planning document. The write-up is the permanent record of what you actually did and found.
Your M1 PDF already has prose you can migrate:
| Proposal section | Write-up section |
|---|---|
| Problem framing and RQs | Introduction |
| Impact and stakeholders | Introduction / Impact |
| Data sources and engineering | Data and data engineering |
| Ethics and risks | Ethics and responsible use |
| Planned analysis | Methods and evaluation |
| (new after you run code) | Results and visualizations |
| Timeline risks | Discussion and limitations |
Add a short “Changes since M1” paragraph if your methods or data shifted. Honesty beats silent rewrites.
deliverables/
M1-proposal/ # you submitted PDF here
M2-data-summary/
M3-poster-draft/
M4-writeup-draft/ # writeup.qmd lives here (start now)
M5-final/
notebooks/ # exploration and heavy analysis
src/ # scripts imported or summarized in the write-up
Rule of thumb: notebooks hold the messy work; the write-up summarizes and cites the final pipeline. Peer POs should not need to run twelve notebooks to grade your story.
| When | What to do in writeup.qmd |
|---|---|
| Week 5 (now) | Skeleton + paste proposal sections; stub Results |
| Week 7 (M2) | Data section matches stable panel; add QC figures |
| Week 10 (M3) | Pull key figures from poster into Results |
| Week 12 (M4) | Full draft; methods and findings freeze |
| Week 14 (M5) | Polish prose, citations, render final HTML + PDF |
Starting early means you are not writing twelve sections from a blank page in week 12. Fight me if you want, but the students who start now thank themselves in July.
Your draft must include the following sections:
The skeleton file in this lecture folder mirrors these headings.
Before each Iteration Review:
quarto render deliverables/M4-writeup-draft/writeup.qmdREADME.md summary| Path | Best for |
|---|---|
Command line (quarto) |
Reproducible renders, README instructions, CI-style habits |
| VS Code | Daily authoring, Quarto preview, R chunk run controls |
I prefer you author in VS Code (or Cursor, same extensions) and verify in Terminal before milestone submissions. Same file, two ways to catch path bugs.
.pkg and complete installationquarto check confirms R, knitr, and optional PDF tools. Fix anything it flags before week 12 panic.
If you are on Windows or Linux for this course, use the matching installer from the same Quarto installation page. Tonight’s lab machines are macOS-first.
Canvas milestones often want PDF. On macOS:
Then re-run quarto check. First PDF render downloads LaTeX packages; it is slow once, fast after.
You likely already use VS Code (or Cursor) for Python and git. Add Quarto on top:
Extensions: Install Extensions):
.qmd file (e.g. deliverables/M4-writeup-draft/writeup.qmd)Quarto: Render (or click Render in the editor toolbar when the Quarto extension recognizes the file)quarto render path/to/writeup.qmdPreview: Command Palette Quarto: Preview (live HTML reload), same engine as quarto preview in Terminal.
Docs: Quarto VS Code extension
For {r} chunks to execute at render time you need R on PATH and packages knitr / rmarkdown:
In VS Code, the R extension can run individual lines or chunks for debugging; milestone submission should still come from a full quarto render so output matches what graders see.
On your machine, right now:
If your neighbor fails, compare quarto check output. Nine times out of ten it is a missing package, missing extension, or wrong working directory.
The DS3 template .gitignore already ignores .quarto/ cache.
Commit: .qmd source, rendered PDF/HTML for milestones, figures referenced in the doc.
Do not commit: .quarto/ scratch, huge raw data, secrets.
Every capstone write-up follows this shape (one .qmd file):
---
title: "Your Project Title"
format:
html: default
pdf: default
---
# Introduction
Prose here.
# R chunk here (summary(cars))
Three layers: YAML metadata, Markdown prose, executable chunks.
| Key | Purpose |
|---|---|
title, subtitle, author |
Cover metadata |
format: html / pdf |
Output targets (list both for capstone) |
number-sections: true |
Numbered headings in PDF |
toc: true |
Table of contents in HTML/PDF |
bibliography: refs.bib |
Citation database |
execute: |
Global chunk defaults (echo, warning, message) |
R Markdown users: .Rmd used output: html_document. Quarto uses format: html. That is the main YAML migration pain point.
```{r}
#| label: fig-scatter
#| fig-cap: "MPG vs weight"
#| echo: true
#| warning: false
#| fig-width: 6
#| fig-height: 4
plot(mtcars$wt, mtcars$mpg)
```
Chunk options (capstone essentials):
echo: true shows code (methods transparency)echo: false hides boilerplate importsfig-cap + label: enables @fig-scatter cross-refscache: true only for expensive stable chunks (not while debugging)In prose: use cross-ref syntax with your figure label (example: @fig-scatter).
Tables get #| label: tbl-summary and a caption option similarly.
Cross-refs are how you write like a report, not like a folder of images named final_v3_REALLY_final.png.
refs.bib in the same folder as writeup.qmdbibliography: refs.bib@liu2016 or @liu2016 [p. 352]# References or use reference-section-title)For parallel editing, split sections:
{{< include _sections/methods.qmd >}}
Each teammate owns a file; one person integrates renders. Optional for teams of three; solo students can ignore this.
From your repo root (paths adjusted):
VS Code: Command Palette Quarto: Render on the open .qmd = quarto render on that file. Use the integrated terminal when you want the exact command for your README.
If chunks cannot find data/processed/panel.csv:
here::here("data/processed/panel.csv")README.mdWrong wd is the number one “it works on my laptop” capstone bug.
Copy from this lecture:
Into your repo:
deliverables/M4-writeup-draft/writeup.qmd
Paste proposal prose into the marked sections. Leave Results as stubs until M2/M3.
We do not render the skeleton in Block 1. Many of you have not cloned your DS3 repo yet, and rendering belongs with Git commit and push.
In Block 2 I will walk through:
deliverables/M4-writeup-draft/See the Git session slides for step-by-step commands.
Should you commit the rendered PDF/HTML for milestone submissions?
A. No, only `.qmd` source ever
B. Yes for graded milestones so that Lucas and peer POs open artifacts without rendering
C. Only commit PDF if you use Word
D. Only commit on the final week
B. DS3 convention: source plus rendered milestone artifacts in deliverables/. I click PDF; you still maintain .qmd as source of truth.
The syllabus expects a portfolio-quality artifact: employers should see your question, methods, and findings without joining our Canvas course.
Your final write-up becomes a permanent public record, linked from your project website and eventually your professional portfolio.
One project page tells the story; the Quarto write-up is the depth layer.
Later you will create a Quarto website (separate project):
That gives you index.qmd, _quarto.yml, and a projects/ folder for case studies. Your capstone write-up becomes one project entry with summary, hero figure, and links.
Render the site to _site/ or docs/, push to GitHub, enable Pages on that folder. Your write-up HTML becomes a public URL. Full walkthrough is the next technical writing / portfolio session.
notebooks/; summarize in the write-up as results matureBlock 2: Git session first, then data engineering consultations. Bring your GitHub repo URL (or be ready to create one from the DS3 template).
Follow-up lecture: building your portfolio site around this write-up (Quarto website, GitHub Pages, project landing page). Today you learned the engine; next time we ship the showcase.