Talks included in the playlist, broken up into a few categories for easier browsing, are as follows:

Quarto Extensions & Advanced Features

Speakers	Title	Thumbnail
Carlos Scheidegger (Quarto Team)	What we’re doing to make Quarto fast(er)
Christophe Dervieux (Quarto Team)	Beyond the Basics: Expanding Quarto’s Capabilities
Garrick Aden-Buie	Theming Made Easy: Introducing brand.yml
Gordon Woodhull (Quarto Team)	Brand YML and Dark Mode in Quarto
JooYoung Seo	maidr: Empowering Accessible, Multimodal Data Science with Quarto

Workflow Automation & Reporting

Speakers	Title	Thumbnail
Becca Krouse	Instant Impact: Developing {docorator} to Simplify Document Production
John Paul Helveston	surveydown: A Markdown-Based Platform for Interactive Surveys
Keaton Wilson	Using Quarto to Improve Formatting and Automation

Teaching & Education

Speakers	Title	Thumbnail
Claus Wilke	Teaching data visualization with R entirely in Quarto
Mine Çetinkaya-Rundel (Quarto Team)	Leveraging LLMs for student feedback in introductory data science courses
Ted Laderas	Empowering Learners with WebR, Pyodide, and Quarto

Business, Collaboration & Publishing

Speakers	Title	Thumbnail
Andrew Heiss and Gabe Osterhout	Election Night Reporting Using R & Quarto
Bill Pikounis	Quarto for Business Collaboration and Technical Documentation in Word docx format
Timothy Keyes	Trust, but Verify: Lessons from Deploying LLMs

We hope you enjoyed this look back at the Quarto sessions from posit::conf(2025). Every year the community brings new ideas, new tools, and new ways of working — and we’d love to see your voice added to the mix. We hope to see you next year, and maybe even see you up on stage sharing your own work at posit::conf!

We think that the tidymodels philosophy can enhance modeling in Python, and we believe that learning more about modeling in Python will provide us with ideas on how to improve tidymodels. To clarify, we are not creating a tidymodels Python package; however, some of its APIs may be beneficial to Python users. Two examples are recipes and broom’s tidy and augment verbs.

There are numerous ways that individuals can contribute to improving the Python ecosystem. We have a lot of ideas, but we also want to know what our new hire believes is most important. A sample of potential projects that have been on our mind:

• Grid search for model tuning has a fairly bad reputation for being inefficient. However, space-filling designs (SFDs) are excellent tools for making small tuning grids that methodically cover the entire parameter space. Users would benefit from having an integrated tool that can create grids from their pipelines using optimal SFDs.

• There are occasions where we might decline to produce a prediction, perhaps due to our prediction data being extrapolations from the training set. Applicability Domain methods measure extrapolation and can help determine where the model’s predictions are likely to be poor. An API that can take a model object and the training set could generate a score that informs users when their predictions are hallucinated unlikely to be accurate.

• Python deserves an original (Python-only) implementation of the popular glmnet model . There are Python libraries that wrap the original Fortran code; however, this approach isn’t easily supported, nor is it able to facilitate the numerous extensions of this particular model (e.g., group-wise penalties , MCP penalties, etc). This would be a substantial and in-depth project.

We have about a dozen other project ideas.

Open-source developers at Posit often have a broader role than just writing and testing code. We are often the folks defining what is deemed important and prioritizing our work. Additionally, we frequently undertake tasks that are typically considered part of developer relations, such as reaching out to the community, creating additional technical content, speaking at conferences, and teaching workshops. If you are a driven and independent developer, you might be interested in this position. You’ll have a lot of agency here and in an environment that encourages quality. Our developers tend to feel a personal stake in our work and want it to be as good as it can be. We’re a completely remote team, flexible in terms of how and when we work, and we do a good job of minimizing administrative overhead for engineers.

To learn more about the position and to apply, visit the Careers page .

All materials from both workshops are available online. You can access the full workshop websites, source code, and exercises to learn at your own pace or adapt them for your own teaching; they are both released with a CC BY-SA 4.0 license.

Branded Websites, Presentations, Dashboards, and PDFs with Quarto

Workshop website Source Exercises

Led by Isabella Velásquez , Posit, PBC and Sara Altman , Posit, PBC.

Designed for data scientists, analysts, and content creators, this immersive session will teach you how to craft cohesive reports and presentations while refining your workflow with Quarto’s latest features.

You will learn how to create dynamic websites, professional PDF documents, engaging presentations, and interactive dashboards using Quarto. This workshop highlights Quarto’s powerful theming capabilities, including the new support for brand.yml, which ensures that your work maintains a professional and cohesive style across all formats.

By the end of the session, you’ll be equipped to:

• Build and deploy Quarto websites.
• Generate professional presentations and PDF reports.
• Create interactive dashboards for data visualization and reporting.
• Use brand.yml to define and apply consistent theming across all outputs.

Whether you’re looking to enhance your personal projects or streamline organizational outputs, this workshop will equip you with the tools to create polished, professional results.

Extending Quarto

Workshop website Source Exercises

Led by Mine Çetinkaya-Rundel , Posit, PBC + Duke University and Charlotte Wickham Posit, PBC.

In this workshop, we will dive deep into ways of customizing your Quarto outputs with tooling beyond built-in features. This workshop is designed for data scientists, analysts, and technical writers looking to extend Quarto’s capabilities to suit their unique workflows better.

Participants will learn how to create custom extensions, including new formats, templates, and filters, to enhance their document production process. Through hands-on exercises and real-world examples, you’ll gain practical skills in:

• Developing and integrating custom formats to support diverse outputs while reducing repetition across projects.
• Substituting Quarto’s templates with your own to customize formats beyond the built-in options.
• Implementing filters to automate and streamline content transformation.

By the end of the workshop, you will be able to leverage Quarto’s extensibility to create powerful, tailored solutions for your documentation needs. Whether you have just worked on a few Quarto projects or are an everyday user, this workshop will equip you with the tools and knowledge to take your document workflows to the next level.

The 2025 Tidy Dev Day will be on September 19th! We’ll gather after posit::conf near the conference venue (see the link to the event page at the bottom).

Tidy Dev Day (TDD) is an event where developers and open source contributors meet to collaboratively solve issues. You can hone your software engineering skills or work on your first contribution. We will have a slate of existing issues that you can work on with or without the assistance of our developers.

Here’s how Laura Acion described the 2019 event:

I wish there were more of these R-related dev days. Developing events that are friendly, diverse, and safe to advance not only the tidyverse. I see no downsides. Kudos to the organizers.

Plus…

Who should attend

You don’t have to have an extensive development background or experience solving issues, or making pull requests. You do need a GitHub account, and some git experience.

Leading up to TDD, we will hold (optional) virtual “office hours” for TDD participants to help you with your Git workflow so that you can stroll into TDD confident that your R, Git, GitHub, and IDE are set up in the most ideal way possible to work in harmony on your laptop.

How to sign up

There is a token $10 cost for the day; we provide the venue, snacks, lunch, and a barista. If cost is an issue, please email hadley@posit.co and we’ll work that out. We only charge a small fee to encourage people to show up for the day.

Get your ticket now!

Note: by using this link, you agree to Posit’s Privacy Policy, available at https://posit.co/about/privacy-policy/ . You also consent to using https://lu.ma/ for the purposes of processing your event attendance fees.

Previous Tidy Dev Days have sold out quickly, so don’t wait!

As an educator who teaches data science with R, I have LOTS of opinions about using artificial intelligence (AI) tools when learning R. But I will keep this post to the use of generative AI tools, like ChatGPT, in learning R, and specifically learning to do data science with R and the tidyverse.¹

I’ll first walk you through three case studies that demonstrate what asking for help from a generative AI tool looks like. Then, I’ll wrap up the post with some tips and good practices for getting the most out of help provided by these tools in the context of writing tidyverse code.

Before we get started, though, it’s important to note that knowledge bases of Large Language Models (LLMs) that underlie popular generative AI tools are private and lack transparency. There are important societal concerns about the fairness of equitable access to these tools. It’s unclear how developers or users of these models can be held accountable. Additionally, there is an environmental impact to using these tools.

Case study 1: Reshaping and plotting

The first case study features an example on reshaping and plotting the billboard data frame and it’s directly out of R for Data Science . In fact, it’s worked out in the book . Here is the initial prompt:

