+
+Email [Pengyin Shan](mailto:pengyins@illinois.edu) for any questions!
+
+### **Community Calls**
+
+
+
+
+
+Our next meeting is scheduled for Thursday, July 9, 2026, 12:00PM EST.
+We hope to see you there!
+
+------------------------------------------------------------------------
+
+## 👀 Interesting Events and Opportunities 👀
+
+
+
+{% assign today = "now" | date: "%Y-%m-%d" %}
+{% for opp in site.data.newsletter-events-opportunities %}
+{% assign expires = opp.expires | date: "%Y-%m-%d" %}
+{% if opp.type == "opportunity" and expires >= today %}
+{% include opportunity-box.html
+ title=opp.title
+ when=opp.when
+ where=opp.where
+ preamble=opp.preamble
+ links=opp.links
+%}
+{% endif %}
+{% endfor %}
+
+{% for event in site.data.newsletter-events-opportunities %}
+{% assign expires_formatted = event.expires | date: "%Y-%m-%d" %}
+{% if expires_formatted >= today %}
+{% if event.type == "event" %}
+{% include event-box.html
+ title=event.title
+ when=event.when
+ where=event.where
+ preamble=event.preamble
+ links=event.links
+%}
+{% endif %}
+{% endif %}
+{% endfor %}
+
+Have an event or opportunity you want to promote? Reach out on Slack in
+the `#newsletters` channel!
+
+------------------------------------------------------------------------
+
+## 📚 Featured Reads, Videos, and Podcasts 📚
+
+
+
+{% assign refs = site.data.newsletter_bib_yml.references
+ | where_exp: "r", "r.annote contains 'Read_Status: To Read'" %}
+
+{% assign professional = refs | where: "type", "article-journal" %}
+
+{% if professional.size > 0 %}
+### 📑 Recent Publications
+{% for ref in professional %}
+{% include citation-publication.html ref=ref %}
+{% endfor %}
+{% endif %}
+
+{% assign podcasts = refs | where: "type", "song" %}
+
+{% if podcasts.size > 0 %}
+### 🎧 Podcast Episodes
+{% for ref in podcasts %}
+{% include citation-podcast.html ref=ref %}
+{% endfor %}
+{% endif %}
+
+{% assign other = refs | where: "type", "webpage" %}
+
+{% if other.size > 0 %}
+### 📇 Blog Posts, Videos, & Other Reads
+{% for ref in other %}
+{% include citation.html ref=ref %}
+{% endfor %}
+{% endif %}
+
+Did you read something interesting this week? Want to share your own
+publications in the community? Reach out on Slack in the `#newsletters`
+channel!
+
+------------------------------------------------------------------------
+
+## 🏃 Get Involved! 🏃
+
+
+
+US-RSE Working Groups:
+
+{% assign wgs = site.data.menus["working-groups"][0].items %}
+
+
+------------------------------------------------------------------------
+
+## 🧑💼 Recent Job Postings 🧑💼
+
+
+
+{% assign today = 'now' | date: "%Y-%m-%d" %}
+
+{% for job in site.data.jobs %}
+ {% assign expires_formatted = job.expires | date: "%Y-%m-%d" %}
+ {% if expires_formatted >= today %}
+ -
+ {{ job.name }}
+ 📍 {{ job.location }}
+ 🗓️ Posted: {{ job.posted }} | Expires: {{ job.expires }}
+
+ {% endif %}
+{% endfor %}
+
+
+### Other Job Boards
+
+
+{% for board in site.data.job-boards.boards %}
+ - {{ board.name }}
+{% endfor %}
+
+
+You can learn more about job boards in the `#jobs` Slack channel!
+
+------------------------------------------------------------------------
+
+**This newsletter is a joint effort of members of the US-RSE
+Association.**
+
+© US-RSE • 2021–{{ 'now' | date: "%Y" }} • US-RSE is a fiscally sponsored project of [Community Initiatives](http://communityin.org/)
+
+[Email](mailto:contact@us-rse.org) [Mastodon](https://fosstodon.org/@us_rse) [Twitter](https://twitter.com/us_rse) [YouTube](https://youtube.com/@us_rse) [LinkedIn](https://linkedin.com/company/us-rse/) [GitHub](https://github.com/USRSE)
diff --git a/_posts/newsletters/quarto/_headline.md b/_posts/newsletters/quarto/_headline.md
index d97c64bab..48f7586d2 100644
--- a/_posts/newsletters/quarto/_headline.md
+++ b/_posts/newsletters/quarto/_headline.md
@@ -1,62 +1,108 @@
-## 🤩 Wait a Minute, I'm an RSE, I Know How to Do That! 🤩
+## 🤔 Arrestive Curiosity & RSEs: How to Turn the Shiny Toy Syndrome Bug into a Feature 🤔
-*I know how to do that!*
-
-It is one of the most rewarding thoughts you can have as a research software engineer: that moment when you notice a colleague, PI, collaborator, or student struggling with a software problem and realize you can help.
-
-Not because they are unmotivated. Not because they are bad scientists. But because things are not working, not moving quickly enough, or not being recognized for what they are: software problems that can be solved with the right tools, techniques, and expertise. Maybe the scientist is looking toward industry and thinking, "I wish we could move as quickly as Google, Facebook, or Microsoft." Or, more recently, "I wish we could figure out how to really use all this LLM stuff." Ever persistent, the scientist keeps chasing their research questions. They want to discover the next big thing in their field. They want to make an impact. But because their workflow was essentially written in 2012, and because they do not have the time, support, or expertise to modernize it, they are stuck moving at the pace of 2012.
-
-And as RSEs, we get it! Code can be fragile — and scary. If a new student or postdoc touches it, they might break it. If the code breaks, so might every paper, grant, and project built on top of it. When was the last time it was updated? Months ago? Years ago? So the scientist does not touch it. They treat it like a Rube Goldberg machine: they know it works, but they no longer remember how. At this point, they are too afraid to find out.
-
-As RSEs, we see this...and get excited.
-
-Because we know how to help. 🥹
-
-I first came across the term "RSE" in the wonderfully cute and informative 2019 YouTube video, [The Story of the Research Engineer](https://www.youtube.com/watch?v=trAfA9VWLTQ), and I instantly fell in love with the idea. Here was a name for the squeaky wheel that gets the grease: the person who helps scientists get unstuck, move faster, and work more sustainably. But then as now, the field was young. There was not much consensus about what an RSE was, where they belonged, or how institutions should support them.
-
-The term itself emerged in the UK [in 2012](https://www.software.ac.uk/blog/not-so-brief-history-research-software-engineers-0), after a group of researchers and software practitioners began formalizing a role that many people were already doing but few institutions knew how to recognize. Since then, definitions have been proposed, refined, and debated.
-
-Ian Cosden, one of our newsletter editors and Director of *Research Software Engineering for Computational & Data Science* at Princeton, defines the role partly by what it is not. An RSE, he argues, is not simply a researcher, not simply a facilitator, and not simply a pure software engineer. The role lives in the productive space between those identities.
-
-
-
-
-
-
-
-Goth et al. ([2025](https://f1000research.com/articles/13-1429)) offer one recent attempt to concretize the foundational competencies and responsibilities of an RSE, including software development, building and distributing software assets, understanding the research lifecycle, and supporting reproducible, sustainable research. [Vanessa Sochat's EasyBuild talk](https://www.youtube.com/watch?v=FB2yV8TNnSw), on the other hand, emphasizes just how broad this space can be: among roughly 400 people surveyed who identified themselves to be working on "research software" in some capacity, there were more than *190 unique job titles*. That degree of diversity can be both a strength and a challenge. It shows how widely research software work appears across institutions, but it also explains why the role can be so difficult to define, hire for, promote, and reward. Another one of our US-RSE members, Dan Katz, proposes a 3-dimensional schematic
-to isolate the Super RSE role who commands "a superset of the responsibilities of the traditional RSE role, combining both service and the RSE’s own research."
-
-
-
-
-
-By identifying this RSE unicorn, Katz highlights the fact that as we define
-the breadth of the scope of the RSE, we also need to think about its
-potentially necessary boundaries.
-
-In a 2022 [career Q&A in *Nature*](https://www.nature.com/articles/d41586-022-01516-2), Paul Richmond predicted that RSEs could become equals in the academic environment if they receive proper recognition for their contributions. James Schloss, in his [YouTube talk](https://www.youtube.com/watch?v=t2BjZ5hSjHo) highlights some of the barriers still standing in the way: the publication economy, academic resistance to software engineering best practices, and the difficulty of competing with industry salaries for people with similar technical expertise. In fact, one of my very first suggestions for newsletter topics was to discuss the definition of the title "Research Software Engineer" itself, and I was told very firmly to avoid the topic as much as possible — not because it was inflammatory, but because it remains a particularly sensitive topic. While many are strongly attached to the name for its truthiness, just as many others are more concerned with defining the tasks, responsibilities, and competencies of the role, regardless of what it is called, because funding sources will pay a great deal of attention to those details.
-
-But friends, there is hope. 🌱
-
-Just as a small group of concerned scientists and software practitioners began with an idea, a conversation, and a Google Group, we can continue making the role visible at our own institutions. This can be through formal titles, clearer career paths, better credit, stronger communities of practice, or simply naming the work when we see it as we help research software engineering become easier to recognize and harder to ignore. This week, celebrate yourself by encouraging your colleagues, coworkers, PIs, and students to **make this role visible**. Look around. We are once again watching technology change the fabric of research itself. Rigorous science, and the software that powers it, cannot afford to be left behind. Now more than ever, research needs talented, driven, curious technology specialists who can ask new questions, solve impossible bugs, push compute clusters to their limits, and preserve the code — and the science — that so many people depend on.
-
-Our Executive Director had this to say about the importance of this community:
-
-"Reaching more than 4,000 members is not just a milestone in numbers - it reflects a growing
-community of people who care deeply about advancing research through software, collaboration, and
-support for one another. As Executive Director, I am incredibly grateful to be part of this community
-and inspired every day by the generosity, expertise, and passion our members bring to US-RSE. Thank
-you for helping build a place where research software engineers can truly belong."
-
-> [Sandra](https://us-rse.org/about/staff/)
-
-This month, we thank the scrappy and passionate group of researchers who helped crystallize the idea of the Research Software Engineer, [one quiet afternoon in Oxford, UK, in 2012](https://www.pure.ed.ac.uk/ws/portalfiles/portal/65195747/DR2012_12_1_.pdf). And the next time you notice a colleague struggling with a technical problem, be the RSE on their shoulder. Gently remind them:
-
-*Hey, I know how to do that.*
-
-> You are braver than you believe, stronger than you seem, and smarter than you think. A. A. Milne, *Winnie the Pooh*
+This month, I had the pleasure of meeting some fellow R users at the Boston R User Group meetup,
+where I can say I finally felt safe opening a conversation with a hot take like, "R is the best," knowing
+it would likely not spark a flame war. I'm sure many of you having read that sentence
+are already compiling the several counterarguments in your head, mashing away your response
+in a text editor, choosing all your best and worst use cases as examples and calling on the
+greats of your respective community to back you up. But this discussion is actually not about flame wars;
+in fact, as I'm sure you've experienced, we as technologists often care less about what tool
+is objectively best, and more about what tool is best for us, our project, and our team.
+
+And while this can sound like a freeing stance on tooling in general, it leaves us with
+an acute conundrum: how do we know when to _switch_ tools? When do we know that the tool we're
+using is no longer best for us, and that we should switch to something else? As computing becomes
+more accessible and capable, more individuals are building tools that avow to _finally_ and
+_decisively_ solve the problem of [insert other tools' shortcomings here]. Indeed, whether it
+was Markdown's attempt to become the de facto standard for writing on the web
+Anaconda claim to be the last word in environment management for data science, or the
+eternal paradox of Apple's latest OS somehow always having "the best feature, ever,"
+technology is rife with shiny toys that promise to solve all our problems. On the one hand, it can be
+incredibly overwhelming trying to keep up with the latest and greatest, and on the other,
+you could easily risk missing out on a tool that could be a game changer for you and your team if
+you don't branch out and experiment from time to time[1^].
+
+This decision fatigue can end up being a significant job hazard for people who work with technology.
+What if your organization is one of the unfortunate few that decided to go all-in on Skype[2^],
+or what if you can't ship a new product or publish a paper because your team has not ported
+over its legacy libraries to Python 3 yet? As RSEs, part of our responsibility is to help
+scientific teams navigate this ever-changing landscape of tools and technologies, and it can
+be very tricky to draw the line between productive experimentation and [shiny toy syndrome](https://nesslabs.com/shiny-toy-syndrome).
+How does one justify several afternoons' worth of tinkering, only to come to the conclusion
+that the new tool actually _doesn't_ do what it says on the box - or at least, not to your satisfaction —
+and continue to be trusted with the responsibility of guiding your team's technological vision?
+
+But as I thought about this more, I realized that this activity of tinkering and experimenting
+with new tools is actually a critical part of our job as RSEs, and that we can turn this "bug"
+of shiny toy syndrome into a "feature" of arrestive curiosity. Arrestive curiosity is the
+tendency to be so curious about new tools and technologies that you cannot move forward with your
+own work until you've proven a new tool is either better or worse for you than the one
+you're currently using[3^]. If you've ever been up late at night trying to get a VSCode extension to
+run without error, trying to figure out why a new library can't just install on your system,
+or drawing out your ultimate note-taking entourage of apps for never losing a thought, I see you!
+This kind of curiosity can be a disastrous time sink — but it can also be a powerful way to
+stay on top of the latest and greatest, and to make sure you're using the best tools for you and your team.
+
+So, how do we cultivate arrestive curiosity without falling into the trap of
+time-wasting? Having wrestled with this for several years, I think I can provide a few
+considerations that have helped me strike this balance:
+
+1. _Stop being distracted by the perfect tool until you know what perfect is supposed to look like._
+Before seriously investigating a new tool, write down exactly
+what problem or need you think it is trying to solve for you. In the simple process of
+articulating this, you may find that your existing workflow just needs some refinement,
+or a simple adjustment or reframing of the problem. 95% of the time, my tinkering does not
+pass this step.
+
+2. _Get comfortable with the discomfort of your current tools._ If you've successfully passed
+the first step, then you know for a fact that your current workflow needs are not being met,
+and a new tool — or repurposing an old one — is likely the solution. But before you dive into the new tool,
+now is the time to measure the discomfort of your current workflow. How much time are you losing to this
+problem? How much mental energy are you spending on it? How much is it costing your team in
+productivity and morale? If the cost of your current workflow is not high enough, then it may
+not be worth the time and effort to switch to a new tool. If you can tolerate the discomfort, then the tool search ends here.
+
+3. _Refine to absurdum._ If you are still convinced that something is missing, then it is time to start
+looking for what is missing. Surely someone has felt this acute pain, right? The internet is a vast place,
+and there are several billion of us using it at any given time. It's more than likely that someone,
+somewhere, has been in the exact position you're in, with an install that is too slow, a link that
+doesn't work, or a workflow that is too clunky and just missing that, _secret something_. Go out into dark
+corners of the second, third, and fourth pages of Google search, ask around on Reddit and Facebook groups, or
+find forums and communities that are relevant to the problem space. Surely **someone** has faced this problem, too?
+
+4. If the solution is identified, use it. If not, build it. By this point, if you have found a
+niche problem that 1) arrests your productivity, 2) causes measurable discomfort, and 3) has not been
+solved by anyone else, then this is a problem worth solving. In fact, as an RSE, this is the _perfect_
+problem to have, because it is within this narrow gap between your vision and the status quo that
+you can actually make valuable impact to your team. If you can't or don't want to build the solution yourself,
+one of two things must be true: either the problem is not worth solving, or you are _not yet_ the right person to solve it.
+
+In my experience, the really interesting Research Software Engineering is what happens when as an
+engineer I have become _obsessed_ with a particular technological blocker to the success of my or my colleagues' scientific endeavors.
+
+It is the moment we look at the scientific engine and say, "I know we _could_ just use [X Tool] to write
+this part of the paper, but I just can't accept that this is the best way to do it. I simply can't. There
+_must_ be a better way."
+
+This is the "arrestive," part of "arrestive curiosity" — the part that keeps you up at night,
+ceases you in your tracks every time you think about it, and continues to consume all of your mental
+energy until you have either found a solution or come to terms with the fact that there is no solution.
+
+And if you ask me, that tendency to be obsessed with finding the best way to do science is what makes a good
+RSE a _great_ RSE. So, the next time you find yourself in the throes of shiny toy syndrome, try to
+channel that energy into arrestive curiosity using the flowchart I outlined above, and see where it takes you.
+You might just find that the perfect tool was right in front of you all along, or you might end up building
+something that changes the game for you, your team, and perhaps even the science itself.
+
+[1^]: In fact, at this UseR Boston meetup, we ourselves had a hard time rectifying our excitement
+vs. hesitation around all things AI in the R world. We could barely come to a consensus on
+whether we could be convinced to switch over to the new native pipe `|>` or stick with the beloved
+`magrittr` pipe `%>%` that we've been using for years, all the while doing our best "old man yells at cloud" impression.
+Spoiler alert: I'm yelling at the cloud.
+[2^]: Shout out to everyone currently being held hostage by their CTO's contract with Microsoft and having to wake
+up every morning to the sound of a Teams notification. We see you, and we feel your pain.
+[3^]: Yes, I just came up with it. No, I will not be answering questions.
------------------------------------------------------------------------
\ No newline at end of file
diff --git a/_posts/newsletters/quarto/_news.md b/_posts/newsletters/quarto/_news.md
index 7ca41c102..27912b247 100644
--- a/_posts/newsletters/quarto/_news.md
+++ b/_posts/newsletters/quarto/_news.md
@@ -2,6 +2,73 @@
+### The Whole Person: Pride and Belonging in US-RSE
+
+Pride Month is both a celebration and a moment for reflection for the communities
+we are part of. As the chairs of the DEI Working Group, we welcome everyone
+to celebrate Pride Month with the US‑RSE community this June and beyond.
+We also want to take a moment to reflect on what Pride means to me and how it shapes
+how we think about belonging in our professional communities.
+
+US‑RSE is a community built around shared skills, interests, and goals centered
+on advancing research through software engineering. While that core set of
+interests brings us together, we are also a collection of individuals who work
+across different research domains and parts of the software engineering lifecycle.
+Each person brings unique strengths and perspectives.
+
+A mix of viewpoints helps teams generate stronger ideas and advance research. That
+kind of collaboration works best when people feel a sense of belonging.
+
+At the same time, we don’t show up to these communities as just
+“RSEs.” Each of us brings life experiences, preferences, and unique quirks. You
+can’t interact with just the “software engineer” side of someone. You interact with
+the whole person, which means accepting them as they are.
+
+That’s where belonging comes from. It’s not just about being part of a
+group with shared interests. It’s about being accepted as you are.Creating that
+kind of belonging can be challenging in practice, especially
+when building trust with people who have experienced bias, exclusion, or worse.
+
+That’s why small actions matter. Sharing pronouns, using gender‑neutral
+language, and taking the time to learn about the people around us can make
+a real difference. They signal that people are seen, respected, and
+welcome as part of the community.
+
+For us, Pride is a reminder that this kind of belonging does not happen
+by accident. It is something we create together through everyday choices.
+
+Pride means different things to different people. To reflect that range
+of experiences, we invite members of the US‑RSE community to share what Pride
+means to them and how they think about belonging in their work.
+
+What does Pride mean to you? We’d love to hear your perspective. Feel free to
+join the conversation on Slack or share on social media using the hashtag `#RSEPride`.
+
+##### Community Contributions
+
+> Research software often involves intensely multidisciplinary collaboration,
+> and, depending on the size of a team, may require the ability to liaise
+> between domains, technical-side, business-side, etc. and advocate whether
+> it's for data integrity processes or for underweighted voices. In my mind
+> this relational communication and openness is very prosocial and
+> qualitatively close to what Pride is all about; I think it's why I feel at
+> home in research software and the surrounding communities.\n
+> – Michael P. Pascale
+
+> I actually did not grow up playing with computers. I always was tech
+> savvy, but never imagined myself opening a terminal or writing code.
+> So when I found myself engaging with technology in research, I was
+> very intimidated, often suffixing all of my conversations with, "but
+> I don't know anything about this stuff." That feeling of imposter
+> syndrome went away when I joined the RSE community, and I owe my
+> career success to the culture of support and encouragement that I found here.
+> Celebrating Pride Month with the LGBTQ+ community every year
+> is a reminder of how unconditional acceptance and support enables people
+> to self-actualize and thrive. I stand with my LGBTQ+ allies in
+> celebrating them and advocating for their space in our world!\n
+> - Tinashe M. Tapera
+
+
### **Community Shoutouts**
@@ -22,19 +89,24 @@ consecutive year a Chameleon user has taken home this honor!
Read the announcement [here](https://blog.chameleoncloud.org/posts/sc25-best-reproducibility-advancement-award/).
-### RSE's with a New York State of Mind... 🗽
+> Did you know that we have a community Code of Conduct? Anyone is able to view it in the
+`#code_of_conduct` Slack channel, under `Files`!
-The NYC Regional Group recently met up for their inaugural
-in-person hangout! Special thanks to Roger Ferger for spearheading the event!
-
- 
-
+### In Memoriam
-As an added bonus, the group also now has a dedicated page on the US-RSE website! Check it out [here](https://us-rse.org/ag/rg-nyc/) to learn more about the group and how to get involved.
+We mourn the loss of a dear friend and colleague, Cleve Moler, who passed away on May 20, 2026, at the age of 86 at his home
+surrounded by his family. Cleve was chief mathematician and cofounder of MathWorks and the author of the first version of MATLAB.
+Please join us in remembering their contributions to science and engineering by reading Mathworks official announcement [here](https://www.mathworks.com/company/aboutus/founders/clevemoler.html).
+
+## Community Spotlight
+
+🌱 Our community is full of people doing fascinating research and software work, and we want to put a face to it. Starting this month, we'll be featuring a group of different members in a regular spotlight: what they work on, a tool they can't live without, and how they found their way into RSE work.
+
+We'd love to feature YOU. It takes about 5 minutes to fill out, and nothing gets posted without your okay: [https://forms.gle/dXqVsHKiHnot2u449](https://forms.gle/dXqVsHKiHnot2u449)
+
+Email [Pengyin Shan](mailto:pengyins@illinois.edu) for any questions!
-> Did you know that we have a community Code of Conduct? Anyone is able to view it in the
-`#code_of_conduct` Slack channel, under `Files`!
### **Community Calls**
diff --git a/_posts/newsletters/quarto/_preamble.md b/_posts/newsletters/quarto/_preamble.md
index fe220c56e..252a230b5 100644
--- a/_posts/newsletters/quarto/_preamble.md
+++ b/_posts/newsletters/quarto/_preamble.md
@@ -1,10 +1,6 @@
-Well, actually, there are thousands — **four thousand and counting**, to be exact! That's
-right, as of April 2026, US-RSE has grown to over 4,000 registered members! That means if you
-tried to count every member one by one, it would take you [over an hour](https://numbermatics.com/n/4000/) to
-count them all. 4000 is also a Harshad number, which means it's divisible by the sum of its digits (4 + 0 + 0 + 0
-= 4). So, in a way, our membership is mathematically harmonious! Also, did you know
-that the recent Artemis mission flew approximately [4000 miles above the moon's surface](https://science.nasa.gov/solar-system/skywatching/night-sky-network/night-sky-network-celebrates-artemis-ii/)?
-Okay, you get the point — that's a lot of RSEs, and we're thrilled to have each and every one of you as part of our community.
+First of all, Happy Pride Month 🌈, and Happy Juneteenth 🎉! We hope you are all having a wonderful summer celebrating the diversity and resilience of our communities.
-So grab a beverage, sit back, and dive in to the latest news and updates from your
-4000-member-strong community of research software engineers!
\ No newline at end of file
+It's been another busy month for US-RSE, as conference planning continues to ramp up,
+membership continues to grow, and the organization continues to expand its offerings and
+impact to the research software community. In this issue, we'll discuss shiny toy syndrome in
+technology, celebrate the LGBTQ+ community, and share all the latest and greatest news from US-RSE.
\ No newline at end of file
diff --git a/_posts/newsletters/quarto/_reads.md b/_posts/newsletters/quarto/_reads.md
index 582201ef4..43b6a36a0 100644
--- a/_posts/newsletters/quarto/_reads.md
+++ b/_posts/newsletters/quarto/_reads.md
@@ -15,7 +15,7 @@
{% endfor %}
{% endif %}
-{% assign podcasts = refs | where: "type", "motion_picture" %}
+{% assign podcasts = refs | where: "type", "song" %}
{% if podcasts.size > 0 %}
### 🎧 Podcast Episodes
diff --git a/_posts/newsletters/quarto/params.yml b/_posts/newsletters/quarto/params.yml
index fa8bca96b..c0abd38b2 100644
--- a/_posts/newsletters/quarto/params.yml
+++ b/_posts/newsletters/quarto/params.yml
@@ -1,24 +1,24 @@
layout: post
-title: "US-RSE May 2026 Newsletter"
-subtitle: "🙌 There Are Dozens of Us, DOZENS! 🙌"
+title: "US-RSE June 2026 Newsletter"
+subtitle: "🤔 Arrestive Curiosity & RSEs: How to Turn the Shiny Toy Syndrome Bug into a Feature 🤔"
category: newsletter
-tags: [newsletter, May]
-date: 2026-05-20 00:00:00 -0400
+tags: [newsletter, June]
+date: 2026-06-15 00:00:00 -0400
author: "Tinashe M. Tapera (Author & Editor), Sandra Gesing (Editor), Ian Cosden (Editor)"
-image: "/assets/img/newsletter-202605/us-rse_4k_members.png"
-img_alttext: "Colourful poster with the words \"Celebrating 4,000+ Member Milestone\" and a progression of trees growing from a seedling to a full tree, with the number 4011 prominently displayed."
-next_meeting_date: Friday, June 12, 2026, 12:00PM EST
+image: "/assets/img/newsletter-202606/tasha-kostyuk-TtMKq3lJm-U-unsplash.jpg" #Done
+img_alttext: "A railway traffic controller with his back to the camera, looking at several screens with train camera feed and data." #Done
+next_meeting_date: Thursday, July 9, 2026, 12:00PM EST #Done
sections:
- preamble: true # done
- headline: true # done
- conference: true # done
- execupdate: false # done
- scupdate: false # yay!
- orgmember: true # done
- communityfunds: false # no changes, check back in june
- news: true # add community call summary
- events: true
- reads: true
+ preamble: true #Done
+ headline: true #Done
+ conference: true #Done
+ execupdate: false #TODO
+ scupdate: false #TODO
+ orgmember: true #TODO
+ communityfunds: false #TODO
+ news: true #TODO
+ events: true #TODO
+ reads: true #TODO
involved: true
jobs: true
diff --git a/_posts/newsletters/quarto/template.md b/_posts/newsletters/quarto/template.md
index 4cd7e5bac..32ea6934f 100644
--- a/_posts/newsletters/quarto/template.md
+++ b/_posts/newsletters/quarto/template.md
@@ -1,11 +1,11 @@
-# US-RSE May 2026 Newsletter
+# US-RSE June 2026 Newsletter
Tinashe M. Tapera (Author & Editor), Sandra Gesing (Editor), Ian Cosden
(Editor)
-2026-05-20
+2026-06-15
-- [1 🤩 Wait a Minute, I’m an
- RSE, I Know How to Do That!
- 🤩](#star_struck-wait-a-minute-im-an-rse-i-know-how-to-do-that-star_struck)
+- [1 🤔 Arrestive Curiosity &
+ RSEs: How to Turn the Shiny Toy Syndrome Bug into a Feature
+ 🤔](#thinking-arrestive-curiosity--rses-how-to-turn-the-shiny-toy-syndrome-bug-into-a-feature-thinking)
- [2 📣 Mark Your Calendars for
USRSE’26! 📣](#mega-mark-your-calendars-for-usrse26-mega)
- [3 🤝 Organizational Founding
@@ -13,192 +13,184 @@ Tinashe M. Tapera (Author & Editor), Sandra Gesing (Editor), Ian Cosden
🤝](#handshake-organizational-founding-membership-handshake)
- [4 🗞️ Community News
🗞️](#newspaper_roll-community-news-newspaper_roll)
-- [5 👀 Interesting Events and
+- [5 Community
+ Spotlight](#community-spotlight)
+- [6 👀 Interesting Events and
Opportunities 👀](#eyes-interesting-events-and-opportunities-eyes)
-- [6 📚 Featured Reads, Videos,
+- [7 📚 Featured Reads, Videos,
and Podcasts 📚](#books-featured-reads-videos-and-podcasts-books)
-- [7 🏃 Get Involved!
+- [8 🏃 Get Involved!
🏃](#running-get-involved-running)
-- [8 🧑💼 Recent Job Postings
+- [9 🧑💼 Recent Job Postings
🧑💼](#office_worker-recent-job-postings-office_worker)
-Well, actually, there are thousands — **four thousand and counting**, to
-be exact! That’s right, as of April 2026, US-RSE has grown to over 4,000
-registered members! That means if you tried to count every member one by
-one, it would take you [over an hour](https://numbermatics.com/n/4000/)
-to count them all. 4000 is also a Harshad number, which means it’s
-divisible by the sum of its digits (4 + 0 + 0 + 0 = 4). So, in a way,
-our membership is mathematically harmonious! Also, did you know that the
-recent Artemis mission flew approximately [4000 miles above the moon’s
-surface](https://science.nasa.gov/solar-system/skywatching/night-sky-network/night-sky-network-celebrates-artemis-ii/)?
-Okay, you get the point — that’s a lot of RSEs, and we’re thrilled to
-have each and every one of you as part of our community.
-
-So grab a beverage, sit back, and dive in to the latest news and updates
-from your 4000-member-strong community of research software engineers!
+First of all, Happy Pride Month 🌈, and Happy Juneteenth 🎉! We hope you
+are all having a wonderful summer celebrating the diversity and
+resilience of our communities.
+
+It’s been another busy month for US-RSE, as conference planning
+continues to ramp up, membership continues to grow, and the organization
+continues to expand its offerings and impact to the research software
+community. In this issue, we’ll discuss shiny toy syndrome in
+technology, celebrate the LGBTQ+ community, and share all the latest and
+greatest news from US-RSE.
- 
+ 
In this issue:
------------------------------------------------------------------------
-## 🤩 Wait a Minute, I’m an RSE, I Know How to Do That! 🤩
+## 🤔 Arrestive Curiosity & RSEs: How to Turn the Shiny Toy Syndrome Bug into a Feature 🤔
-*I know how to do that!*
-
-It is one of the most rewarding thoughts you can have as a research
-software engineer: that moment when you notice a colleague, PI,
-collaborator, or student struggling with a software problem and realize
-you can help.
-
-Not because they are unmotivated. Not because they are bad scientists.
-But because things are not working, not moving quickly enough, or not
-being recognized for what they are: software problems that can be solved
-with the right tools, techniques, and expertise. Maybe the scientist is
-looking toward industry and thinking, “I wish we could move as quickly
-as Google, Facebook, or Microsoft.” Or, more recently, “I wish we could
-figure out how to really use all this LLM stuff.” Ever persistent, the
-scientist keeps chasing their research questions. They want to discover
-the next big thing in their field. They want to make an impact. But
-because their workflow was essentially written in 2012, and because they
-do not have the time, support, or expertise to modernize it, they are
-stuck moving at the pace of 2012.
-
-And as RSEs, we get it! Code can be fragile — and scary. If a new
-student or postdoc touches it, they might break it. If the code breaks,
-so might every paper, grant, and project built on top of it. When was
-the last time it was updated? Months ago? Years ago? So the scientist
-does not touch it. They treat it like a Rube Goldberg machine: they know
-it works, but they no longer remember how. At this point, they are too
-afraid to find out.
-
-As RSEs, we see this…and get excited.
-
-Because we know how to help. 🥹
-
-I first came across the term “RSE” in the wonderfully cute and
-informative 2019 YouTube video, [The Story of the Research
-Engineer](https://www.youtube.com/watch?v=trAfA9VWLTQ), and I instantly
-fell in love with the idea. Here was a name for the squeaky wheel that
-gets the grease: the person who helps scientists get unstuck, move
-faster, and work more sustainably. But then as now, the field was young.
-There was not much consensus about what an RSE was, where they belonged,
-or how institutions should support them.
-
-The term itself emerged in the UK [in
-2012](https://www.software.ac.uk/blog/not-so-brief-history-research-software-engineers-0),
-after a group of researchers and software practitioners began
-formalizing a role that many people were already doing but few
-institutions knew how to recognize. Since then, definitions have been
-proposed, refined, and debated.
-
-Ian Cosden, one of our newsletter editors and Director of *Research
-Software Engineering for Computational & Data Science* at Princeton,
-defines the role partly by what it is not. An RSE, he argues, is not
-simply a researcher, not simply a facilitator, and not simply a pure
-software engineer. The role lives in the productive space between those
-identities.
-
-
-
-
-
-
-
-Goth et al. ([2025](https://f1000research.com/articles/13-1429)) offer
-one recent attempt to concretize the foundational competencies and
-responsibilities of an RSE, including software development, building and
-distributing software assets, understanding the research lifecycle, and
-supporting reproducible, sustainable research. [Vanessa Sochat’s
-EasyBuild talk](https://www.youtube.com/watch?v=FB2yV8TNnSw), on the
-other hand, emphasizes just how broad this space can be: among roughly
-400 people surveyed who identified themselves to be working on “research
-software” in some capacity, there were more than *190 unique job
-titles*. That degree of diversity can be both a strength and a
-challenge. It shows how widely research software work appears across
-institutions, but it also explains why the role can be so difficult to
-define, hire for, promote, and reward. Another one of our US-RSE
-members, Dan Katz, proposes a 3-dimensional schematic to isolate the
-Super RSE role who commands “a superset of the responsibilities of the
-traditional RSE role, combining both service and the RSE’s own
-research.”
-
-
-
-
-
-
-By identifying this RSE unicorn, Katz highlights the fact that as we
-define the breadth of the scope of the RSE, we also need to think about
-its potentially necessary boundaries.
-
-In a 2022 [career Q&A in
-*Nature*](https://www.nature.com/articles/d41586-022-01516-2), Paul
-Richmond predicted that RSEs could become equals in the academic
-environment if they receive proper recognition for their contributions.
-James Schloss, in his [YouTube
-talk](https://www.youtube.com/watch?v=t2BjZ5hSjHo) highlights some of
-the barriers still standing in the way: the publication economy,
-academic resistance to software engineering best practices, and the
-difficulty of competing with industry salaries for people with similar
-technical expertise. In fact, one of my very first suggestions for
-newsletter topics was to discuss the definition of the title “Research
-Software Engineer” itself, and I was told very firmly to avoid the topic
-as much as possible — not because it was inflammatory, but because it
-remains a particularly sensitive topic. While many are strongly attached
-to the name for its truthiness, just as many others are more concerned
-with defining the tasks, responsibilities, and competencies of the role,
-regardless of what it is called, because funding sources will pay a
-great deal of attention to those details.
-
-But friends, there is hope. 🌱
-
-Just as a small group of concerned scientists and software practitioners
-began with an idea, a conversation, and a Google Group, we can continue
-making the role visible at our own institutions. This can be through
-formal titles, clearer career paths, better credit, stronger communities
-of practice, or simply naming the work when we see it as we help
-research software engineering become easier to recognize and harder to
-ignore. This week, celebrate yourself by encouraging your colleagues,
-coworkers, PIs, and students to **make this role visible**. Look around.
-We are once again watching technology change the fabric of research
-itself. Rigorous science, and the software that powers it, cannot afford
-to be left behind. Now more than ever, research needs talented, driven,
-curious technology specialists who can ask new questions, solve
-impossible bugs, push compute clusters to their limits, and preserve the
-code — and the science — that so many people depend on.
-
-Our Executive Director had this to say about the importance of this
-community:
-
-“Reaching more than 4,000 members is not just a milestone in numbers -
-it reflects a growing community of people who care deeply about
-advancing research through software, collaboration, and support for one
-another. As Executive Director, I am incredibly grateful to be part of
-this community and inspired every day by the generosity, expertise, and
-passion our members bring to US-RSE. Thank you for helping build a place
-where research software engineers can truly belong.”
-
-> [Sandra](https://us-rse.org/about/staff/)
-
-This month, we thank the scrappy and passionate group of researchers who
-helped crystallize the idea of the Research Software Engineer, [one
-quiet afternoon in Oxford, UK, in
-2012](https://www.pure.ed.ac.uk/ws/portalfiles/portal/65195747/DR2012_12_1_.pdf).
-And the next time you notice a colleague struggling with a technical
-problem, be the RSE on their shoulder. Gently remind them:
-
-*Hey, I know how to do that.*
-
-> You are braver than you believe, stronger than you seem, and smarter
-> than you think. A. A. Milne, *Winnie the Pooh*
+This month, I had the pleasure of meeting some fellow R users at the
+Boston R User Group meetup, where I can say I finally felt safe opening
+a conversation with a hot take like, “R is the best,” knowing it would
+likely not spark a flame war. I’m sure many of you having read that
+sentence are already compiling the several counterarguments in your
+head, mashing away your response in a text editor, choosing all your
+best and worst use cases as examples and calling on the greats of your
+respective community to back you up. But this discussion is actually not
+about flame wars; in fact, as I’m sure you’ve experienced, we as
+technologists often care less about what tool is objectively best, and
+more about what tool is best for us, our project, and our team.
+
+And while this can sound like a freeing stance on tooling in general, it
+leaves us with an acute conundrum: how do we know when to *switch*
+tools? When do we know that the tool we’re using is no longer best for
+us, and that we should switch to something else? As computing becomes
+more accessible and capable, more individuals are building tools that
+avow to *finally* and *decisively* solve the problem of \[insert other
+tools’ shortcomings here\]. Indeed, whether it was Markdown’s attempt to
+become the de facto standard for writing on the web Anaconda claim to be
+the last word in environment management for data science, or the eternal
+paradox of Apple’s latest OS somehow always having “the best feature,
+ever,” technology is rife with shiny toys that promise to solve all our
+problems. On the one hand, it can be incredibly overwhelming trying to
+keep up with the latest and greatest, and on the other, you could easily
+risk missing out on a tool that could be a game changer for you and your
+team if you don’t branch out and experiment from time to
+time[1^](In%20fact,%20at%20this%20UseR%20Boston%20meetup,%20we%20ourselves%20had%20a%20hard%20time%20rectifying%20our%20excitement).
+
+This decision fatigue can end up being a significant job hazard for
+people who work with technology. What if your organization is one of the
+unfortunate few that decided to go all-in on Skype\[2^\], or what if you
+can’t ship a new product or publish a paper because your team has not
+ported over its legacy libraries to Python 3 yet? As RSEs, part of our
+responsibility is to help scientific teams navigate this ever-changing
+landscape of tools and technologies, and it can be very tricky to draw
+the line between productive experimentation and [shiny toy
+syndrome](https://nesslabs.com/shiny-toy-syndrome). How does one justify
+several afternoons’ worth of tinkering, only to come to the conclusion
+that the new tool actually *doesn’t* do what it says on the box - or at
+least, not to your satisfaction — and continue to be trusted with the
+responsibility of guiding your team’s technological vision?
+
+But as I thought about this more, I realized that this activity of
+tinkering and experimenting with new tools is actually a critical part
+of our job as RSEs, and that we can turn this “bug” of shiny toy
+syndrome into a “feature” of arrestive curiosity. Arrestive curiosity is
+the tendency to be so curious about new tools and technologies that you
+cannot move forward with your own work until you’ve proven a new tool is
+either better or worse for you than the one you’re currently
+using\[3^\]. If you’ve ever been up late at night trying to get a VSCode
+extension to run without error, trying to figure out why a new library
+can’t just install on your system, or drawing out your ultimate
+note-taking entourage of apps for never losing a thought, I see you!
+This kind of curiosity can be a disastrous time sink — but it can also
+be a powerful way to stay on top of the latest and greatest, and to make
+sure you’re using the best tools for you and your team.
+
+So, how do we cultivate arrestive curiosity without falling into the
+trap of time-wasting? Having wrestled with this for several years, I
+think I can provide a few considerations that have helped me strike this
+balance:
+
+1. *Stop being distracted by the perfect tool until you know what
+ perfect is supposed to look like.* Before seriously investigating a
+ new tool, write down exactly what problem or need you think it is
+ trying to solve for you. In the simple process of articulating this,
+ you may find that your existing workflow just needs some refinement,
+ or a simple adjustment or reframing of the problem. 95% of the time,
+ my tinkering does not pass this step.
+
+2. *Get comfortable with the discomfort of your current tools.* If
+ you’ve successfully passed the first step, then you know for a fact
+ that your current workflow needs are not being met, and a new tool —
+ or repurposing an old one — is likely the solution. But before you
+ dive into the new tool, now is the time to measure the discomfort of
+ your current workflow. How much time are you losing to this problem?
+ How much mental energy are you spending on it? How much is it
+ costing your team in productivity and morale? If the cost of your
+ current workflow is not high enough, then it may not be worth the
+ time and effort to switch to a new tool. If you can tolerate the
+ discomfort, then the tool search ends here.
+
+3. *Refine to absurdum.* If you are still convinced that something is
+ missing, then it is time to start looking for what is missing.
+ Surely someone has felt this acute pain, right? The internet is a
+ vast place, and there are several billion of us using it at any
+ given time. It’s more than likely that someone, somewhere, has been
+ in the exact position you’re in, with an install that is too slow, a
+ link that doesn’t work, or a workflow that is too clunky and just
+ missing that, *secret something*. Go out into dark corners of the
+ second, third, and fourth pages of Google search, ask around on
+ Reddit and Facebook groups, or find forums and communities that are
+ relevant to the problem space. Surely **someone** has faced this
+ problem, too?
+
+4. If the solution is identified, use it. If not, build it. By this
+ point, if you have found a niche problem that 1) arrests your
+ productivity, 2) causes measurable discomfort, and 3) has not been
+ solved by anyone else, then this is a problem worth solving. In
+ fact, as an RSE, this is the *perfect* problem to have, because it
+ is within this narrow gap between your vision and the status quo
+ that you can actually make valuable impact to your team. If you
+ can’t or don’t want to build the solution yourself, one of two
+ things must be true: either the problem is not worth solving, or you
+ are *not yet* the right person to solve it.
+
+In my experience, the really interesting Research Software Engineering
+is what happens when as an engineer I have become *obsessed* with a
+particular technological blocker to the success of my or my colleagues’
+scientific endeavors.
+
+It is the moment we look at the scientific engine and say, “I know we
+*could* just use \[X Tool\] to write this part of the paper, but I just
+can’t accept that this is the best way to do it. I simply can’t. There
+*must* be a better way.”
+
+This is the “arrestive,” part of “arrestive curiosity” — the part that
+keeps you up at night, ceases you in your tracks every time you think
+about it, and continues to consume all of your mental energy until you
+have either found a solution or come to terms with the fact that there
+is no solution.
+
+And if you ask me, that tendency to be obsessed with finding the best
+way to do science is what makes a good RSE a *great* RSE. So, the next
+time you find yourself in the throes of shiny toy syndrome, try to
+channel that energy into arrestive curiosity using the flowchart I
+outlined above, and see where it takes you. You might just find that the
+perfect tool was right in front of you all along, or you might end up
+building something that changes the game for you, your team, and perhaps
+even the science itself.
+
+vs. hesitation around all things AI in the R world. We could barely come
+to a consensus on whether we could be convinced to switch over to the
+new native pipe `|>` or stick with the beloved `magrittr` pipe `%>%`
+that we’ve been using for years, all the while doing our best “old man
+yells at cloud” impression. Spoiler alert: I’m yelling at the cloud.
+\[2^\]: Shout out to everyone currently being held hostage by their
+CTO’s contract with Microsoft and having to wake up every morning to the
+sound of a Teams notification. We see you, and we feel your pain.
+\[3^\]: Yes, I just came up with it. No, I will not be answering
+questions.
------------------------------------------------------------------------
@@ -297,7 +289,6 @@ interested in becoming an organizational founding member!
{% for org in site.data.org-members.standard %}
- [{{ org.name }}]({{ org.url }})
-- [Flatiron Institute](https://www.simonsfoundation.org/flatiron/)
{% endfor %}
@@ -314,6 +305,78 @@ interested in becoming an organizational founding member!
+### The Whole Person: Pride and Belonging in US-RSE
+
+Pride Month is both a celebration and a moment for reflection for the
+communities we are part of. As the chairs of the DEI Working Group, we
+welcome everyone to celebrate Pride Month with the US‑RSE community this
+June and beyond. We also want to take a moment to reflect on what Pride
+means to me and how it shapes how we think about belonging in our
+professional communities.
+
+US‑RSE is a community built around shared skills, interests, and goals
+centered on advancing research through software engineering. While that
+core set of interests brings us together, we are also a collection of
+individuals who work across different research domains and parts of the
+software engineering lifecycle. Each person brings unique strengths and
+perspectives.
+
+A mix of viewpoints helps teams generate stronger ideas and advance
+research. That kind of collaboration works best when people feel a sense
+of belonging.
+
+At the same time, we don’t show up to these communities as just “RSEs.”
+Each of us brings life experiences, preferences, and unique quirks. You
+can’t interact with just the “software engineer” side of someone. You
+interact with the whole person, which means accepting them as they are.
+
+That’s where belonging comes from. It’s not just about being part of a
+group with shared interests. It’s about being accepted as you
+are.Creating that kind of belonging can be challenging in practice,
+especially when building trust with people who have experienced bias,
+exclusion, or worse.
+
+That’s why small actions matter. Sharing pronouns, using gender‑neutral
+language, and taking the time to learn about the people around us can
+make a real difference. They signal that people are seen, respected, and
+welcome as part of the community.
+
+For us, Pride is a reminder that this kind of belonging does not happen
+by accident. It is something we create together through everyday
+choices.
+
+Pride means different things to different people. To reflect that range
+of experiences, we invite members of the US‑RSE community to share what
+Pride means to them and how they think about belonging in their work.
+
+What does Pride mean to you? We’d love to hear your perspective. Feel
+free to join the conversation on Slack or share on social media using
+the hashtag `#RSEPride`.
+
+##### Community Contributions
+
+> Research software often involves intensely multidisciplinary
+> collaboration, and, depending on the size of a team, may require the
+> ability to liaise between domains, technical-side, business-side, etc.
+> and advocate whether it’s for data integrity processes or for
+> underweighted voices. In my mind this relational communication and
+> openness is very prosocial and qualitatively close to what Pride is
+> all about; I think it’s why I feel at home in research software and
+> the surrounding communities. – Michael P. Pascale
+
+> I actually did not grow up playing with computers. I always was tech
+> savvy, but never imagined myself opening a terminal or writing code.
+> So when I found myself engaging with technology in research, I was
+> very intimidated, often suffixing all of my conversations with, “but I
+> don’t know anything about this stuff.” That feeling of imposter
+> syndrome went away when I joined the RSE community, and I owe my
+> career success to the culture of support and encouragement that I
+> found here. Celebrating Pride Month with the LGBTQ+ community every
+> year is a reminder of how unconditional acceptance and support enables
+> people to self-actualize and thrive. I stand with my LGBTQ+ allies in
+> celebrating them and advocating for their space in our world! -
+> Tinashe M. Tapera
+
### **Community Shoutouts**
@@ -338,22 +401,32 @@ has taken home this honor!
Read the announcement
[here](https://blog.chameleoncloud.org/posts/sc25-best-reproducibility-advancement-award/).
-### RSE’s with a New York State of Mind… 🗽
+> Did you know that we have a community Code of Conduct? Anyone is able
+> to view it in the `#code_of_conduct` Slack channel, under `Files`!
+
+### In Memoriam
-The NYC Regional Group recently met up for their inaugural in-person
-hangout! Special thanks to Roger Ferger for spearheading the event!
+We mourn the loss of a dear friend and colleague, Cleve Moler, who
+passed away on May 20, 2026, at the age of 86 at his home surrounded by
+his family. Cleve was chief mathematician and cofounder of MathWorks and
+the author of the first version of MATLAB. Please join us in remembering
+their contributions to science and engineering by reading Mathworks
+official announcement
+[here](https://www.mathworks.com/company/aboutus/founders/clevemoler.html).
-
+## Community Spotlight
-
-
+🌱 Our community is full of people doing fascinating research and
+software work, and we want to put a face to it. Starting this month,
+we’ll be featuring a group of different members in a regular spotlight:
+what they work on, a tool they can’t live without, and how they found
+their way into RSE work.
-As an added bonus, the group also now has a dedicated page on the US-RSE
-website! Check it out [here](https://us-rse.org/ag/rg-nyc/) to learn
-more about the group and how to get involved.
+We’d love to feature YOU. It takes about 5 minutes to fill out, and
+nothing gets posted without your okay:
+
-> Did you know that we have a community Code of Conduct? Anyone is able
-> to view it in the `#code_of_conduct` Slack channel, under `Files`!
+Email [Pengyin Shan](mailto:pengyins@illinois.edu) for any questions!
### **Community Calls**
@@ -369,8 +442,8 @@ more about the group and how to get involved.
-->
-Our next meeting is scheduled for Friday, June 12, 2026, 12:00PM EST. We
-hope to see you there!
+Our next meeting is scheduled for Thursday, July 9, 2026, 12:00PM EST.
+We hope to see you there!
------------------------------------------------------------------------
@@ -428,7 +501,7 @@ the `#newsletters` channel!
{% endfor %}
{% endif %}
-{% assign podcasts = refs | where: "type", "motion_picture" %}
+{% assign podcasts = refs | where: "type", "song" %}
{% if podcasts.size > 0 %}
### 🎧 Podcast Episodes
diff --git a/_posts/newsletters/render_new_edition.sh b/_posts/newsletters/render_new_edition.sh
index 6a75bd772..c94c4d2b0 100755
--- a/_posts/newsletters/render_new_edition.sh
+++ b/_posts/newsletters/render_new_edition.sh
@@ -10,7 +10,7 @@ yaml_file="$4" # newsletter parameters
quarto render "$qmd_file" --metadata-file "$yaml_file"
# convert Interesting Reads bib to yaml
-pandoc _data/newsletter_bib.bib -s -f biblatex -t markdown > _data/newsletter_bib_yml.yml
+pandoc _data/newsletter_bib.bib -s -f biblatex -t gfm > _data/newsletter_bib_yml.yml
# copy yaml frontmatter into rendered quarto output
tmp=$(mktemp)
diff --git a/assets/img/newsletter-202606/tasha-kostyuk-TtMKq3lJm-U-unsplash.jpg b/assets/img/newsletter-202606/tasha-kostyuk-TtMKq3lJm-U-unsplash.jpg
new file mode 100644
index 000000000..04cc6faf0
Binary files /dev/null and b/assets/img/newsletter-202606/tasha-kostyuk-TtMKq3lJm-U-unsplash.jpg differ
+