Skip to main content

This Week In React - Curator Job

I initially created This Week In React as a curation newsletter helping React devs stay up-to-date with ecosystem news.

The long-term goal is to become a real community-driven media for React and React Native developers (similar to CSS-Tricks). I’d like it to be more than a weekly email with a list of links.

To do that, I need to delegate, and would like to recruit newsletter collaborators to help me produce the weekly issues.

This is real work: you get paid, need to be reliable, and be willing to spend 14-18h of work on a single email.

Benefits for This Week In React​

My main goals for this recruitment are:

  • Having a reliable a backup when I take holidays, to avoid burnout
  • Making the media look professional with 50+ issues per year
  • Making the media more community-driven
  • Making the media more diverse by rotating authors
  • Freeing up time to develop the media further
  • Ensuring the quality of the newsletter stays high

I've been doing this almost alone for five years now, and what was fun at first can become a burden in the long run. I’d like to choose when I want to publish a curation newsletter, instead of being forced to. I’d like to remove myself from the equation so that the project can eventually outlive me.

Benefits for our guest curators​

The main benefits you get:

  • Being paid correctly for each issue sent
  • Contributing to your personal branding and the visibility of your company (example issue written by guest curators)
  • Giving back to the community, contributing to a useful project

I’m open to discuss the benefits you get if you have fancy ideas. As long as it’s a win-win.

The ideal candidate​

I’m looking for someone who:

  • Takes it seriously, is super reliable and willing to do that job in the long term.
  • Can take full ownership of a single email. Remember: I’ll be on holiday and will just be there to hit send! You will be on your own, in my shoes.
  • Can comment on both React and React Native news, and provide interesting, senior-level insight.
  • Can spend ~16h on a single email once a month. Really, it’s not a joke, you can’t do that as a side project and need to schedule that time on your agenda.
  • Can follow my curation process to find interesting links through various sources (RSS, X, organic…)
  • Read the newsletter regularly, and understand the target audience.
  • Can follow my editorial line and formatting guides.
  • Can communicate properly and simply in English, but it doesn’t need to be perfect and you can use LLMs if you want. I’m not a native speaker and it’s ok.

Yes, I’m looking for a 5-legged sheep 😅

The ideal candidate might not be a single person, but a React service company providing a duo of contributors. The advantages for me:

  • They usually take it seriously, with a long-term marketing vision.
  • They know how to manage developers and book the appropriate time in their agendas.
  • They can take ownership of an issue and care about their reputation.
  • They can provide a stable duo with distinct expertise to cover both React web and React Native
  • They can find a backup in case one of them takes holidays or doesn’t want to contribute anymore

I remain open to individual contributors, but I believe companies are a better fit. I already work with Theodo Apps successfully (example).

Onboarding​

So far, the onboarding has been:

  • You introduce yourself (or your company’s employees), explain why you think you are a good fit.
  • We run a test (paid), and assign you 2 test issues on our newsletter calendar, weeks in advance.
  • We do an onboarding call so that I can explain the process .
  • I give you access to my curation tools to source links (RSS reader).
  • We work collaboratively on the 1st test issue so that you get used to the process and understand the subtleties.
  • You take full ownership of the 2nd test issue. I’ll answer questions and provide feedback, but you’ll do the majority of the work in autonomy.
  • We review the work. It will never be perfect, but If I’m not ashamed of the email we sent, then it’s working and likely to improve in the future.
  • We can define other dates you take ownership of.

The process​

TLDR: the newsletter curation process usually starts on Mondays, and we send the newsletter on Wednesdays evening (~17h UTC - ~9am PST). You have the responsibility to ensure that the email is 100% ready to be sent on Wednesday. Usually, it takes ~16h of work in total, that you can eventually parallelize between 2 devs.

Main steps:

  • Planning weeks in advance the issues you’ll take ownership of
  • Sourcing roughly interesting links on X, RSS, web and organic sources
  • Adding those links to a collaborative Google Docs
  • Reviewing these links, formatting them and filtering uninteresting ones
  • Commenting the most interesting links
  • Selecting headlines
  • Selecting a meme, preferably related to the news
  • Creating a title with React / RN keywords
  • Creating an intro text
  • Converting to MDX
  • Pushing to Git and publishing the online version
  • Helping spread the word about the newsletter on social platforms

This remains under my responsibility:

  • Managing newsletter sponsors and ad placements
  • Converting the web newsletter to the email version and hitting send

To be defined:

  • Publishing a X thread or an article
  • Publishing on Bluesky, Reddit, LinkedIn and other platforms

Months in advance, we look at the newsletter public calendar to define which dates you will contribute to. Once we decide on a date, you become the planned author of this newsletter, and you must book ~2 days of work in your calendar to work on it.

Curation process​

The sourcing process is quite predictable:

You can also find interesting things your own way, organically or predictably, and help me refine this process over time. If you find interesting sources that we don’t track yet, we need to start tracking them.

Editorial line​

General idea:

  • For mid/senior React and React Native dev, but not limited to React links.
  • Fresh content. 1 month is old already, we probably already covered it.
  • Weak signals to understand what the future will look like.
  • Event-driven content, such as a new release, a new project, a new docs page.
  • Be the pulse of the ecosystem instead of being a discovery tool for all the React npm packages.

What to prefer:

  • Content focusing on a single idea explaining a concept in depth.
  • Content focusing on React core techniques, broadly applicable by a large audience.
  • Content presenting novel, innovative or underrated techniques.
  • Content covering niche topics and weak signals when presented well or impactful.
  • Content with outstanding presentation effort and great reading experience such as interactive articles.

What to avoid:

  • Filter content produced by AI, for obvious SEO reasons, listicles, and other low-quality articles.
  • Filter content behind a paywall, requiring auth or having a bad reading UX.
  • Filter content for junior developers, basic 101s, step-by-step tutorials, paraphrasing official documentations with no added value.
  • Filter content teaching how to use a paid product (we have sponsorships for that), unless it is not too promotional and teaches something valuable about React core along the way.
  • Filter most UI libs and boilerplates, There simply are too many. The exception is when they prove high traction, a long-term maintenance commitment or come from an authority. We don’t cover “launches” for these but might cover v10 once it becomes mainstream and has proven its value to the community.
  • Filter weak signals that are too weak: if you don’t even understand it, can’t explain its impact with simple words, or think only a dozen people will benefit from a link, maybe it’s too soon, or not worth including that link.
  • Avoid X/Twitter thread/conversation links whenever possible: they require signups. Prefer external links. Eventually, individual tweets are fine if they contain all the information, a link, or a video demo.

Exceptions can always be made for content with an outstanding presentation effort. An interactive article explaining basic React concepts is fine for example: it’s a great resource our target audience (senior devs) might share with their junior colleagues.

Content​

The newsletter contains a lot of links, because the React ecosystem is thriving. Instead of filtering links more aggressively, we optimize for providing a good reading experience despite the information density. The content should be consistent, easy to scan, and information should be “inlined” whenever possible. We don't want to bait someone into clicking on a link and then disappoint them. Reading the newsletter should provide value despite not clicking a single link.

Sections​

The newsletter has 5 main sections:

  • Intro: a small recap of the news
  • React: for content relevant to all React devs, and React web devs
  • React Native: for content relevant to React Native devs
  • Other: for content relevant to a broader JS audience, including TS, CSS, TC39, HTML, tooling and more
  • Fun: 1-3 memes or fun screenshots, preferably related to React (private joke) and the news of the current week.

Headlines​

We usually pick:

  • 1 React headline
  • 1 React Native headline

Each headline usually has a top banner image. It’s preferable to pick one that represents something meaningful visually (such as a code screenshot) but a beautiful social card is ok too.

Sometimes there is no clear headline for a section, sometimes there are 2. Sometimes we pick a headline for the Other section.

Formatting​

All links usually follow the following convention for most links:

  • <Emoji> Link title: Optional subjective comment.

If a title is too long, click-baity or weirdly capitalized, feel free to refactor it so that all titles are relatively consistent.

For releases, we drop the “v” and the patch number (3.1, not v3.1.9). Include the major release highlight keywords directly in the link, separated with a dash -. Don’t include a release if there’s nothing interesting to highlight, which is often the case for patch releases. What’s “inside” the link is the “objective” part (the highlights), what’s “outside” is your subjective comment (if any). Examples:

If it’s a rather new project featured for the first time, you can avoid the version number, and replace keywords by an objective project description (inspired by GitHub repo description, landing page, SEO tags):

Here’s the emoji palette we generally use

  • 💸: sponsors
  • 👀: preview, PR, weak signals
  • 💬: RFC, community discussion
  • 📊: survey, benchmark
  • 💡: interesting idea
  • 📖: docs
  • 🦋: Bluesky links
  • 🐦: Twitter/X links (avoid if possible)
  • 🎨: visual demos (posted outside X)
  • 📅: events, conference partnerships
  • 📜: articles
  • 📦: releases, npm packages plugins, repositories
  • 🔗: resources
  • 🎥: videos
  • 🎙️: podcasts

We usually respect more or less this “emoji ordering”, leading to a consistent reading order:

  • headlines
  • weak signals
  • community articles
  • media resources

Example:

Comments​

Some general rules to follow:

  • It’s not needed to comment on everything.
  • For a given emoji, what we comment usually appears first.
  • It's better not to comment on something than to make the wrong comment.
  • Comments have to be concise and to the point.
  • Use a simple language.
  • Don’t add useless fluff words.

Conclusion​

Yes, this is a serious job that takes a lot of time. I hope you’ll be interested to help me!

Contact me at sebastien@thisweekinreact.com