Use the billboard dataset in the tidyr package to create a visualization of rank vs. week number for each song in the dataset.

And the following is what ChatGPT by OpenAI suggests as the first answer:

The billboard dataset from the tidyr package contains weekly rankings of songs on the Billboard charts. Here’s how you can visualize the rank vs. week number for each song in the dataset using R:

# Load required libraries
library(tidyr)
library(ggplot2)
library(dplyr)

# Load the billboard dataset
data("billboard")

# Prepare the data for visualization
billboard_long <- billboard |>
  pivot_longer(
    cols = starts_with("wk"),
    names_to = "week",
    values_to = "rank",
    names_prefix = "wk",
    values_drop_na = TRUE
  )

# Convert week to a numeric value
billboard_long$week <- as.numeric(billboard_long$week)

# Create the visualization
ggplot(billboard_long, aes(x = week, y = rank, group = track, color = track)) +
  geom_line(show.legend = FALSE, alpha = 0.6) +
  scale_y_reverse() +  # Reverse the y-axis since rank 1 is the top position
  labs(
    title = "Song Rank vs. Week Number",
    x = "Week Number",
    y = "Rank",
    caption = "Data: Billboard (tidyr package)"
  ) +
  theme_minimal()

ChatGPT also provides a neat explanation of the code:

Explanation

1. Pivoting the Data: The billboard dataset is in wide format, with week columns (wk1, wk2, etc.). We use pivot_longer() to reshape it into a long format with week and rank columns.
2. Rank vs. Week Plot: Each song’s weekly rankings are connected with lines (geom_line() ), and we reverse the y-axis since rank 1 is the best.
3. Grouping by Track: The group aesthetic ensures lines are drawn separately for each song.

Output

This will create a line plot where each line represents a song’s rank progression over weeks. The y-axis is reversed to reflect higher rankings at the top.

There are a few things about this answer that are promising:

• The response is a tidyverse approach.
• It uses pivot_longer() as opposed to the superseded alternative gather() .
• The plot features a reversed y-axis, just like in the book

However, the resulting plot doesn’t show exactly what the prompt asked for – the lines are colored by track, which produces a busy plot that is difficult to interpret. While this is not ideal, it’s something a new learner can easily spot and ask ChatGPT for a follow up correcting it. For example, a subsequent prompt like the following fixes this issue:

Can you redraw the plot without coloring each line by track?

You can see this in action in this saved chat , in the second prompt. Here is the updated code suggested by ChatGPT:

# Create the visualization without coloring by track
ggplot(billboard_long, aes(x = week, y = rank, group = track)) +
  geom_line(alpha = 0.3, color = "blue") +
  scale_y_reverse() +  # Reverse the y-axis since rank 1 is the top position
  labs(
    title = "Song Rank vs. Week Number",
    x = "Week Number",
    y = "Rank",
    caption = "Data: Billboard (tidyr package)"
  ) +
  theme_minimal()

Note, however, that the only change wasn’t omitting the color = track aesthetic mapping. The alpha level is also changed (from 0.6 to 0.3) without a justification for that change and the lines are colored "blue". None of these are bad or wrong choices, but they can be confusing for new learners. Similarly, using theme_minimal() is not a bad or wrong choice either², but it’s not necessary, but this might not be obvious to a new learner.

Furthermore, while ChatGPT “solves” the problem, a thorough code review reveals a number of not-so-great things about the answer that can be confusing for new learners or promote poor coding practices:

• The code loads packages that are not necessary: tidyr and ggplot2 packages are sufficient for this code, we don’t also need dplyr. Additionally, learners coming from R for Data Science likely expect library(tidyverse) in analysis code, instead of loading the packages individualy.
• There is no need to load the billboard dataset, it’s available to use once the tidyr package is loaded. Additionally, quotes are not needed, data(billboard) also works.
• The code mixes up tidyverse and base R styles:
  • Changing the type of week to numeric can be done in a mutate() statement with the tidyverse, which would then warrant loading the dplyr package.
  • This can also be done within pivot_longer() with the names_transform argument.

All of these are addressable with further prompts, as I’ve done at the saved chat , in the last two prompts. But doing so requires being able to identify these issues and explicitly asking for corrections. In practice, I wouldn’t have asked ChatGPT to correct everything for me, I would have stopped after the first suggestion, which was a pretty good starting point, and made the improvements myself. However, a new learner might assume (and based on my experience seeing lots of new learner code, does assume) the first answer is the right and good or best answer since (1) it looks reasonable and (2) it works, sort of.

Furthermore, requesting improvements in subsequent calls can result in surprising changes that the user hasn’t asked for. We saw an example of this above, in updating the alpha level. Similarly, in the saved chat you can see that asking ChatGPT to not load the packages individually but to use library(tidyverse) instead results in this change as well as not loading the data with a data() call and adding a data transformation step with mutate() to convert week to numeric:

# Load the tidyverse package
library(tidyverse)

# Load the billboard dataset and prepare the data
billboard_long <- billboard |>
  pivot_longer(
    cols = starts_with("wk"),
    names_to = "week",
    values_to = "rank",
    names_prefix = "wk",
    values_drop_na = TRUE
  ) |>
  mutate(week = as.numeric(week))  # Convert week to numeric

Both of these are welcome changes, but it can be surprising to a new learner why they’re combined with updating the library() call. This is happening because with each call ChatGPT is “trying again” – it’s not just editing the previous answer but it’s regenerating an answer with additional context.

I should also note that ChatGPT generally gives better responses when asking about sample datasets because the model has probably been exposed to them somewhere in the training data. Next, let’s try a non-sample dataset.

Case study 2: Data cleaning

The next example is a lot more vague as it’s a task that, if someone asked me for help, I would reply with “Can you share the data with me?”, but ChatGPT happily generates an answer. That’s probably one of the reasons why people love these tools, they never respond to a question with another question, at least not in my experience.

Below is the prompt for this case study. I’ll provide it with no background first so you can read it as the AI tool would “read” it without any background.

Another variable that needs some cleaning up is membership_status. Currently it should either be NA or contain some text that says “Select … to register for this group”. Recode this variable to say "Closed" if the current value is NA or "Open" otherwise. Save the resulting dataset with this new variables as clubs, i.e., overwrite the original data frame. Then, display the first 10 rows of the dataset, moving membership_status to the beginning of the dataset to make sure it appears in the output in your rendered document.

This time, let’s try Claude by Anthropic. Below is the first response:

I’ll help you clean up the membership_status variable. Let’s break this down into steps:

# Recode membership_status to "Closed" if NA, "Open" otherwise
clubs$membership_status <- ifelse(is.na(clubs$membership_status), "Closed", "Open")

# Reorder columns to put membership_status first
clubs <- clubs[, c("membership_status", setdiff(names(clubs), "membership_status"))]

# Display first 10 rows
head(clubs, 10)

This code will:

• Use ifelse() to recode the variable based on whether it’s NA
• Reorder the columns to put membership_status first
• Show the first 10 rows of the modified dataset

Would you like me to explain any part of this solution in more detail?

I like the offer to explain more at the end! However, the suggested code does not use the tidyverse. In fact, it’s perhaps surprising that it uses R, this could very well have been a task for Python or anoher language commonly used for data science problems.

Let’s try again:

Can you suggest an answer that uses the tidyverse instead of base R?

And here is the result:

Here’s how to accomplish the same tasks using tidyverse functions:

clubs <- clubs %>%
  mutate(membership_status = if_else(is.na(membership_status), 
                                   "Closed", 
                                   "Open")) %>%
  relocate(membership_status)

clubs %>% 
  head(10)

This tidyverse solution:

• Uses mutate() with if_else() to recode the variable
• Uses relocate() to move membership_status to the front
• Shows the first 10 rows using head()

The tidyverse version is more readable and follows the principle of chaining operations with the pipe operator (%>%). if_else() is the tidyverse equivalent of base R’s ifelse() , with stricter type checking.

Would you like me to explain any of these functions in more detail?

We’re getting there! For new learners of the tidyverse, there are still a few aspects of this code that might be misleading:

• It doesn’t use the base pipe operator (|>), which is the pipe operator used in R for Data Science.
• Line breaks and indentation does not follow tidyverse style guidelines , which suggest that if the arguments to a function don’t all fit on one line, each argument should go on its own line.
• If clubs is a tibble, printing it will only display the first 10 rows anyway, so there’s no need for the head() call.

