The Marketing team promotes WordPress to current and future users and contributors. We create and amplify campaigns to support the growth of the WordPress project.
Our work is tracked on the Marketing Tasks Board on the WordPress organization’s GitHub. If you are planning a Marketing Table at a Contributor Event, please let us know in the Slack channel.
You can be part of the #marketing channel on Slack. Join our next Weekly Marketing Chat at: Tuesday 15:00 UTC.
Diary dates
This guide summarizes the responsibilities and processes of the Marketing and Communications lead role for a major releaseMajor Release A set of releases or versions having the same major version number may be collectively referred to as “X.Y” -- for example version 5.2.x to refer to versions 5.2, 5.2.1, and all other versions in the 5.2. (five dot two dot) branch of that software. Major Releases often are the introduction of new major features and functionality. cycle. It includes information on:
This is a living document. Therefore, each lead is expected to update this document to reflect the evolution of the role and processes regarding release communications.
Your work may start sooner than you expect in this role. It will also require accuracy, technical knowledge, communication, and collaboration. Additionally, you’ll need to bring patience, confidence, and humility to the role. Above all, don’t stress this role. Like many parts of the WordPress project, a community of contributors is waiting to help you succeed.
Your work and responsibilities begin the day it is announced that you are a mar/comms lead, usually about a month before the BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 release. At that time, you’ll start to work on two key items: the About page and the Beta 1 release post. These two assets will share content.
Before beginning work on the About page and the release posts, make sure you plan and prepare tasks, as that will help set you up for success early. Things can move quickly and tend to accelerate until the release day, so it will be easy to fall behind if you are unprepared. The following are some tasks to keep in mind for the planning phase:
Writing about the release requires that you know what is going into the release. This can be one of the most challenging things about the role of the mar/comms lead. Don’t sweat it! Read as many resources about the release as possible. You will also want to review GitHub and Core TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. tickets, partner with other contributors, and collaborate with release squad members to gain the needed knowledge. Here are some posts/resources that come out early in the release cycle and are good to have on your radar:
Tips:
IMPORTANT NOTE: There may be around 10 or so GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ releases between major WordPress releases. The “What’s new in Gutenberg” posts can be a nice guide to learn about some features planned for the release, but they are not a definitive list of what will ship with your release. Once you build a list of key features, you must validate it with product contributors, release coordinators, and leads from core, at a minimum. More on this below.
Communicating the value of a specific release is an evolving and ongoing topic within the WordPress project. It may be worthwhile to introduce high-level release messaging with the release preview (e.g. beta 1) or even just in the release announcement itself. Doing so could also provide some nice talking points with the tech media that often will report on the release. For example, 6.3 (Lionel) was the “official” end of the major work in Phase 2.
It is also important to highlight what goes on “under the hood” in a WordPress release. In other words, all the feature enhancements that went into the release are not all design/UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing.-related or feature-based. These are sometimes more difficult to communicate because they are not always visible to everyday users. For example, each release has a lot of time and attention devoted to backward compatibility, a hallmark of WordPress. Along with backward compatibility comes a focus on stability and testing. Additionally, in recent years, a greater emphasis has been placed on accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) and performance. All of these topics should be addressed in release communications.
It is important for you (in this role) to be proactive and visible. This helps folks understand your role and contributions and be aware of your actions so they can ask questions and resolve assumptions. Ensure the Make Marketing team reps and release contributors know you are a mar/comms lead and tag you when questions come:
Will you miss a release party? Plan to have a backup represent the team at the release party. That person should have access to the release post draft(s), an understanding of what you need them to do (and when), access to publishing the post, and the release squad leaders should know that you’ll be out and have a substitute. If your backup is unfamiliar with the release process, plan to have that person tag along for an earlier release to observe. Be very clear and specific with commitments and obligations. Typically, anyone on the release squad can serve as a backup (but note that they have other responsibilities.) Other members outside the squad may also have release announcement experience, so ask around (especially full-time sponsored contributors).
Additional tips:
Plan to ensure the documents you create are shared with the community and co-leads in various Slack channels. This should include the release mar/comms channel (if you set up one) and the release leads channel. The #core channel can be appropriate as well. Developer input should always be welcome as that is a good perspective to help validate the content of a release document.
Make Marketing contributors can provide editorial support and insights into ensuring your post copy is clear and properly internationalized. Also, explain when you deviate from historical practices, as the community may want to understand the reason behind the change. So tread carefully and focus on incremental advancement rather than the complete refresh of processes and content. Always embrace communication with a focus on clarity and thoroughness.
The “About page” is a reference page displayed to admin users in the WP-Admin dashboard post-upgrade. The content on this page generally focuses on key features introduced in the release. It includes resources for finding more information about updates and features, such as the release notes documents, developer tickets, and so forth. The page also has sections on WordPress privacy, the freedoms of open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL., credits for the release contributors, and how to get involved. These four sections seem to remain relatively unchanged from release to release. However, it is reasonable to iterate improvements to the main part of the page by reorganizing the content a bit. For example, some releases featured a video.
Open a Trac ticket for the release About page, similar to this one for 6.4. Any contributor can do this, so check first to see if one does not exist by searching Trac or posting in the release leads channel. It does not require much data when creating the ticket, as it is a placeholder. This ticket will store links to the draft working docs for collaborating on content and design (e.g., a Google doc and a Figma file), preliminary artwork, discussions around the page, and, ultimately, the final approved materials and source code for the page.
Create a working document (a Google doc in the shared drive). You can base it on prior release assets, like this one from 6.3 or this other from 6.4. As you work on your content, collaborate with product contributors to ensure that you are clear on the key features to prioritize and ensure the accuracy of the copy.
NOTE: If you include placeholder images in your draft documents, clearly indicate that the image is a placeholder. Either do this by watermarking the image or using a color blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. that says “placeholder.” It is important that anyone viewing the working documents knows that the image is not a final one.
Share it for review and feedback. Once you have a draft, share a link to this document in the Trac ticket and with the release leads and mar/comms contributors. When sharing the doc, provide some ground rules for collaborating and set clear expectations on the feedback expected and when (this is applicable to all release documents). For example:
Collaborate with design contributors. As you work on finalizing the content, it’s important that you work closely with design contributors. The About page usually follows specific layouts, so it’s very likely that the copy will need changes as contributors work on its design, such as tweaks to avoid orphans and widows, shorten some sections, etc.
Timeline: The About page should be completed one week prior to RCRelease Candidate A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. 1. In fact, it is recommended by core committers that the content be completed by Beta 2 to allow for time for feedback and design to work out the layout. RC 1 includes a “hard string freeze.” This means the text copy is locked from edits so Polyglots can translate it. The only changes made to the doc after RC 1 should be changes that correct factual errors – and if so, those changes should be communicated in the release leads channel and added to the Trac ticket.
Tips: In Google Docs, you can change the page setup to “pageless” to remove page breaks since they are unnecessary for this document. Also, you can name versions as you progress through the editing process and/or add a changelog to the doc to help track changes and understand the evolution of the document.
For more context on the About page asset, this marketing handbook discusses some of the page’s history and what goes into it, referencing the design work and the news post. However, note that it is outdated and no longer actively maintained. By viewing recent About page examples and the guide you are reading now, you should be able to have a good starting point. If you need more information or guidance, ask previous mar/comms co-leads.
Before introducing any change, make sure you can clearly explain the value it brings, address possible concerns in advance, and prepare to have some discussion. Of course, it is much easier to make small changes during the release cycle than big ones, so keep that in mind. Bigger changes might need to be introduced, discussed, and tabled so that the release process can continue and be reintroduced for the next release cycle. This is perfectly okay and a natural part of working within open source. Embrace it!
When sharing the link in any public channel, clearly state what you share. Explain the process and resources you used to produce the document. This helps to provide context to the community on how you made your decisions. Here’s an example of the RC 3 post for 6.0 in the release leads channel. Knowing what context (or lens) everyone else uses to read and interpret your comments is impossible, so taking extra time to communicate thoughtfully is very beneficial in the project. It also makes it much easier to reference your work in the future.
Scrolling through this handbook, you’ll see examples of the various announcements (Betas, RCs, and the final post). These posts have all varied from release to release over the years. Toward the end of 6.3’s release cycle, a new format/structure was tested with positive results. Therefore, it is recommended that you use this “updated” template as the basis for all of your Beta and RC posts. While posts will still vary from one to the next, following this general structure should create consistency and efficiency.
Here’s an example of the above outline in action for 6.3 RC3 and another similar example for 6.4 RC3.
The Beta 1 announcement is the first major public announcement about the forthcoming release. It’s also one of the most complex yet important announcements to create. The announcement typically includes a summary of the planned features and the general purpose of the release. You’ll also include a call for testing and reference links to queries for fixes and enhancements that will be included in the release. This announcement will be made on /news.
Fine-tuning the list of what will be in the release is challenging. Like the About page, lean early on folks who serve in product roles and other project technical areas for their keen insight and visibility into the release specifics.
Collaborate with them on a feature list summary and get clarity on priority features ahead of the first drafts of the Beta 1 post and About page. This will help you get consensus/buy-in on the list and reduce the back-and-forth during the drafting, editing, and publishing processes down the road. You can also tag authors of tickets/features so they know you are requesting their assistance. If there’s work on assets like the highlight grid, that information can help too.
By researching various GitHub/Trac tickets and following the core channel in Slack, you should also be able to learn and gain a better understanding of each feature. Do not hesitate to ask questions; direct them to the release leads or the product folks. Moving further into the release cycle, you will become more familiar with the major features.
Examples of Beta 1 Posts:
Create a Beta 1 post template 3-4 weeks before. This will ensure that you can continue researching the features in the announcement. Later announcements will benefit from the early preparation of the Beta 1 announcement. Therefore, your drafts of the other milestone announcements can likely follow a shorter window.
It is important to note that numerous versions of Gutenberg are merged into core for a major release. Still, not all the features from the Gutenberg plugin may actually make it into the release. It can also happen that during the release cycle, some features initially slated for the release require further testing and are punted to the next major release. You are expected to be proactive by regularly checking and understanding what goes into the release. Read the release leads Slack channel for updates, review relevant tickets on GitHub or Trac often, and confirm with release contributors about any features before their inclusion in the Beta 1 post or other release assets.
Share an outline of the Beta 1 post with the product or technical liaisons for the release to ensure the highlighted features and messaging are accurate. After your first draft, once you have received feedback and cleaned the doc up, re-share the document to confirm technical accuracy.
Share your next draft, 1-2 weeks before publishing, with the release leads for feedback and pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” specific persons (owners of tickets referenced in the post or team leads for entire sections such as “performance” and “accessibility”) to help review the information. This will give you extra time to fine-tune the post before sharing it with a broader audience.
Tip: If someone suggests that you add/remove/edit something in the post, you should attempt to verify the request (e.g., fact-check). Obviously, if the request comes from a release lead, it likely can be highly trusted for accuracy. However, sometimes, contributors may suggest something is missing or wrong with a section. You’ll need to understand if the request is a matter of personal preference or historical precedence and/or if necessary. It’s always fine to ask for clarification as to why the suggestion is being made and to verify it with a member of the release squad.
Remember to set ground rules and timelines for contributing when sharing the doc. Be specific about who you seek feedback from, the type of feedback you seek, and when you need the feedback. For example, you may not need feedback on messaging or style/voice in the later review rounds. See more tips in the About page section above.
You can reshare a final draft in the release leads channel and lock the document from editing before publishing, just allowing comments. However, you should understand that feedback and some data/stats may arrive at the very last minute. You must be able to accommodate last-minute feedback and collaborate quickly with folks across the project to determine if any change is necessary.
An announcement tradition: Release posts have included historical quotes or poems (such as Haiku) at the end of the announcement. This keeps with the casual and fun tone of the WordPress project. It is optional, although well-received by the community. Whatever you do, be sure that what you write is consistent with the voice of WordPress and can be universally accepted. In other words, avoid writing things that might create risk for the project from a public or community relations standpoint.
Tips: Enable the public preview after moving the post to the CMS so folks can review it during the release party. Check/click all your links to ensure they resolve to the destinations you intend. Some links, such as the ones to download the release package, may be case-sensitive. See this checklist for announcement posts for more tips.
Feel free to include a link to the live demo walkthrough when appropriate. Finally, you’ll want to share the announcement code from the CMS in the #Polyglots channel. See the section entitled “Polyglots” below.
The next few release posts will typically cover the planned Beta 2 and Beta 3 releases. These announcements will be made on /news. In some prior releases (6.2, for example), these were shipped to /core. However, while justified, various community members didn’t welcome this change, so it was decided that posts would continue to ship on /news.
These two posts will look similar to one another and typically include a call for testing, links to fixes in both GitHub and Trac, a list of key fixes with links to their corresponding tickets when needed, and any other important information (ping and ask the release leads what else should be included if anything.)
Use the general template shared above in the Beta 1 section of this guide.
Given the typical milestone release cadence (weekly), it is recommended to draft and share the template for the release announcement the day after the prior release. So, if a release announcement for Beta 1 happens on the 1st, you would draft and share the Beta 2 announcement on the 2nd. Things move fast!
You’ll then want to update the post the morning of the release party with the latest statistics and re-share the link with the release squad for a final technical check. Release squad leads will peek at your shared links at various times and offer feedback. They are very helpful with verifying queries for counts of issues resolved, helping you identify key tickets or issues you should include, and general proofreading. Feel confident in asking questions, as folks will be willing to help.
Finally, remember to share the announcement code from the CMS in the #Polyglots channel. See the section entitled “Polyglots” below.
Examples of Beta 2 & Beta 3 Posts:
The RC 1 announcement is an important milestone as it signifies the release cycle is entering its final phase. This post, like all others, will be on /news. Posts should include an explanation of what an RC is and the different ways to contribute, including a call for testing specific to extenders (theme and plugin authors) and a call for translation help. It can also include a recap of what is expected in the release from a high-level feature standpoint. Consult the outline shared in the Beta 1 section for additional guidance. While referencing/reviewing prior release posts is helpful, the most recent post typically reflects accumulated edits to processes and structure. Therefore, use the most recent post as the primary point of reference for structure.
Beta 1, which is released only one month prior, may contain a good list of features you’ll want to recap in RC1. You can also link back to RC1 versus simply using copy/paste. For the feature recap, it is important to verify with a member of the release squad that the list is still accurate.
You can leverage the same weekly “draft and share cadence” as you did for the Beta cycles. Share the draft the day after the prior release with the release leads and contributors for review and feedback.
Finally, you’ll want to share the announcement code from the CMS in the #Polyglots channel. See the section entitled “Polyglots” below.
Examples of RC 1 Announcements:
RC 2 and subsequent posts follow a similar structure to RC 1. However, you can remove the feature list, as you shared it in RC 1 (likely a week prior). You can provide links to Github and Trac queries for issues resolved since the prior milestone. You can also highlight any major items the squad believes are worthy of calling out. To support this, ping the squad in Slack and ask for those tickets in advance.
Here are two sample queries:
Note: For the sample queries above, you will need to adjust the filters/parameters to match your desired release number and date window. You should also check these queries with the release leads to ensure your parameters accurately capture the changes between milestones. It’s not entirely accurate, as the queries use date ranges, and issues could fall through the cracks or be duplicated in your query depending on the day they were committed. The release squad can always double-check your work. That’s why just including the queries is better than listing specific issues. (Unless there is a major issue that is recently resolved.)
Finally, you’ll want to share the announcement code from the CMS in the #Polyglots channel. See the section entitled “Polyglots” below.
Examples of RC 2 and RC 3 Announcements:
Sometimes the release squad determines the need for an extra milestone release as part of the beta or RC cycle (or both!) The original roadmap usually doesn’t include a call for extra milestones like a Beta 4 or RC 4. Yet, the squad sometimes needs to add these milestones into the release cycle, which usually does not change the timeline for the final release date. The reasons for them will not be covered here as they relate to development and testing processes.
Sometimes the responsibility of writing and publishing silent release posts remains with the technical leads. Therefore, you should ask and verify before working on a draft.
These are called “silent releases,” and publicly announcing them on the /news/ blog is not required. Instead, it is recommended that they be shared on the /core/ Make WordPress blog. Incidentally, if you have made it this far into this guide, you should consider working with the release squad to obtain access for posting in the CMS on the Make Core blog.
Examples of Silent Release Announcements:
Despite not being publicly announced, the silent releases can typically follow the same formats as other posts. If the silent release addresses a specific issue or set of issues, a small section detailing the issue(s) may be relevant.
Silent releases need not be announced on social media, as they are primarily for the dev and testing communities.
The General Availability or GA post is typically the final post in the release cycle. This is the most visible post and requires significant preparation, similar to the Beta 1 post. The good news is that there are well-defined examples from prior releases.
Sample GA Announcements:
Here is a sample release checklist for the “big day.”
For the feature summary, you can reuse the material from the About page, including the visuals. For releases like 6.3 or 6.4, more specific visual assets were created for the /news posts (here’s an example). Coordinate with the design contributors who work on the About page and other creative assets to help you with assets and, optionally, have them add the images directly into the CMS post after the final Google doc draft is complete.
It’s recommended to start work on this post at least three weeks prior to the publication date, with the first week spent compiling all the sections. Use placeholders that are very obvious and tagged with comments for any links, queries, images, or other unavailable assets.
Share an outline first, like this or this one used in 6.4. It denotes ordering sections, headings, content to be included, etc. Share this with your co-leads and other release squad members on Slack as soon as possible. TagTag Tag is one of the pre-defined taxonomies in WordPress. Users can add tags to their WordPress posts along with categories. However, while a category may cover a broad range of topics, tags are smaller in scope and focused to specific topics. Think of them as keywords used for topics discussed in a particular post. specific people if you need input by a specific date. Use the same process you used for Beta 1 and the About Page.
Once your first draft is ready, you can share it in the usual places noted throughout this guide. Include the timeline and contribution ground rules directly in your document. Here is an example draft document used for 6.3 and the one used for WordPress 6.4.
You can perform a few rounds of editing, with timelines for contributors to provide input. Then, you can clean up the document and request release leads to fact-check any particular areas.
Be sure to obtain a tentative final ticket count from the release leads and leave some wiggle room to avoid accuracy issues. For example, if 1123 issues and enhancements are completed, you could say “more than 1000” or “1000+”. This gives you some room. The media will likely use this figure, so it’s important it holds up.
Someone on the release squad will likely identify and compile the list of contributors. You can get an estimated count from this person and use the same strategy, such as “more than 500”, etc. It would be prudent to check in with the person providing the count to confirm that the list is accurate on the release day. There are some last-minute list “cleaning” activities where some contributors may be removed or added. Therefore, keep your estimate broad. Here’s an example of the spreadsheet that was used for 6.4.
To include the full list, you only need to use the “shortcodeShortcode A shortcode is a placeholder used within a WordPress post, page, or widget to insert a form or function generated by a plugin in a specific location on your site.” block in the CMS and add the following shortcode: [wpcredits X.y]. “X.y” is the version number, such as “6.4”.
For translation statistics, according to this Polyglots Slack thread, you should 1) look at the locales listed at least 75% or more in the /admin/ translate project and 2) look at locales listed at least 90% or more in the /dev/ translate project. Then, only count the locales that are on both of those lists to get the number. Since this is a somewhat tedious task, you can use tools such as ChatGPT to check the number of locales with such requirements in both lists. If you see the total number is 63, keeping it estimated (e.g., “more than 60 locales) is recommended.
For the GA post, you will obtain the jazz artist a few days prior to the release date and work with design folks to obtain relevant artwork. Do not add the art or the name to the Google Doc. Instead, draft an intro paragraph and share it with project leadership (Josepha) for approval or someone she designates.
A day before the ship date, move the doc to the CMS, set up all the metadata, upload the images to the media library, format, and proofread. Then you’ll share a public preview with the release squad for final feedback.
During the release party, turn off the public preview and update the draft in the CMS. Then add in the jazz artist info and image(s). You are now ready to ship!
The GA announcement should have a featured imageFeatured image A featured image is the main image used on your blog archive page and is pulled when the post or page is shared on social media. The image can be used to display in widget areas on your site or in a summary list of posts. (the jazz artist), and it is recommended to turn off the Jetpack social sharing if it’s not already turned off (more on that below in the social media section).
For this announcement, change the post author to the release lead (in 6.4, that was Josepha; in prior releases, it was Matt Mullenweg.)
Finally, you’ll want to share the announcement code from the CMS in the #Polyglots channel. See the section entitled “Polyglots” below.
After the major release, work will quickly pivot to future releases, including the next major release and one or more minor releases. WordPress development is global and 365/24/7 – it never sleeps! For example, after 5.9, there were three minor releases (5.9.1, 5.9.2, and 5.9.3). For 5.9 and 6.0, the first minor releaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality. shipped approximately one month following the major release. Also, for 5.9, the 2nd and 3rd minor releases shipped about three weeks apart. Finally, there was only one week between the 5.9.3 minor and 6.0 beta 1 releases. So as you can see, release cycles overlap a bit. In fact, for 5.8, the 5.8.3 minor release shipped between 5.9 RC 1 and RC 2.
As mar/comms lead for a major release, you may also be responsible for handling communications for the minor releases that follow. Be sure to indicate your availability to support these via the release squad channel.
These announcements require less preparation and follow a fairly consistent template. Minor releases typically have RC announcements you can assist with, published on the Making WordPress Core blog, while the actual release announcements occur on the main news blog.
Here are some examples of minor release announcements:
You’ll typically interact with the minor release squad (which likely will be similar to the major release squad). You’ll want to pull queries for fixes in the release and a list of props. However, you cannot use the WPCredits shortcode as you did for the major release. Members of the release squad can help you with all of these tasks. Share a draft of the announcement a few days prior with the release squad, and then after feedback, move it into the CMS and share a public preview with the release squad thereafter.
Finally, you’ll participate in the release party and publish the announcement, similar to a Beta 2 or RC 2 release announcement.
You will receive the jazz artist’s information a few days before release. It is the project’s tradition and the project leadership’s wish to keep this information as confidential as possible. Some people will know, but only those doing work around release documents.
Do not add the jazz information to the Google doc, CMS, or any other public space. Do not share it over Slack, even in a DM, if possible. You will draft the jazz section of the release announcement locally on your laptop and then share the passage for approval privately with Josepha (Josepha is the one who will share the information with you initially.)
On release day, a few minutes before publishing the release, you can add the passage into the CMS after disabling the public preview. Coordinate with the release leads or design contributors once you have the jazz artist info to ensure you have the appropriate images on time for the release announcement.
As mentioned, you can no longer leverage the Jetpack plugin for auto-posting milestone announcements directly through the CMS. Instead, coordinate with social media contributors to manually post release announcements.
The social media contributors manage official accounts for WordPress.org. They can help you draft content, find images, schedule, and more. You should feel confident collaborating and delegating to this team as they manage all official WordPress social media accounts.
As part of the release communications, you will want to develop a social media posting plan that begins promoting the release a few weeks prior and continues several weeks following the release (usually up until the first patch release.) A good starting point is to begin promotion about two weeks prior to the GA announcement.
You should be able to repurpose images that design contributors in the release will help create, such as the highlight grid or “coming soon” assets. Collaborate with them during the release (more on the section below), follow design work, and request specific assets when needed. Be sure to be proactive, provide specifics as soon as possible, and allow for ample time.
If there is a video accompanying the release, that can be used on social media. Sometimes the main video is also sliced into segments that can be used.
Have the release announcement posts ready to go (approved by necessary social media folks) a day or so before the release. You may have to update them with information about the jazz artist and provide links to the landing page and/or news announcement. But it is a good idea to understand that you’ll want to request these to be live as soon as the news release is published.
As mentioned above, it’s important to coordinate and partner with the release design contributors and helpers as soon as possible, as they will create different creative assets that mar/comms will contribute to and leverage for social media purposes. In 6.4, for example, there were different GitHub tracking issues for each asset, including:
Jazz artist’s assets are handled differently, but you should also keep them in mind.
Additionally, since WordPress 6.3, release design, developers, and marketing contributors have worked on a public-facing landing page for the release (microsite). See 6.3 microsite and 6.4 microsite. It is expected this will be continued for future releases. The microsite features short videos, visual assets, key messaging (much from the About page), and other relevant information about the release (with call-to-actions to download the release). Sometimes it might be necessary to expand and adjust the landing page copy. Mar/comms should help with this to ensure consistency with the rest of the release messaging and deliverables. For example, this is the GitHub issue where work happened for collaboration on the 6.4 microsite.
When the release squad begins, this work and design assets should be queued up with the video, if there’s one, as they might overlap with the same contributors.
Since 6.0, there have been opportunities to produce live sessions to spread awareness for what’s in the release ahead of time in a more visual/interactive manner. These events help build excitement with our developer audiences and enthusiasts alike.
In these live product demos, one or more hosts (typically release members of the squad) walk attendees through an outline of the major features and share their thoughts on functionality and the direction of the release. Should you want to continue with this type of event, you’ll want to coordinate the following with the release squad well in advance.
Date/time: For some releases, the event date was just after RC 1 to ensure that the features shown were the most likely to be within the release.
Moderator and presenters/hosts. Ensuring that the moderator and presenters or hosts represent the WordPress community as much as possible will ensure the event is well-received. Anne McCarthy, a product wrangler, created this excellent post as a reference doc for folks presenting/moderating.
Agenda and outline: You will also need to provide an event outline for the moderator and presenters; here is a sample outline for 6.1. But essentially, here’s a possible flow:
Duration: Allow 60 minutes as attention spans wane after a while, although some releases may merit up to a 90-minute session because of question-and-answer times.
Logistics: You should plan on confirming logistics about four weeks in advance. WordPress.org uses its own Zoom license, and you can contact Chloé Bringmann for more information. However, live streaming the event onto Facebook or YouTube might be beneficial to reach a wider audience. In that case, some additional prep work may be worthwhile. Irrespective of the platform, a dry run is useful. Consider how and where questions can be asked to avoid searching multiple locations.
A dedicated channel for this event exists in Making WordPress Slack, #walkthrough.
Promotion: Promotion of this event is key for attendance and should occur 1-2 weeks prior. Announce the event in a brief post on /news and promote it on the official WordPress social media channels. You can include regular reminders in channels such as #core, #marketing, and #announcements. Follow-up social media posts with a link to the recording and a recap post are also worthwhile, especially for folks in time zones where attending live is inconvenient. In that vein, WordPress did advertise in the post that people could pre-submit questions.
Here’s the public post about the 6.3 live product walkthrough event, the recap, the Q&A follow-up post, and the video on YouTube.
It may also benefit the community and build excitement around the release by hosting a second walkthrough during the RC phase of the release cycle. This has not occurred previously but could be considered in the future.
Some releases may include a video trailer, or overview, of the release. For 5.9, this was packaged as a “preview” and shared well ahead of the release. For 6.0, the video was timed to ship the day before the release internally and then publicly, along with the release embedded into the About page and news release, among other places such as social media and YouTube.
The video is a newer and evolving element for release communications and involves many teams of contributors, including marketing, design, and developers.
The primary focus of the video is to showcase new features debuting in the release. The mar/comms lead will coordinate this project, relying heavily on support and execution from design and developer contributors. For 5.9 and 6.0, an external contractor was leveraged to produce the video.
Planning for the video should begin when the release squad is announced, before Beta 1, and should coincide/overlap with coordination on design assets.
Videos from prior releases:
Josepha has featured a preview of the release for the past few releases as part of her bi-weekly podcast series. Here are links to the 5.9, 6.0, 6.3, and 6.4 episodes.
There’s not a lot of work for mar/comms in regard to this element. Just coordinate with Josepha and the production team to discuss including a release-related podcast in the schedule. The timing is less strict, though it is recommended to do it at least a few weeks prior to the release to help build momentum and excitement around the release. The podcast topic can also focus on a particular topic and/or include guests from the release squad.
But wait, there’s more! After the release announcement is published, your contributions as mar/comms lead may continue. Here are some additional responsibilities you may have in the weeks to come:
On release day, share a link to the announcement and a personalized note of thanks to the contributors on Slack. You can also share on your company’s Slack workspace if you are a sponsored contributor.
The Polyglots teamPolyglots Team Polyglots Team is a group of multilingual translators who work on translating plugins, themes, documentation, and front-facing marketing copy. https://make.wordpress.org/polyglots/teams/. will translate the news announcement into many other languages. You’ll need to send the team the source code from the CMS to assist with this process.
Find some time to sync up with the Make Training team to know if they are developing any short video workshops around new features in the release.
It should be possible to work with them and identify at least 3-5 short video workshops that could be produced using beta or RC software on some of the new features forthcoming. These videos, such as the Field Guide and About page, can be incorporated into release documentation. Here’s an example from the 6.4 release notes/documentation page.
Some good data around self-hosted WordPress usage may be helpful when writing and communicating about the release.
Release parties typically last about an hour and occur on the days of the milestone releases (betas, RCs, etc.) These occur in real-time via Slack, usually in the #core channel. The release coordinators run release parties and involve the release squad and many other contributors.
If you’d like to scroll back and review some release parties, here are a few:
You should attend all release parties as a release lead, so mark your calendars. Actively follow the conversation as the party takes place. Note that it is common that the party may start late if there are last-minute issues that require attention within core, so you could be “on hold” for a few hours. Plan accordingly.
The party follows a script run by the release coordinators that progresses through a series of steps to test the build in various ways and make it available for public testing. One of the final steps in the process is to publish the milestone announcement on the WordPress.org website.
Ahead of the release party, typically several days prior, you should share a Google draft of the release announcement in the release-leads Slack channel to request input and address any data needs. Once you have a final draft, you should lock that doc by setting it to “comment only.” Place a note at the top of the Google doc letting folks know the doc is “locked” for additional input when you finish the draft and to DM you on Slack if they have questions. Then, move the copy into the CMS, follow the checklist in this guide to proofread your release, and share the public preview link in the release-leads channel for final review.
During the party, stay alert and pay close attention as the script progresses. Toward the end, you will be prompted by the party lead to publish the announcement. Once you do, copy and paste the link into Slack and share it in the #core and #marketing channels.
Proofreading is important! When you publish the release, it gets emailed to all the folks subscribed to the WordPress.org news blog. Nervous yet? A typo or wrong link will then get emailed to those folks. While you can easily correct the post itself, you cannot retroactively update the email that goes out.
Release notes, like these for 6.4, are also published on the same day as the announcement. There’s a bit of a circular reference because the release notes link to the news announcement, and the news announcement links to the release notes.
The announcement should have precedence. Ideally, the release notes should be published first so the news announcement can include a link to the notes. The notes page can then be retroactively edited to include information on the jazz artist, a download link, and a link to the news announcement. Coordinate with the release leads to align and coordinate this process before release day.
For 6.4, mar/comms contributors were asked to help with the email sent to plugin authors after RC1 (once most of the dev notes and the Field Guide are published). This does not mean you will have to work on this in the next release. However, check with the release leads and coordinators to align expectations, ensure someone is in charge of this effort, and/or if your help is needed.
The 6.4 email followed the template of previous releases, with some minor improvements in the copy to improve readability and clarity.
The main work for this email consists of updating and identifying dev notes and backward compatibility changes relevant to plugin developers. To do this, you can ask for help from the release squad, such as the documentation folks who are working on the Field Guide and dev notes. In parallel, connect with contributors like Scott, who typically help with this effort. They will be able to offer you further guidance and access to the Plugin Team’s private P2P2 P2 or O2 is the term people use to refer to the Make WordPress blog. It can be found at https://make.wordpress.org/./blog so you can share the draft with them. They will take care of sending the email.
Working with the technology and WordPress-specific media outlets is a relatively new exercise but worth noting in this guide. The main WordPress media, such as the ones that cover almost anything related to WordPress on a regular basis (e.g., PostStatus, WP Tavern, Gutenberg Times), do not necessarily need additional attention or outreach as they are likely already plugged into the day-to-day developments and happenings within the WordPress community. However, connecting with one or more organizations for interviews, articles, and podcasts before and after the release launch is worth considering. Doing so helps nurture a positive relationship with these visible publications.
When engaging with the media, it is helpful to ensure the reporter understands the relationship between WordPress.org and WordPress.comWordPress.com An online implementation of WordPress code that lets you immediately access a new WordPress environment to publish your content. WordPress.com is a private company owned by Automattic that hosts the largest multisite in the world. This is arguably the best place to start blogging if you have never touched WordPress before. https://wordpress.com/, as well as concepts such as semantic version (which the project does not use).
Outside the standard WordPress media are the mainstream tech media, such as TechCrunch and Smashing Magazine. These publications do not regularly cover WordPress releases. However, building relationships with these larger tech pubs can help create additional visibility and goodwill for the WordPress project and community. It’s recommended that you ask the marketing channel and partner with a contributor to leverage any connections with these media outlets, build a PR strategy for the release, and identify some reporters to pitch the release. Here’s an example from 6.1 and 6.2.
Oh, did this guide mention having fun? Being on the release squad is a vote of confidence from the community that you can handle the pressure, pace, and complexity of helping manage an open-source release. It’s a lot of fun, but you must embrace some chaos too. Just remember that this is not heart transplant surgery. No one will die if you skip a step or make a mistake. Ask for help when needed, think ahead, proof your work, and remain calm. And, you’ll become part of internet history, with your byline on announcement posts and credit in the release notes as a contributor and lead.
Well done!
Last updated: