Publishing Your Research: Quarto Books & GitHub Pages

You have collected data, cleaned it, visualized it, and tested a hypothesis. Now you assemble everything into your White Paper, published simultaneously as a PDF and a live website.

The White Paper is the graded deliverable. A Quarto Book is the format it takes: a collection of .qmd files that Quarto renders into a single, cohesive document. Two words, one artifact. When the syllabus says White Paper and this chapter says Quarto Book, they are describing the same thing from two angles: what you wrote, and how it is built.

What You’re Building

One command (quarto render) produces:

1. A PDF: print-ready, submitted to Blackboard
2. A website: hosted free on GitHub Pages, accessible to anyone with the link

This is real academic publishing. Graduate students, researchers, and data journalists use this exact workflow.

The structure is IMRaD

Your White Paper follows IMRaD: Introduction, Methods, Results, and Discussion, in that order, with a short abstract in front and references at the close. The structure is a contract with the reader, who knows where to look for the question, the procedure, the finding, and the meaning. Your syllabus rubric is organized by these same sections, so the file layout below maps one to one onto how the paper is graded.

Scaffolding the Project

Create the project with the course R package rather than assembling folders by hand:

library(v2v)
new_portfolio("~/Documents/mc451-whitepaper")

That gives you the White Paper skeleton, a journals/ directory for your weekly reading journal, a codebook/ directory, a data tree with data/raw/ already gitignored, and a _quarto.yml wired as a Quarto Book:

mc451-whitepaper/
├── _quarto.yml          ← Master configuration file
├── index.qmd            ← Abstract (write this LAST)
├── 01-introduction.qmd  ← Question, theory, research questions
├── 02-methods.qmd       ← Data provenance, sampling, variables, reliability
├── 03-results.qmd       ← R code + output (tables, charts, tests, effect sizes)
├── 04-discussion.qmd    ← Interpretation, limitations, conclusion
├── 05-reflection.qmd    ← What was hard, what was ambiguous, what you'd change
├── references.qmd       ← Auto-generated bibliography
├── references.bib       ← Your citations (from Zotero)
├── journals/            ← Weekly reading journal entries
├── codebook/            ← Draft and final codebooks
├── data/raw/            ← Source data (gitignored)
├── data/derived/        ← Cleaned, analysis-ready data
└── figures/             ← Exported plots

How the Files Map to Your Prior Work

Template File	What to Write	Where It Comes From
01-introduction.qmd	Question, theoretical lens, research questions	Project Prospectus + Topic Selection & RQs
02-methods.qmd	Data provenance, sampling strategy, variable definitions, reliability, wrangling steps	Codebook & Qual Memo + Sampling Plan & Pilot
03-results.qmd	Distributions, group comparisons, test statistics, effect sizes	Data Wrangling + Describing Data + Inferencing Data
04-discussion.qmd	Answer your RQs, connect to theory, state the limits	Your own analysis
05-reflection.qmd	What proved harder than expected, and what a second attempt would change	Your own experience of the term
index.qmd	Abstract summarizing all four IMRaD sections	Write this LAST
references.bib	BibTeX citations for all sources	Export from Zotero

ImportantYou Are Not Starting from Scratch

Every section draws from an assignment you have already completed. This is assembly and revision, not new writing. Your Introduction comes from your Prospectus. Your Methods come from your Codebook and Sampling Plan. Your Results come from your three R assignments.

Setup: Getting the Project Running

Step 1: Scaffold and Open

1. Run v2v::new_portfolio() as shown above.
2. In VS Code, choose File, Open Folder and select the new folder. The open folder is your working directory.

Step 2: Install Required Packages

In an R session inside VS Code’s terminal, run:

install.packages(c("tidyverse", "knitr", "kableExtra", "scales"))

Step 3: Place Your Data

Copy your cleaned .RDS file (from Chapter 4 and the Data Wrangling assignment) into data/derived/. The starter 03-results.qmd expects a file called coding_data_clean.RDS, so rename yours to match, or update the filename in the code.

Step 4: First Render

Open VS Code’s integrated terminal (Terminal, New Terminal) and type:

quarto render

Or press Ctrl/Cmd+Shift+K with any .qmd file open. Quarto will run all R code in 03-results.qmd, combine the chapters into a single document, and produce a PDF and HTML website in the docs/ folder.

If it works, you will see a docs/ folder appear with your rendered files. If it does not, check the error message; it will tell you exactly which line failed.

Writing Each Section

Introduction (01-introduction.qmd)

Structure:

1. Opening hook (2 to 3 sentences): why should anyone care about your topic? Start with a concrete example or a surprising fact.
2. Background (1 to 2 paragraphs): what do we already know? Cite your sources using @citationkey syntax (Quarto auto-generates the reference list).
3. Theory (1 paragraph): which communication theory frames your study, and how does it connect to your variables? The rubric asks for a lens that is doing work rather than decoration, so the theory has to set up something your study can actually deliver.
4. Research Questions (list): state both RQs exactly as you wrote them in your Topic Selection & RQs assignment.

Aim for roughly 500 to 700 words. That is guidance for pacing, not a graded threshold; the rubric scores whether the question is clear and the lens is load-bearing.

Your Introduction is scored on framing: the question has to be situated in the theoretical literature rather than gestured at. That means a structured literature review drawing on 15 or more sources, organized by argument rather than listed one study per paragraph. Expect this section to run substantially longer than the undergraduate version.

Source: pull from your Project Prospectus and Topic Selection assignments. Revise for flow, because these were separate assignments, so connecting them into a single narrative takes some editing.

Methods (02-methods.qmd)

The rubric standard is repeatability: enough detail that another researcher could run your study again and get your dataset.

Structure:

1. Data provenance (1 paragraph): what media content did you analyze, where did it come from, and over what time period?
2. Sampling strategy (1 paragraph): how did you select your sample? What was the population, and what was the final sample size?
3. Variables (1 to 2 paragraphs): define each variable, conceptually and operationally. This comes directly from your codebook.
4. Reliability (1 paragraph): report your pilot, the agreement statistic you computed, and any codebook changes it prompted.
5. Wrangling (1 paragraph): the steps between raw file and analysis-ready data.

Aim for roughly 400 to 600 words. Methods carries the single largest block of points in the rubric, so specificity pays here more than anywhere else in the paper.

Methods carries three transparency markers, and each is checked explicitly:

1. A data provenance statement: the source, the access method, and the collection window, stated so a reader can reconstruct the dataset.
2. An intercoder reliability report: the kappa value, the training protocol that produced it, and the threshold you applied before coding the full sample.
3. A pre-registration disclosure with its OSF URL, including anything you changed after registering and why.

A Methods section missing any of the three is incomplete regardless of how well the rest reads.

Source: pull from your Codebook and Sampling Plan & Pilot assignments.

Results (03-results.qmd)

Report what you found, plainly and without interpretation. Interpretation belongs in the Discussion, and moving it there is worth points in both sections.

The starter file includes pre-written R code with placeholder variable names. You need to:

1. Replace var1 and var2 with your actual variable names
2. Update the readRDS() call to point to your .RDS file
3. Add your reporting paragraphs between the code chunks

Component	What to Include	Source Assignment
Frequency table	knitr::kable() formatted table with counts and percentages	Describing Data
Bar chart	ggplot2 publication-ready chart, labelled and captioned	Describing Data
Test result	The test statistic with its degrees of freedom, its p-value, and its effect size, in APA format, plus the journalist translation	Inferencing Data

WarningThe Effect Size Is Not Optional

A test statistic and a p-value tell a reader whether you found something. Only the effect size tells them whether it matters. The rubric asks for it in Results and then asks, in Discussion, whether you characterized it accurately rather than inflating it. Reporting the p-value alone costs points twice.

Report the power statistics behind the design alongside your effect sizes: the power analysis you ran, the effect size it assumed, and the sample size it implied. If your realized sample differs from that target, say so here rather than in the limitations.

TipDon’t Reinvent the Wheel

The R code in your graded assignments is the foundation. Copy your working code from the Describing Data and Inferencing Data assignments into the starter file and adjust the variable names. The scaffold is a starting point, but your tested code is more reliable.

Discussion (04-discussion.qmd)

Structure:

1. Answer your RQs (1 paragraph each): directly address each research question with evidence from your results.
2. Connect to theory (1 paragraph): how do your findings relate to the theory you introduced?
3. Limitations (at least 3): be specific. “Small sample size” is generic. “The sample capped each channel at 1,000 messages, so the busiest channels are under-represented relative to their real chat volume” is specific and useful.
4. Conclusion (2 to 3 sentences): what is the takeaway, and what should future researchers investigate?

Aim for roughly 400 to 500 words.

Two additions. First, distinguish statistical significance from practical size explicitly: a significant result with a trivial effect is a finding about your sample size, not about the world, and saying so is worth points. Second, the limitations are graded as an explicit limitations analysis rather than a list: for each limitation, say what it threatens (internal validity, external validity, reliability) and how a future design would address it.

Reflection (05-reflection.qmd)

One specific paragraph naming what proved harder than expected, where a rule was ambiguous in practice, what the data could not answer, and what a second attempt would change.

NoteGraded on Candour, Not on Success

The reflection is scored on precision, not on whether the study went well. A researcher who can say exactly where their study is weak is a researcher who understands it. “Everything went smoothly” is the lowest-scoring answer available.

Abstract (index.qmd)

Write this last. The abstract summarizes all four IMRaD sections in one paragraph of about 150 words:

• What you studied (1 sentence)
• How you studied it (1 sentence)
• What you found (2 to 3 sentences)
• Why it matters (1 sentence)

Graduate submissions carry an executive summary in addition to the abstract. The abstract is written for a researcher deciding whether to read the paper; the executive summary is written for a client or editor deciding what to do about it. Lead with the finding and its practical consequence, not with the method.

Reproducibility: No Pasted Numbers

The rubric awards points for a document that renders from source with no pasted numbers. That means every figure in your prose comes from inline R rather than from typing what you saw in the console:

The mean message length was `r round(mean(dat$len), 1)` characters.

If you retype a number and later re-run the analysis on a corrected dataset, the prose silently goes stale and disagrees with the table beside it. Inline code cannot go stale. It is also the single easiest place in the paper to lose points, because a grader can spot it by changing one row of your data and re-rendering.

Publishing to GitHub Pages

Step 1: Create a GitHub Repository

1. Go to github.com and sign in
2. Click New Repository (the green button or the + icon)
3. Name it something descriptive (for example, mc451-whitepaper)
4. Set it to Public (GitHub Pages requires a public repo on free accounts)
5. Do NOT add a README, .gitignore, or license (the scaffold already has these)
6. Click Create Repository

Step 2: Push Your Project

In VS Code’s integrated terminal, run these commands (replace the URL with your repo’s URL):

git init
git add .
git commit -m "Initial white paper commit"
git branch -M main
git remote add origin https://github.com/YOUR-USERNAME/mc451-whitepaper.git
git push -u origin main

Step 3: Enable GitHub Pages

1. Go to your repository on GitHub
2. Click Settings (tab at the top)
3. Scroll down to Pages (in the left sidebar)
4. Under “Source,” select Deploy from a branch
5. Set Branch to main and Folder to /docs
6. Click Save

Step 4: Wait and Test

GitHub Pages takes 1 to 2 minutes to build. Your site will be available at:

https://YOUR-USERNAME.github.io/mc451-whitepaper/

Test it in an incognito or private window to make sure it works for someone who is not logged into your GitHub account. The rubric is explicit that a paper nobody can open scores nothing, and “it worked on my laptop” is the most common way to discover that too late.

WarningThe Most Common Last-Minute Problem

Broken GitHub Pages link. This usually happens because:

1. The docs/ folder was not pushed (run git add docs/ && git commit -m "add docs" && git push)
2. GitHub Pages source is set wrong (should be main branch, /docs folder)
3. You have not waited long enough (give it 2 minutes)

Test in incognito before submitting.

Submission Checklist

• All IMRaD sections plus the abstract and reflection are complete and in your own words
• Every reported number comes from inline R, with nothing retyped from the console
• Test results include the statistic, its degrees of freedom, the p-value, and the effect size
• references.bib contains all your citations (exported from Zotero) and renders in APA 7th edition
• quarto render produces both PDF and HTML without errors
• PDF and website are in the docs/ folder and display all sections
• GitHub repo is public and contains the docs/ folder
• GitHub Pages is enabled and the site loads in an incognito window
• PDF renamed to Lastname_WhitePaper.pdf and uploaded to Blackboard
• GitHub Pages URL pasted into Blackboard submission text

• Executive summary included alongside the abstract
• Literature review draws on 15 or more sources
• Methods carries all three transparency markers, including the OSF pre-registration URL
• Power statistics reported with the effect sizes
• Conference poster submitted (a separate requirement, shared with MC 500)

Try It Yourself

1. Scaffold the project with v2v::new_portfolio() and open the folder in VS Code.
2. Run quarto render without making any changes. Does it produce output in the docs/ folder?
3. Read each .qmd file and identify which of your prior assignments provides the content for each section.
4. Replace one placeholder in 03-results.qmd with a real variable name from your dataset. Re-render and check the output.
5. Convert one retyped number in your prose into inline R and re-render to confirm it still reads correctly.
6. Set up a GitHub repository, push, enable Pages, and verify the site loads in an incognito window.

TipConnection to Your Project

This is it: the final deliverable. Everything in this workbook feeds into it. Chapters 1 and 2 prepared your data. Chapters 3 through 6 taught you the R skills. This chapter assembles the White Paper. When you are done, you will have a live research website and a professional PDF, real artifacts for a graduate school application or a job application.