Once again, it’s possible to ask the tool to make these updates. At the time of developing this example, Claude didn’t provide a sharing link for the conversation (it does now!), but I’ve saved it at https://gist.github.com/mine-cetinkaya-rundel/c74dc7c5f2a27a846574edd063988431 . Even with vague prompts like “If clubs is a tibble, it’ll only print out the first 10 rows anyway,” it does exactly what we would want it to do, resulting in the following:

clubs <- clubs |>
  mutate(membership_status = if_else(is.na(membership_status), "Closed", "Open")) |>
  relocate(membership_status)

clubs

The operative word here being “want”. Once again, someone with enough experience with R and the tidyverse would not explicitly ask for these improvements; they would just make them themselves and carry on. But someone who is just learning the tidyverse would likely stop much earlier. In my experience, many new learners stop after the very first prompt, which looks unfamiliar, and hence potentially intimidating. For learners of the tidyverse, the simple “Can you do this with the tidyverse?” can be a very useful prompt improvement that gets them majority of the way there.

Case study 3: Web scraping

For the third and last example we’ll try scraping some data from the web, specifically some structured North Carolina weather data . For this example, I’ve used perplexity.ai .

My first prompt was:

Write code for scraping data from https://www.usclimatedata.com/climate/durham/north-carolina/united-states/usnc0192 .

This resulted in an answer using Python, BeautifulSoup, and pandas. So I followed up with:

Use R instead.

This resulted in the following.

# Load required libraries
library(rvest)
#> 
#> Attaching package: 'rvest'
#> The following object is masked from 'package:readr':
#> 
#>     guess_encoding
library(dplyr)

# Define the URL for Durham, North Carolina climate data
url <- "https://www.usclimatedata.com/climate/durham/north-carolina/united-states/usnc0192"

# Read the HTML content from the website
webpage <- read_html(url)

# Extract the table containing climate data
climate_table <- webpage %>%
  html_nodes("table") %>%
  .[[1]] %>% # Assuming the first table contains the relevant data
  html_table(fill = TRUE)

# Convert the table to a data frame
climate_data <- as.data.frame(climate_table)

# Display the scraped data
print(climate_data)
#>                                              JanJa FebFe MarMa AprAp MayMa
#> 1             Average high in ºF Av. high Hi 49.00  53.0 62.00 71.00 79.00
#> 2               Average low in ºF Av. low Lo 28.00  29.0 37.00 46.00 56.00
#> 3 Av. precipitation in inch Av. precip. Pre.  4.45   3.7  4.69  3.43  4.61
#>   JunJu
#> 1 85.00
#> 2 65.00
#> 3  4.02

Additionally, the suggestion included optional code for writing the data to CSV even though it wasn’t part of the prompt, though also not bad practice either when scraping data from the web.

# Optional: Save the data to a CSV file
write.csv(climate_data, "durham_climate_data.csv", row.names = FALSE)

First, this code doesn’t give us what we want:

climate_data
#>                                              JanJa FebFe MarMa AprAp MayMa
#> 1             Average high in ºF Av. high Hi 49.00  53.0 62.00 71.00 79.00
#> 2               Average low in ºF Av. low Lo 28.00  29.0 37.00 46.00 56.00
#> 3 Av. precipitation in inch Av. precip. Pre.  4.45   3.7  4.69  3.43  4.61
#>   JunJu
#> 1 85.00
#> 2 65.00
#> 3  4.02

We only have the first six months (the first table) and the formatting is not great, especially for the column names. Additionally, this doesn’t look like a tidy data frame – a better organization would be months in rows and temperatures in columns.

Let’s follow up with a better articulated prompt:

Update the code to scrape data for all months from both of the tables on the website and organizing the data with months as rows and temperature types as columns.

Here is the updated suggestion:

library(rvest)
library(dplyr)
library(tidyr)

url <- "https://www.usclimatedata.com/climate/durham/north-carolina/united-states/usnc0192"

# Read HTML content
webpage <- read_html(url)

# Extract all tables
climate_tables <- webpage %>%
  html_nodes("table") %>%
  html_table(header = TRUE, fill = TRUE)

# Check if we have at least 2 tables
if(length(climate_tables) >= 2) {
  # Process first table (Average High Temperatures)
  high_temp <- climate_tables[[1]] %>%
    select(Month = 1, High = 2) %>%
    mutate(High = as.numeric(gsub("[^0-9.]", "", High)))
  
  # Process second table (Average Low Temperatures)
  low_temp <- climate_tables[[2]] %>%
    select(Month = 1, Low = 2) %>% 
    mutate(Low = as.numeric(gsub("[^0-9.]", "", Low)))
  
  # Combine and organize data
  combined_data <- high_temp %>%
    full_join(low_temp, by = "Month") %>%
    arrange(factor(Month, levels = month.name))
  
  # Display cleaned data
  print(combined_data)
  
  # Save to CSV
  write.csv(combined_data, "durham_temperatures.csv", row.names = FALSE)
} else {
  stop("Required tables not found - website structure may have changed")
}
#> # A tibble: 3 × 3
#>   Month                                       High   Low
#>   <chr>                                      <dbl> <dbl>
#> 1 Average high in ºF Av. high Hi             49    89   
#> 2 Average low in ºF Av. low Lo               28    70   
#> 3 Av. precipitation in inch Av. precip. Pre.  4.45  3.94

#> [1] TRUE

There is a lot going on here, especially for a new learner, and the result is ultimately not what we want:

combined_data
#> # A tibble: 3 × 3
#>   Month                                       High   Low
#>   <chr>                                      <dbl> <dbl>
#> 1 Average high in ºF Av. high Hi             49    89   
#> 2 Average low in ºF Av. low Lo               28    70   
#> 3 Av. precipitation in inch Av. precip. Pre.  4.45  3.94

Let’s try one more time, following up with this prompt:

This is not what I wanted. First scrape the data from the two tables for months January to June and July to December. Then put them together. Then reshape the data to have months as rows and temperature types as columns.

library(rvest)
library(dplyr)
library(tidyr)

url <- "https://www.usclimatedata.com/climate/durham/north-carolina/united-states/usnc0192"
webpage <- read_html(url)

# Extract all climate tables (4 tables total)
all_tables <- webpage %>% 
  html_nodes("table.climate-table") %>% 
  html_table(header = TRUE)

# Process temperature data from first two tables (Jan-Jun and Jul-Dec)
high_temp <- bind_rows(
  all_tables[[1]] %>% select(Month = 1, High = 2),
  all_tables[[2]] %>% select(Month = 1, High = 2)
) %>% mutate(High = as.numeric(gsub("°F", "", High)))
#> Error in all_tables[[1]]: subscript out of bounds

low_temp <- bind_rows(
  all_tables[[3]] %>% select(Month = 1, Low = 2),
  all_tables[[4]] %>% select(Month = 1, Low = 2)
) %>% mutate(Low = as.numeric(gsub("°F", "", Low)))
#> Error in all_tables[[3]]: subscript out of bounds

# Combine and format final dataset
climate_data <- high_temp %>% 
  left_join(low_temp, by = "Month") %>% 
  mutate(Month = factor(Month, levels = month.name)) %>% 
  arrange(Month) %>% 
  select(Month, High, Low)

# Display formatted results
print(climate_data)
#> # A tibble: 3 × 3
#>   Month  High   Low
#>   <fct> <dbl> <dbl>
#> 1 NA    49    89   
#> 2 NA    28    70   
#> 3 NA     4.45  3.94

Unfortunately this gives an error. However, the presentation in the answer from Perplexity makes it seem like the data were scraped successfully since a table with rows as months and columns as temperature types is included in the explanation:

       Month High Low
1    January   50  30
2   February   54  32
3      March   63  39
4      April   72  47
5        May   79  56
6       June   85  64
7       July   89  69
8     August   87  68
9  September   81  60
10   October   72  49
11  November   63  39
12  December   54  32

I’m not sure how these data were extracted, but we know it’s not with the R code provided above. The values are also not correct (e.g., high and low in January should be 49 and 28, instead), so it’s completely unclear where they’re coming from. You can follow along with this thread at https://www.perplexity.ai/search/write-code-for-scraping-data-f-6kRnwLDTTpe8vItl08Bo3g . I tried a few more prompts and finally gave up. While the other two tasks were much more straightforward, the web scraping task seems to be more difficult for this tool. I should note that I used different services for each task, and the lack of success in this last one might be due to that as well.

Ultimately, though, as the complexity of the task increases, it (understandably) gets more difficult to get to straightforward and new-learner-friendly answers with simple prompts.

Tips and good practices

I’ll wrap up this post with some tips and good practices for using AI tools for (tidyverse) code generation. But first, a disclaimer – this landscape is changing super quickly. Today’s good practices might not be the best approaches for tomorrow. However, the following have held true over the last year so there’s a good chance they will remain relevant for some time into the future.

1. Provide context and engineer prompts: This might be obvious, but it should be stated. Providing context, even something as simple as “use R” or “use tidyverse” can go a long way in getting a semi-successful first suggestion. Then, continue engineering the prompt until you achieve the results you need, being more articulate about what you want at each step. This is easier said than done, though, for new learners. If you don’t know what the right answer should look like, it’s much harder to be articulate in your prompt to get to that answer. On the other hand, if you do know what the right answer should look like, you might be more likely to just write the code yourself, instead of coaching the AI tool to get there. Another potentially helpful tip is to end your initial prompt with something like “Ask me any clarifying questions before you begin”. This way you don’t have to think about all the necessary context at once, you can get the tool to ask you for some of the details.

2. Check for errors: This also seems obvious – you should run the code the tool suggests and check for errors. If the code gives an error, this is easy to catch and potentially easy to address. However, sometimes the code suggests arguments that don’t exist that R might silently ignore. These might be unneeded arguments or a needed argument but not used properly due to how it’s called or the value it’s set to. Such errors are more difficult to identify, particularly in functions you might not be familiar with.

3. Run the code it gives you, line-by-line, even if the code is in a pipeline: Tidyverse data transformation pipelines and ggplot layers are easy to run at once, with the code doing many things with one execution prompt, compared to Base R code where you execute each line of code separately. The scaffolded nature of these pipelines are very nice for keeping all steps associated with a task together and not generating unnecessary interim objects along the way. However, it requires self-discipline to inspect the code line-by-line as opposed to just inspecting the final output. For example, I regularly encounter unnecessary group_by() /ungroup() s or select() s steps injected into pipelines. Identifying these requires running the pipeline code line-by-line, and then you can remove or modify them to simplify your answer. My recommendation would be to approach the working with AI tools for code generation with an “I’m trying to learn how to do this” attitude. It’s then natural to investigate and interact with each step of the answer. If you approach it with a “Solve this for me” attitude, it’s a lot harder to be critical of seemingly functioning and seemingly good enough code.

4. Improve code smell: While I don’t have empirical evidence for this, I believe for humans, taste for good code develops faster than ability. For LLMs, this is the opposite. These tools will happily barf out code that runs without regard to cohesive syntax, avoiding redundancies, etc. Therefore, it’s essential to “clean up” the suggested code to improve its “code smell”. Below are some steps I regularly use:

   • Remove redundant library calls.
   • Use pkg::function() syntax only as needed and consistently.
   • Avoid mixing and matching base R and tidyverse syntax (e.g., in one step finding mean in a summarize() call and in another step as mean of a vector, mean(df$var).
   • Remove unnecessary print() statements.³
   • Consider whether code comments address the “why” or the “what.” If comments describe relatively self-documenting code, consider removing them.

5. Stuck? Start a new chat: Each new prompt in a chat/thread is evaluated within the context of previous prompts in that thread. If you’re stuck and not getting to a good answer after modifying your prompt a few times, start fresh with a new chat/thread instead.

6. Use code completion tools sparingly if you’re a new user: Code completion tools, like GitHub Copilot , can be huge productivity boosters. But, especially for new learners, they can also be huge distractions as they tend to take action before the user is able to complete a thought in their head. My recommendation for new learners would be to avoid these tools altogether until they get a little faster at going from idea to code by themselves, or at a minimum until they feel like they can consistently write high quality prompts that generate the desired code on the first try. And my recommendation for anyone using code completion tools is to experiment with wait time between prompt and code generation and set a time that works for well for themselves. In my experience, the default wait time can be too short, resulting in code being generated before I can finish writing my prompt or reviewing the prompt I write.⁴

7. Use AI tools for help with getting help: So far the focus of this post has been on generating code to accomplish certain data science tasks. Perhaps the most important, and most difficult, data science task is asking good questions when you’re stuck troubleshooting. And it usually requires or is greatly helped by creating a minimum reproducible example and using tools like reprex . This often starts with creating a small dataset with certain features, and AI tools can be pretty useful for generating such toy examples.

Additional links:

• Quarto 1.6 release post
• Download Positron
• Quarto’s _brand.yml documentation

Hello there! I’ve been working on ggplot2 for a while now, and I’d like to tell you how that came about and what it is like.

How I got involved

My journey into learning R started in 2017 during an internship at the EMBL-EBI. The main gripe about base R plotting that drove me into ggplot2’s arms were the arcane invocations to get anything else than one of the pre-approved chart types. In contrast, ggplot2 absorbs a bunch of small paper cuts, is very compositional in nature while remaining highly customisable. In a bid to “learn from the mistakes of others” rather than (continue to copiously) make my own, I became active on Stack Overflow answering questions and solving plotting issues. For posterity: this was in the days before you could ask an large language model for personalised advice and actual humans were equally frustrated on both sides of the question.

I was keeping track of solutions to common problems in a personal cookbook that had its own arcane invocations. To give a bit of flavour: much of the cookbook was about preparing gtables (the data structure that comes out of building a plot) for combining and aligning plots. ¹ The cookbook eventually grew into my first ggplot2 extension package: ggh4x . Perhaps that package would be best subtitled: ‘Remedies to my common ggplot2 ailments’. It contains a bunch of miscellaneous functions ranging from reorganising facets to putting minor ticks on the axes. The nature of the package was also its downside, as ggh4x lacked any sense of scope (and still does, as befits any first package).

Around the time when I was really getting into ggplot extensions, Gina Reynolds had started organising a meeting for people who build ggplot2 extensions. It is an interesting place to meet others and hear about their packages and how they face interacting with the ggplot2 extension system. I started attending with some degree of regularity and made a discussion place on GitHub. We now use this for general exchange of ideas, but also package specific issues.

Meanwhile, the questions on Stack Overflow kept directing my attention at the ggplot2 issue tracker every once in a while. After lurking in there for a bit, I started my first informal contributions to ggplot2 itself by answering the simple stuff just as I did on Stack Overflow. It may not seem like much of a contribution, but in retrospect, answering issues helps triaging them: it separates those issues that need additional changes in ggplot2 from those that do not. My first ‘proper contribution’ in the shape of a pull request was in 2020. It replaced 3 lines of code with 2 lines of code to benefit type stability (this was prior to vctrs )².

In 2022, I commented “I’d be willing to take a stab at this” on an issue proposing a large refactor of the guide system. I like to think it was this precise moment that Thomas, the project lead after having taken over for Hadley, took notice and later invited me to join the team³. This new guide system ended up laying the foundation for legendry , so it wasn’t entirely out of unselfish reasons that I volunteered. At any rate, this is a great opportunity to fill big shoes on a major R project, so I’m very excited to have joined!

Becoming an insider

Part of being on the team is straightforward. You triage issues. You fix bugs. You implement new features. At the point that I joined, I had already done these things as an outsider. The only thing that really changes is that you get the keys to the kingdom: you can now close issues and merge pull requests ⁴. You’re then trusted to wield this power wisely. You then hope you do.

At the time I joined the most active maintainers were Thomas, Claus and Hiroaki. I was surprised to learn that really most communication happens on GitHub and it is all public discussion. Even more abstract coordination that does not neatly fit into a single issue, like preparing a new release, didn’t occur behind closed doors. I think what made my introduction to the team more awkward than it needed to be was that GitHub issues is not really a good place for announcements where you can say ‘Hi everyone, this person is on the team now and will be doing stuff in the project’. I had interacted with the other active maintainers before, so I wasn’t a completely alien actor, but I felt some unclarity lingered longer than it ought have. Perhaps I should more assertively have introduced myself ⁵.

However, by the time posit::conf(2024) was over, I’ve met 6 out of the 9 other authors in person. I have more thoughts about conf and my first time in the United States, but it has been amazing to meet all these people in person whose work you’ve been admiring for a while!

Maintaining ggplot2

The ggplot2 package has both the blessing and the curse of being a popular package. One the one hand, it is a blessing that people care about the project, post issues that they find and make intermittent contributions. The curse is that it is such a staple in the R ecosystem, that almost any change will inadvertently affect somebody else’s code. Not only because ggplot2 is widely used, but also because people have been …creative… with how they are using ggplot2. The art of making changes is to largely affect plots in a good way.

The first big project I was rummaging through was the guide system I proposed to rewrite. The guide system had never been advertised as an official extension point, but naturally that didn’t preclude people from using it as an extension point anyway.⁶ So in addition to rewriting the system, we also had to prevent terribly breaking extensions that relied on the old system. In some cases, this meant sending out PRs to other packages to be compatible with both systems.

Having worked through a good number of issues at this point in time, I can see some emergent patterns. Different patterns can be partially explained by different audiences. The regular user wants to be empowered to execute their vision of a plot effectively. Maintainers of extensions would often like things to work consistently or change a very obscure line somewhere that they have identified as blocking a niche use case. Teachers would like their students to get stuck less often, which often involves improving error messages. All in all, there is no shortage of issues to work through.

The next big thing we’re working on is some practical necromancy in getting themeable aesthetics resurrected, which was initiated by Dana Paige Seidel all the way back in 2018! We’d like the theme to be a home for more default choices than just non-data elements. Default layer aesthetics are a start, but we plan on putting in default palettes too.

A few words of thanks

I’ve been plucked from a level of relative obscurity —a package maintainer that has this weird miscellaneous package— into the path of a flagship R project, for which I’m very grateful. First and foremost I’m thankful to Thomas Lin Pedersen, who has put me into this position and steers the ggplot2 project. Secondly to Hadley Wickham and the rest of the tidyverse team, who make me feel included; both at conf and during regular meetings⁷. Thirdly, the co-authors I met during conf: Claus Wilke, for whose workshop I TA’d, but also Kara Woo and Winston Chang. Lastly, I’d like to thank Posit the company for contracting me to do work I also enjoy as a hobby!

We’ve had eight previous summer interns and these led to the creation of a number of new packages: agua , applicable , bundle , butcher , shinymodels , spatialsample , and stacks . Our own Simon Couch is a former intern who won an award for his work.

This year, the primary focus is on expanding our feature selection capabilities. Some of this will involve new recipe steps and other functions. Towards the end of the internship, there might be time to work on other things, too!

To apply, make sure that you have a GitHub handle and follow this link:

https://posit.co/job-detail/?gh_jid=6323043003

The internship is US-based.

If you want to know what the internship is like, a few of our alumni have written about it:

• A summer with RStudio (2018)
• RStudio Summer Internship (2018)
• This Is Not Like the Others (2019)
• Tidymodels Internship (2020)
• I know what I did last summer (2022)

We can’t wait to get started and look forward to reading your applications.

There may be times when you would like to single-source content across multiple pages/files to reduce the risk of errors, produce consistent content that is easy to maintain, and ultimately save valuable time. Quarto (an open-source technical publishing system), provides an Includes feature (the equivalent of an R Markdown “child” document) that allows you to reuse content across multiple documents/files/pages.

To achieve this, simply create chunks of content (text, tables, code, callouts, images, etc.) and then insert it using the Include shortcode: {{< include _content.qmd >}}.

Typically, you must keep your content general enough so it can be reused in several places. In other words, if you needed to add a name or an image that is specific to that file, you would assume that you wouldn’t be able to use an include, or you would have to use several smaller includes sewn into uniquely written content.

But what if you need your single-sourced content to be more specific? You can use Includes with meta shortcode (variables) to add precise values defined at the file level.

Walkthrough example

Let us walk you through an example of how to achieve this.

Before you begin:

• Quarto version 1.5+ was used for this walkthrough example.
• This has been tested with both new and existing Website projects.
• A var shortcode enables you to insert content from the project or file level.
• The meta shortcode allows you to insert content from Pandoc metadata (e.g., YAML at the top of the document and/or in _quarto.yml).
• As you preview your site, pages will be rendered and updated. However, if you make changes to global options (e.g. _quarto.yml or included files) you need to fully re-render your site to have all of the changes reflected. Consequently, you should always fully quarto render your site before deploying it, even if you have already previewed changes to some pages with the preview server.

Create the content:

Here is an example of a file with content we want to reuse across several pages.

1

In this document, we cover facts that are unique to the state, like the state's population, its flower, and animal.

This content is general enough to use as each state’s introduction but lacks the facts that are unique to each state. So, we could insert the Include into each state’s file and then add specific content that is unique to the state:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

---
title: New York
---

{{< include _snippets/state-intro.qmd >}}

New York has a geographical size of 54,555, making it the 27th largest state with an estimated population size of 19.8 million.

The state's flower is the Rose, as shown below:

![](images/ny/flower.png)

Why are we doing this?

Instead of copying and pasting this content into each file, and then updating it with each state’s fact (which introduces a higher risk of making an error), we can use meta variables to insert specific values.

Let’s execute

First, I create a file within my _snippets directory named facts.qmd. Throughout the file, I am going to insert a unique meta variable for each occurrence that I want the content to be specific to the state:

1

{{< meta state >}} covers approximately {{< meta square-miles >}} making it the {{< meta size-rank >}} largest state in the United States. As of 2023, {{< meta state >}} has an approximate population of about {{< meta population >}}.

I can define each of the meta variables within the individual file that I plan on reusing this content. So, in my ny.qmd file, I define each variable in the YAML metadata. Then, insert the facts.qmd file with the undefined meta shortcodes using an include:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

---
title: New York
state-abbr: ny
state: New York
size-rank: 27th
square-miles: 54,555
population: 19.8 million
---


{{< include _snippets/facts.qmd >}}

As you can see, the rendered file has the meta shortcodes populated with the definitions that you assigned to each value in the file’s YAML.

But, I would also like to add the state’s flower and animal with images of each. You can achieve this by editing the document to add this information and images:

1
2
3
4
5
6
7
8
9

{{< include _snippets/facts.qmd >}}

New York's official flower is the Rose:

![](../images/ny/flower.png)

And the official animal is the Beaver:

![](../images/ny/animal.png)

Or, you can get creative and use meta shortcodes in your image paths so you can continue to manage all of the content in a single file:

1
2
3
4
5
6
7

{{< meta state >}}'s official flower is the {{< meta flower >}}, pictured below:

![The official {{< meta state >}} state flower, the {{< meta flower >}}](../images/{{< meta state-abbr >}}/flower.png)

Lastly, {{< meta state >}}'s official animal is the {{< meta animal >}}, pictured below:

![The official {{< meta state >}} state animal, the {{< meta animal >}}](../images/{{< meta state-abbr >}}/animal.png)

As you can see, my image paths have {{< meta state-abbr >}} which is defined in the new-york file as “ny”.

When we render the project, the image path updates to /images/ny/flower.png pointing to the existing flower image in the ny directory:

In theory, you could do this for each state as long as each directory follows the same naming conventions, i.e., pa/flower.png and vt/flower.png.

This does require an organized and scalable approach since the images will have to follow the same directory and file-naming conventions, but in doing so, you can create individualized pages and images using a single include.

The rendered example

Here is New York’s page:

Here is Pennsylvania’s page:

Each page was built using a single (shared) file:

1

{{< include _snippets/facts.qmd >}}

Learn more about Quarto Includes

Quarto’s Includes feature allows you to improve your content creation process by reducing redundancy and maintaining consistency across multiple documents. Whether you’re managing technical documentation, educational materials, or any other content, this approach can help you save time, reduce errors, and deliver polished results.

Learn more with these resources:

• Get Started - Quarto
• Quarto - Includes
• Quarto - meta Variables
• An overview of Single Source Authoring

YouTube Playlist

Quarto Websites 1: Build your homepage

In this video, you’ll get a running start by using a template we’ve designed to be functional and attractive, and that will serve as a foundation for the rest of the video series. You’ll customize the content of your homepage, and how it looks, and along the way learn about the two key files in a Quarto website index.qmd and _quarto.yml. Finally, you’ll learn one way to publish your website so other people can see it.

Links: About pages | YAML appearance options

Code: Starter | Final

Quarto Websites 2: Add pages and navigation

Now you’ve got a homepage, you’ll likely want to add some other pages. In this video, learn how to add pages to your website, and help people find them, by adding them to your website navigation.

Links: Bootstrap icons | Navigation bar options | Quarto website navigation

Code: Starter | Final

Quarto Websites 3: Customize appearance with CSS/SCSS

You now have a set of content you are happy with on your website, but how do you customize the look and feel of your site beyond options set in YAML? In this video, you’ll start by learning the basics of CSS and SCSS and how to make good design choices. Then, you’ll see how to apply these choices to your Quarto website.

Links: Color contrast checker | Google fonts

Code: Starter | Final

Quarto Websites 4: Add lists of content with listings

Adding a listing page to your website is a great way to showcase your projects, talks, publications or blog posts. In this video you’ll learn how to create a listing page in Quarto and see two ways to populate it with content: Quarto documents, or a yaml file.

Links: Listings | Andrew Heiss’ teaching listing

Code: Starter | Final

Materials: YouTube playlist | Slides | Starter code

1. Hello, Quarto Dashboards

Start by getting to know Quarto dashboards and make your very first dashboard using either R or Python and share it online. Slides

2. Quarto Dashboards Components

Then, build up your arsenal of dashboard components to add navigation, sidebars, tabsets, value boxes, and fine-tune layout. Slides

3. Quarto Dashboards Theming and Styling

Finally, make your dashboard pop by adding a theme and making styling tweaks. Slides

Talks included in this playlist are as follows:

• Updates from Posit, with Hadley Wickham, Charlotte Wickham, George Stagg, and James Blair
• Andrew Bray - Closeread: bringing Scrollytelling to Quarto
• Meghan Hall - Designing and Deploying Internal Quarto Templates
• David Keyes - Report Design in R: Small Tweaks that Make a Big Difference
• Mine Çetinkaya-Rundel - Reproducible, dynamic, and elegant books with Quarto
• Cynthia Huang - Quarto for Knowledge Management
• Regina Lionheart - Making Waves with R, Python, and Quarto
• Joshua Cook - Quarto: A Multifaceted Publishing Powerhouse for Medical Researchers
• Tyler Morgan-Wall - Quarto, AI, and the Art of Getting Your Life Back
• Sean Nguyen - Beyond Dashboards: Dynamic Data Storytelling with Python, R, and Quarto Emails
• Richie Moluno - JSquarto: Bridging JavaScript Documentation with Quarto’s Power
• Mika Braginsky - DataPages for interactive data sharing using Quarto
• Brennan Antone - Democratizing Organizational Surveys with Quarto and Shiny

Introduction to Quarto

• Led by Andrew Bray , Berkeley University

• Ideal for beginners looking to create rich documents

Build-a-Dashboard Workshop (with Quarto, R, and/or Python)

• Led by Mine Çetinkaya-Rundel , Posit, PBC, Duke University

• Perfect for those familiar with computational notebooks in R and/or Python who want to create eye-catching dashboards

Quarto Websites

• Led by Charlotte Wickham and Emil Hvitfeldt , Posit, PBC

• Great choice for those wanting to build a website from scratch with Quarto

Introduction to Quarto

This workshop will prepare you to author a rich array of documents in Quarto, the next generation of R Markdown. Quarto is an open-source scientific and technical publishing system that offers multilingual programming language support to create dynamic and static documents, books, presentations, blogs, and other online resources.

This workshop focuses on single documents. You will learn to create static documents, add interactivity to them with Shiny and HTML widgets, or steer them toward sophisticated scientific documents.

In the afternoon, you’ll use the same authoring approaches to create slide presentations in various formats, such as reveal.js, Beamer, and PPTX.

This workshop is for you if you:

• Have a basic knowledge of how to use the RStudio IDE,

• Have some familiarity with Markdown, or

• Are excited to author flexible single documents like technical reports and slide presentations.

Build-a-Dashboard Workshop (with Quarto, R, and/or Python)

You already analyze and summarize your data in computational notebooks with R and/or Python. What’s next? 

You can share your insights or allow others to make their own conclusions in eye-catching dashboards and straight-forward to author, design, and deploy Quarto Dashboards, regardless of the language of your data processing, visualization, analysis, etc. With Quarto Dashboards, you can create elegant and production-ready dashboards using a variety of components, including static graphics (ggplot2, Matplotlib, Seaborn, etc.), interactive widgets (Plotly, Leaflet, Jupyter Widgets, htmlwidgets, etc.), tabular data, value boxes, text annotations, and more. Additionally, with intelligent resizing of components, your Quarto Dashboards look great on devices of all sizes.

And importantly, you can author Quarto Dashboards without leaving the comfort of your “home” – in plain text markdown with any text editor (VS Code, RStudio, Neovim, etc.) or any notebook editor (JupyterLab, etc.). This workshop will walk you through building an increasingly complex dashboard using various layout options and deploying them as static web pages (with no special server required), as well as with a Shiny Server on the backend for enhanced interactivity.

This workshop is for you if you:

• Do data analysis in computational notebooks,

• Share your results with your audience in static or interactive dashboards and

• Want to improve the design, user interface, and experience of your dashboards.

Quarto Websites

Do you need a professional website to showcase your work? Or have you got an idea for a website at work, but it needs to reflect your organization’s brand? If you’ve used Quarto to produce a document, you’ve already got the technical skills to create a Quarto website. In this workshop, you’ll learn everything else you need to build a website and customize its appearance.

You’ll get a running start by using a template we’ve designed to be functional and attractive but also act as a guide for your learning. Then you’ll:

• Add pages and navigation, and learn best practices for structuring your content.

• Master the basics of SCSS and CSS and how they apply to Quarto websites to customize your site’s visual appearance.

• Use listings, a special kind of page, to showcase related content like blog posts, projects, or talks.

By the end of the workshop, you’ll have built and published (if you want) a personal website, but the same tools and techniques will apply to any kind of website you might like to build.

We’ll assume you’ve used Quarto to produce documents, but we won’t assume you have any HTML, CSS/SCSS, or Git/GitHub experience, nor will we assume any particular programming language (R, Python, etc.) or level of programming experience.

This workshop is for you if you:

• Have used Quarto to generate documents (e.g., HTML, PDF, MS Word, etc.)

• Are comfortable editing plain text documents (e.g., `.qmd`) in your IDE (e.g., RStudio, Visual Studio Code, etc.) and

• Want to walk away with your own personal website.

Learn more about posit::conf(2024)

Want to explore the complete catalog of posit::conf(2024) workshops and talks?

• Workshops on August 12: Head over to our workshop listing to discover detailed information about the courses and instructors.

• Talks on August 13 and August 14: Peruse the conference agenda .

  • Tip: For a quick view of all Quarto talks, filter for “Quarto” under topics.

Ready to secure your spot? Visit the conference website for comprehensive details on pricing and the agenda, and register today !

It’s been a hot minute since the last one, but we are very excited to announce that the next tidyverse developer day will be after posit::conf in Seattle on August 15, 2024. A big thanks goes to Fred Hutch Cancer Center for donating the space!

What is the tidyverse developer day? TDD is a day of learning and coding to nurture regular contributors to the tidyverse. We’ll provide food; you’ll bring your laptop and enthusiasm. The tidyverse team and other community helpers will be on hand to help you hit the ground running and/or get over any stumbling blocks that you encounter. Don’t have any ideas for something to work on? No problem! We’ll be tagging issues in advance to make sure there’s lots to do for any- and everyone, regardless of level of expertise.

Who should attend? Anyone who would like to get better at contributing to the tidyverse! Everyone is welcome regardless of whether you’ve never done a PR before, or if you’ve already made your 10th package. But you do need a ticket; to provide a fulfilling experience for all attendees we need to carefully manage the ratio of attendees to helpers.

How much does it cost? $10. This doesn’t cover the costs of the event because we don’t want to make attendance contingent on your ability to pay, but we’ve found some monetary commitment discourages people from taking tickets that they don’t end up using. But if the cost would prevent you from attending, please email jenny@posit.co and we can figure something out.

Buy your ticket now!

We’re tickled pink to announce the support of survival analysis for time-to-event data across tidymodels. The tidymodels framework is a collection of R packages for modeling and machine learning using tidyverse principles. This new support makes survival analysis a first-class citizen in tidymodels and gives censored regression modeling the same flexibility and ease as classification or regression.

The functionality resides in multiple tidymodels packages. The easiest way to install them all is to install the tidymodels meta-package:

install.packages("tidymodels")

This blog post will highlight why this is useful, explain which additions we’ve made to the framework, and point to several places to learn more.

You can see a full list of changes in the release notes:

• parsnip
• censored
• yardstick
• workflows
• tune
• finetune
• workflowsets

Increasing usefulness: Two perspectives

We’d like to situate the changes from two different perspectives: How this is useful for people already familiar with survival analysis as well as for people already familiar with tidymodels.

If you are already familiar with both: Excellent, this is very much for you! Read on for more details on how these two things come together.

Adding tidymodels to your tool kit

If you are already familiar with survival analysis but maybe not tidymodels, these changes now unlock a whole framework for predictive modelling for you. It applies tidyverse principles to modeling, meaning it strives to be consistent, composable, and human-centered. The framework covers the modeling process from the initial test/train split of the data all the way to tuning various models. Along the way it offers a rich selection of preprocessing techniques, resampling schemes, and performance metrics along with safe-guards against accidental overfitting. We make the full case for tidymodels at tidymodels.org .

Adding survival analysis to your tool kit

If you are already familiar with tidymodels but maybe not survival analysis, these changes let you leverage the familiar framework for an additional type of modeling problem. Survival analysis offers methods for modeling time-to-event data. While it has its roots in medical research, it has broad applications as that event of interest can be so much more than a medical outcome. Take customer churn as an example: We are interested in how long someone is a customer for and when they churn. For customers who churned, we have the complete time for which they were customers. For existing customers, we only know how long they’ve been customers for so far. Such observations are called censored. So what are our modeling choices here?

We could look at the time and model that as a regression problem. We could look at the event status and model that as a classification problem. Both options might get us somewhere close to an answer to our original modeling question but not quite there. Censored regression models let us model an outcome that includes both aspects, the time and the event status. And with that, it can deal with both censored and uncensored observations appropriately. With this type of model, we can predict the survival time, or in more applied terms, how long someone will stay as a customer. We can also predict the probability of survival at a given time point. This lets us answer questions like “How likely is it that this customer will churn after 3 months?”. See which prediction types are available for which models at censored.tidymodels.org .

Ch-ch-changes: What’s new for censored regression?

The main components needed for this full-fledged integration of survival analysis into tidymodels were

• Survival analysis models that can take censoring into account
• Survival analysis performance metrics that can take censoring into account
• Integrating changes required by these models and metrics into the framework

For the models, parsnip gained a new mode, "censored regression", for existing models as well as new model types such as proportional_hazards(). Engines for these reside in censored, the parsnip extension package for survival models. The "censored regression" mode has been around for a while and we’ve previously shared posts on our initial thoughts and the release of censored .

Now we’ve added the metrics: yardstick v1.3.0 includes new metrics for assessing censored regression models. Somewhat similar to how metrics for classification models can take class predictions or probability predictions as input, these survival metrics can take predicted survival times or predictions of survival probabilities as input.

The new metrics are

• Concordance index on the survival time via concordance_survival()
• Brier score on the survival probability and its integrated version via brier_survival() and brier_survival_integrated()
• ROC curve and the area under the ROC curve on the survival probabilities via roc_curve_survival() and auc_roc_survival() respectively

The probability of survival is always defined at a certain point in time. We call that time point the evaluation time because it is then also the time point at which we want to evaluate model performance. Metrics that work on the survival probabilities are also called dynamic metrics and you can read more about them here:

• Dynamic Performance Metrics for Event Time Data
• Accounting for Censoring in Performance Metrics for Event Time Data

The evaluation time is also the best example to illustrate the changes necessary to the framework. Most of them were under the hood but the evaluation time is user-facing. Let’s take a look at that.

While the need for evaluation times is dependent on type of metric, it is not actually specified as an argument to the metric functions. Like yardstick’s other metrics, those take pre-made predictions as the input. So where do you specify it then?

• You need to specify it to directly predict survival probabilities, via predict() or augment(). We introduced the corresponding eval_time argument first for fitted models in parsnip and censored and have added it now for workflows.
• You also need to specify it for the tuning functions tune_*() from tune and finetune as they will predict survival probabilities as part of the tuning process.
• Lastly, the eval_time argument now shows up when working with tuning/resampling results such as in show_best() or autoplot(). Those changes span the packages generating and working with resampling results: tune, finetune, and workflowsets.

As we said, plenty of changes under the hood but you shouldn’t need to notice them. Everything else should work “as usual,” allowing the same ease and flexibility in combining tidymodels functionality for censored regression as for classification and regression.

The pieces come together: A case study

To see it all in action, check out the case study How long until building complaints are dispositioned? on the tidymodels website!

The city of New York publishes data on complaints received by the Department of Buildings that include how long it takes for a complaint to be dealt with (“dispositioned”) as well as several characteristics of the complaint. The case study covers a full analysis. We start with splitting the data into test and training sets, explore different preprocessing strategies and model types via tuning, and predict with a final model. It should give you a good first impression of how to use tidymodels for predictive survival analysis.

We hope you’ll find this new capability of tidymodels useful!

Acknowledgements

Many thanks to the people who contributed to our packages since their last release:

parsnip: @AlbanOtt2 , @birbritto , @christophscheuch , @EmilHvitfeldt , @Freestyleyang , @gmcmacran , @hfrick , @jmunyoon , @joscani , @jxu , @marcelglueck , @mattheaphy , @mesdi , @millermc38 , @nipnipj , @pgg1309 , @rdavis120 , @seb-mueller , @SHo-JANG , @simonpcouch , @topepo , @vidarsumo , and @wzbillings .

censored: @bcjaeger , @brunocarlin , @EmilHvitfeldt , @hfrick , @noahtsao , and @tripartio .

yardstick: @aecoleman , @asb2111 , @atsyplenkov , @bgreenwell , @Dpananos , @EduMinsky , @EmilHvitfeldt , @heidekrueger , @hfrick , @iacrowe , @jarbet , @jxu , @mattwarkentin , @maxwell-geospatial , @moloscripts , @rdavis120 , @ruddnr , @SimonCoulombe , @simonpcouch , @tbrittoborges , @tonyelhabr , @tripartio , @TSI-PTG , @vnijs , @wbuchanan , and @zkrog .

workflows: @Milardkh , @simonpcouch , and @topepo .

tune: @AlbertoImg , @dramanica , @EmilHvitfeldt , @epiheather , @hfrick , @joranE , @jrosell , @jxu , @kbodwin , @kenraywilliams , @KJT-Habitat , @lionel- , @marcozanotti , @MasterLuke84 , @mikemahoney218 , @PathosEthosLogos , @Peter4801 , @simonpcouch , @topepo , and @walkerjameschris .

finetune: @EmilHvitfeldt , @hfrick , @jdberson , @jrosell , @mfansler , @ruddnr , @simonpcouch , and @topepo .

workflowsets: @dchiu911 , @hfrick , @jkylearmstrong , @PathosEthosLogos , and @simonpcouch .

Some highlights from the webinar include:

• Step-by-step instructions for getting started with a new manuscript project

• Obtaining multiple formats from one source

• An overview of the rich front matter

• Embedding computations from supplementary notebooks

  • Note that I demoed embedding computations in R from .qmd files however it’s also possible to embed computations from Jupyter notebooks and computations done in Python.

• A live-coding demo of authoring Quarto manuscripts with RStudio and all the bells-and-whistles of the visual editor, including:

  • cross referencing
  • citations
  • inline code

• Ability to actually interact with code from a manuscript with Binder

• And a rich Q&A, thanks to the audience!

The slides (also written in Quarto!) and their source code can be found at the links below:

• Slides: https://mine.quarto.pub/quarto-manuscripts-rmed

• Source code for slides: https://github.com/mine-cetinkaya-rundel/quarto-manuscripts-rmed

In addition, the webinar featured a reproduction of a medical manuscript with Quarto.² Materials from this reproduction can be found at the links below:

• Manuscript homepage: https://mine-cetinkaya-rundel.github.io/indo-rct

  • This is an HTML page but you can also access PDF and MS Word versions of the manuscript by clicking on their respective links.
  • You can also find a link to the Binder instance for this manuscript.³

• Source code for manuscript: https://github.com/mine-cetinkaya-rundel/indo-rct

Ready to get started writing a manuscript with Quarto? Go to https://quarto.org/docs/manuscripts for more info and a step-by-step tutorial. Happy authoring!

Fairness assessment features for tidymodels extend across a number of packages; to install each, use the tidymodels meta-package:

install.packages("tidymodels")

Machine learning fairness

In recent years, high-profile analyses have called attention to many contexts where the use of machine learning deepened inequities in our communities. In late 2022, a group of Posit employees across teams, roles, and technical backgrounds formed a reading group to engage with literature on machine learning fairness, a research field that aims to define what it means for a statistical model to act unfairly and take measures to address that unfairness. We then designed new software functionality and learning resources to help data scientists measure and critique the ways in which the machine learning models they’ve built might disparately impact people affected by that model.

Perhaps the core question that fairness as a research field has tried to address is exactly what a machine learning model acting fairly entails. As a recent primer notes, “[t]he rapid growth of this new field has led to wildly inconsistent motivations, terminology, and notation, presenting a serious challenge for cataloging and comparing definitions” (Mitchell et al. 2021).

Broadly, approaches to fairness provide tooling—whether social or algorithmic—to understand the social implications of utilizing a machine learning model. Different researchers categorize approaches to fairness differently, but work in this area can be loosely summarized as falling into one or more of the following categories: assessment, mitigation, and critique.

• Assessment: Fairness assessment tooling allows practitioners to measure the degree to which a machine learning model acts unfairly given some definition of fairness. The chosen definition of fairness greatly impacts whether a model’s predictions are regarded as fair. While there have been many, many definitions of fairness proposed—a popular tutorial on these approaches compares 21 canonical definitions—most all of them involve simple inequalities based on a small set of conditional probabilities (Narayanan 2018; Mitchell et al. 2021).

• Mitigation: Given a fairness assessment, mitigation approaches reduce the degree to which a machine learning model acts unfairly given some definition of fairness. Making a model more fair according to one metric may make that model less fair according to another. Approaches to mitigation are subject to impossibility theorems, which show that “definitions are not mathematically or morally compatible in general” (Mitchell et al. 2021). That is, there is no way to satisfy many fairness constraints at once unless we live in a world with no inequality to start with. However, more recent studies have shown that near-fairness with respect to several definitions is quite possible (Bell et al. 2023).

• Critique: While approaches to assessment and mitigation seek to reduce complexity and situate notions of fairness in mathematical formalism, sociotechnical critique provides tooling to better understand how mathematical notions of fairness may fail to account for the real-world complexity of social phenomena. Work in this discipline often reveals that, in the process of measuring or addressing unfairness by some definition, methods for fairness assessment and mitigation may actually ignore, necessitate, or introduce unfairness by some other definition.

The work of scoping Posit’s resources for fair machine learning, in large part, involved striking the right balance between tools in these categories and integrating them thoughtfully among our existing functionality. Rather than supporting as many fairness-oriented tools as possible, our goal is to best enable users of our tools to reason well about the fairness-relevant decisions they make throughout the modeling process.

Additions to tidymodels

The most recent set of tidymodels releases include changes that provide support for assessment and critique using the tidymodels framework.

The most recent yardstick release introduces a tool to create fairness metrics with the problem context in mind, as well as some outputs of that tool implementing common fairness metrics. For a higher-level introduction to the concept of a groupwise metric, we’ve also introduced a new package vignette . To see those fairness metrics in action, see this new article on tidymodels.org , a case study using data about GPT detectors.

The most recent tune release integrates support for those fairness metrics from yardstick, allowing users to evaluate fairness criteria across resamples. To demonstrate those features in context, we’ve added another new article on tidymodels.org , modeling hospital readmission for patients with Type I diabetes.

Notably, we haven’t introduced functionality to support mitigation. While a number of methods have proliferated over the years to finetune models to act more fairly with respect to some fairness criteria, each apply only in relatively niche applications with modest experimental results (Agarwal et al. 2018; Mittelstadt, Wachter, and Russell 2023). For now, we believe that, in practice, the efforts of practitioners—and thus our efforts to support them—are better spent engaging with the sociotechnical context of a given modeling problem (Holstein et al. 2019).

We’re excited to support modeling practitioners in fairness-oriented analysis of models and look forward to seeing how these methods are put to work.

References

At the end of 2021, we created a survey to get community input on how we prioritize our projects. The results gave us a good sense of which items people were most interested in. Since then we have completed a number of projects:

• Model fairness metrics were included in yardstick 1.3.0 with tidymodels.org posts coming soon.
• Spatial analysis models and methods led to the creation of spatialsample .
• H2O.ai support was achieved with the creation of agua .
• Better serialization tools are now provided in the bundle package.

Almost everything that respondents prioritized highly last year has either been completed or is currently in progress. Our main focus right now is to wrap up survival analysis, which is being done right now with a series of CRAN releases for the affected packages. Most immediately following these releases, we will be working on postprocessing and supervised feature selection. Beyond that, we’d like to once again ask the community for feedback to help us better prioritize features in the coming year.

Looking toward 2024

Take a look at our survey for next priorities and let us know what you think. There are some items we’ve put “on the menu” but you can write in other items that you are interested in.

The current slate of our possible priorities include:

Sparse tibbles

Many models benefit from having sparse data, both in execution time and memory usage. We can’t take full advantage of this since recipes use tibbles. This project would involve making it so the tibbles used inside of a recipe can hold sparse data. This would not be intended as a general substitute for regular tibbles.

Causal inference interface

While many common causal inference workflows are already possible with tidymodels, a small set of helper functions could greatly ease the experience of causal modeling in the framework. Specifically, these changes would better accommodate a two-stage modeling approach, using predictions from a propensity model to set case weights for an outcome model.

Improve chattr

chattr is an interface to large language models (LLMs). It enables interaction with the model directly from the RStudio IDE. This task would involve fine-tuning it to give better results when used for tidymodels tasks.

Cost-sensitive learning API

This feature is another solution for severe class imbalances. The main part of this task is making our approaches to this uniform across models.

Expand models for stacking ensembles

As of now, the stacks package only supports combining the predictions of member models using a regularized linear model. We could extend the package to allow for combining predictions using any modeling workflow .

Extend support for spatial ML

spatialsample introduced a number of spatial resampling methods to tidymodels. More comprehensive support for spatial ML would involve better integrating spatial metrics into the framework and introducing support for new spatial model types.

Ordinal regression extension package

Ordinal regression models are specific to classification tasks with a natural ordering to the outcome categories (e.g., low, medium, high, etc.). We could add support for modeling this type of data in a parsnip extension package.

Check out our survey and tell us what your priorities are!

The workshop was designed for those who want to take their R Markdown skills and expertise and apply them in Quarto, the next generation of R Markdown. Participants learned how to apply their reproducible authoring skills to the Quarto format and about new tools and workflows for authoring with Quarto in RStudio. The workshop covered creating static documents and presentations, building websites, and writing blogs and books. Finally, participants learned various ways to deploy and publish their Quarto projects on the web.

Home pages and links to source code for each of the six workshops are listed below:

Nebraska Chapter Omaha, Nebraska April 28, 2023 mine.quarto.pub/quarto-asa-nebraska Source
Oregon Chapter Portland, Oregon June 10, 2023 andrew.quarto.pub/oregon-asa Source
Alaska Chapter Anchorage, Alaska June 20, 2023 andrew.quarto.pub/alaska-asa/ Source
Ohio Chapter Virtual Workshop on Zoom August 18, 2023 andrew.quarto.pub/ohio-as Source
Boston Chapter Virtual Workshop on Zoom September 20, 2023 andrew.quarto.pub/boston-asa Source
Mid-Tennessee Chapter Nashville, Tennessee October 20, 2023 mine.quarto.pub/quarto-asa-nashville Source

One of the Quarto features we leveraged in organizing these materials is that you can publish to different QuartoPub URLs from the same repository with quarto publish. After each workshop, we created a release on GitHub to take a snapshot of the materials for that workshop, and for the subsequent workshop, we made edits to the materials on the main branch and published them to a new URL.

The source code for everything can be found at github.com/asa-quarto/website . Also in the GitHub organization is a repo containing the “your turn” exercises for the workshops: github.com/asa-quarto/exercises .

All materials are released with Creative Commons Attribution-ShareAlike 4.0 International license. If you are teaching a Quarto workshop, feel free to reuse any and all of these materials. And if you’re learning Quarto, you might find it helpful to follow along with any of the workshops listed above.

Happy learning and happy teaching!