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. After all, just like the rest of WordPress, the mar/comm processes should evolve and adapt to new trends over time.
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 lead. For example, during the 6.3 “Lionel” release, the planning roundup was published on May 18, 2023 (five weeks before 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.)
Five weeks (or more, if you are fortunate) seems like a lot of time. However, you will need every single moment.
First and foremost, if you are leading the release with a co-lead (or even a trio), I recommend holding a two-hour kick-off call to review this document, discuss roles and division of labor/delegation, and so on. It may be wise to have everyone review this handbook before the call.
For 6.3, weekly SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. huddles were held at a time that was as inclusive as possible for all the co-leads. However, everyone must realize that if leads span too broad of a time zone difference, meeting synchronously may be impossible (or at least painfully inconvenient.)
Introduce yourselves on Slack to the release squad members as well since you will be working alongside them for the next several weeks
Much of your work will begin about a month before the Beta 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.
Make sure you complete these tasks before you begin work on the About Page and various release posts. Completing these tasks will 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.
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! Many people can assist you in gaining the knowledge you’ll need. Read as many posts about the release as possible. For example, here are some posts that came out very early in the 6.0 cycle that helped define the release:
Tips
IMPORTANT NOTE: There will likely be about 10 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. However, it is not true that 100% of each Gutenberg release will be merged into core. Therefore, you can only use the “What’s new in Gutenberg” posts as a guide – not a definitive list of what will ship with your release. However, these posts likely contain the bulk of what will eventually ship. Once you build your list of key features, you must validate the list with the release coordinators and the 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.
When engaging with the media, it is helpful to ensure the reporter understands the relationship between WordPress.org, 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/, and Automattic, and also concepts such as semantic version (which the project does not use.)
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 know you are a lead and tag you when questions come into the Making WordPress marketing channel or elsewhere.
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 in various channels. This should include the release leads channel and the #marketing 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.
The make marketing contributors can provide substantial input, editorial support, and validate content.
The make marketing contributors often provide valuable insight into ensuring your post copy is properly internationalized for idioms, for example. 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 and 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 information 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., and credits for the release contributors. The last three 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, recent releases featured a video and included additional links to resources, and 6.3 added a “get involved” tab.
As the mar/comms lead, you can open a TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. ticket for the release about page, similar to the one for 6.0. Any contributor can complete 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 doc for collaborating on content (typically a Google doc), preliminary artwork for the page, discussions around both of these elements, and, ultimately, the final approved materials and source code for the page.
There is also a marketing handbook about the About Page (it is out of date and no longer actively maintained.) This discusses some history of the page’s history and what goes into it. Some of the document references design work as well as the news post. However, between viewing the 6.0 asset and the handbook you are reading now, you should be able to have a good starting point.
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 complete by Beta 2, so that the code can be committed as part of Beta 3. RC 1 includes a “hard string freeze.” This means the text copy is locked from further edits so 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/. 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, at a minimum, and added to the Trac ticket.
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.
You will create the working document from scratch (Google Docs in the shared drive). You can base it on prior release assets, like this one from 6.3.
You should share a link to this document in the release leads and marketing Slack channels. When sharing the doc, it is recommended to provide some ground rules for collaborating and setting clear expectations on what is expected and when. For example:
TIP: When using Google Docs, change the page setup to “pageless” to remove page breaks. These are unnecessary, given that the document will be published online and not printed. Additionally, name versions as you progress through the editing process. For example, looking at the About Page for 6.3 and clicking “versions,” you’ll see various version numbers. These can serve as good reference points for understanding the evolution of the document, noting when it has been reviewed and cleaned up, and so forth.
Before introducing a material change, make sure you can clearly explain the value this change brings, address possible concerns in advance, and prepare to have some discussion. Of course, it is much easier to make small changes than big ones, so keep that in mind. Sometimes a change might need to be introduced, discussed, and tabled so that the release process can continue and 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 post in the release-leads channel about the RC 3 post for 6.0. 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 is an example of the above outline in action for 6.3 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 a challenge. Like the About Page, you can lean on folks who serve in developer relations, release leads, and other project technical areas for their keen insight and visibility into the release specifics. Also, if there is work on a preview walkthrough, that information can help you populate a feature list.
Moving further into the release cycle, you will become more familiar with the major features. However, if you read various dev notes and follow the core channel in Slack, you should be able to read about some of the features to gain a better understanding. Do not hesitate to ask questions; direct them to the release leads (either via DMs or in the release leads channel) or the developer relations folks.
Collaborate on a feature list summary a couple of weeks ahead of the first drafts of the About Page and Beta 1 post. 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 assign or tag authors of various tickets/features so they know you are requesting their assistance to review the technical accuracy of various sections.
Examples of Beta 1 Posts:
Create the Beta 1 post template 3-4 weeks before publishing. 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 while several (sometimes as many as 10) prior versions of Gutenberg will be merged into core, not all the features from the Gutenberg plugin will actually make it into the major release. Therefore, do not rely solely on the “What’s new in Gutenberg” public posts. You must check each feature/ticket in GithubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ or Trac to confirm whether it will be in the major release. You can also 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.” the ticket owner or the release leads for additional assistance.
Share an outline with one or more pre-determined technical liaisons for the release so that the list of highlighted features is 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 with the release leads (again) for feedback and ping specific persons (owners of tickets referenced in the post or team leads for entire sections such as “performance” and “accessibility”) to set expectations on what type of review you need and by when. This will give you extra time to fine-tune the post before sharing it with a broader audience.
When sharing the doc, be specific about who you are seeking feedback from, the type of feedback you seek, and when you need the feedback.
You can share a cleaned-up version with the release leads and marketing channels for input 1-2 weeks before publishing. Remember to set ground rules and timelines for contributing. You can do this when you share the document and list the collaboration parameters in the document itself. For example, in the later review rounds, you may not need feedback on messaging or style/voice. If that is the case, state this clearly.
You could also create Make Marketing Github tickets for each announcement or the general release for all docs. You should re-post the “ground rules” for contributing, deadlines, and other pertinent information in those tickets. Again, remember that contributing to an open source community can sometimes mean sharing information in multiple channels to ensure transparency. While this is not necessarily the most efficient or productive process, it is still expected.
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, someone in the community may suggest something is missing or wrong with a section. You’ll need to understand and decide if the request is a matter of personal preference, historical precedence, and/or even 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.
You can share a final draft in the release-leads channel one week before publishing and lock the document from editing, just allowing comments. Again, When sharing, be very clear about the type of feedback you seek, from whom, and by what time. However, you should have some understanding that feedback may come in at the very last minute. You must be willing and able to accommodate this type of last-minute feedback gracefully and swiftly. That might mean collaborating quickly with folks across the project to determine if the 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.
Feel free to include a link to the live demo walkthrough when appropriate.
Tip: Check all your links. Some links, such as the ones to download the release package, may be case-sensitive. Click all your links to ensure they resolve to the destinations you intend.
Finally, you’ll want to share the announcement code from the CMS in the #Polyglots channel. See the section entitled “Polyglots” below for more information.
The next few release posts will typically cover the planned Beta 2 and Beta 3 releases. These announcements will be made on /news. However, 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 all posts would continue to ship on /news for 6.3.
These two posts will look similar to one another and typically include a call for testing, a list of key fixes with links to their corresponding tickets in GitHub or Trac, links to queried lists of fixes in both repositories and any other important information (ping the release leads and ask 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.
Given the much shorter window for each release after Beta 1, creating a separate Make Marketing Github ticket for each doc may seem a bit excessive, so creating a single placeholder ticket for all docs related to the release is recommended.
Release squad leads will peek at your shared links at various times and offer candid feedback via the channel and DM. 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, you’ll want to share the announcement code from the CMS in the #Polyglots channel. See the section entitled “Polyglots” below for more information.
Examples of Beta 2 & Beta 3 Posts:
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 trust and excitement with our developer audiences and enthusiasts alike.
In 6.2, a live product demo highlighted the various features within the release. Should you want to continue with this type of event, you’ll want to coordinate the date/time, agenda, and moderator ahead of time with the release squad well in advance. For 6.2, the event date was just after RC 1 to ensure that the features shown were the most likely to be within the release. You should plan on confirming logistics about four weeks in advance.
Two release squad members prepared and presented the demo moderated by a community member. Ensuring that the panelists, presenters, and moderators represent the WordPress community as much as possible will ensure the event is well-received. 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.
The event should be announced in a brief post on /news and promoted on official social media channels. The following cadence can be a guide:
In terms of platform, most recently, the mar/comms leads used an Automattic-sponsored Zoom account for WordPress.org. However, live streaming the event onto Facebook or YouTube might be beneficial to reach a wider audience. Irrespective of the platform, a dry run is useful. Consider how and where questions can be asked to avoid searching multiple locations. We recommend using the #walkthrough channel on Making WordPress Slack unless a YouTube live stream is used.
Promotion of this event is key for attendance and should occur 1-2 weeks prior and could include the official WordPress social media channels and Slack channels such as #core, #marketing, #announcements, and others.
Be sure to provide an event outline for the moderator and panelists; here is a sample outline for 6.1. But essentially, here’s a possible flow:
Some follow-up social media with a link to the recording and recap post would also be 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.
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, a call for testing specific to extenders (theme and plugin authors), a call for translation help, and 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 one, only one month prior, contains 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. Draft and share the template the day after the prior release, sharing it in the release leads and marketing channels and, optionally, in Github.
Finally, you’ll want to share the announcement code from the CMS in the #Polyglots channel. See the section entitled “Polyglots” below for more information.
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 for more information.
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!) In the case of 6.0, the original roadmap did not call for a Beta 4 or RC 4, yet the squad decided to add both milestones into the release cycle without changing the timeline for the final release date. The reasons for these decisions will not be covered here as they relate to development and testing processes.
The role of the mar/comms lead was introduced only recently, and therefore, the responsibility of writing and publishing silent release posts remains with the technical leads. Therefore, you may not have much work to do on this task, though you can certainly volunteer to assist with any or all steps.
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. Coordinate with the design lead who worked on the About Page to have them add the images directly into the CMS post after the final draft of the Google doc was complete. This is optional; you can add the images to the Google doc. You can skip this to keep the doc concise for easier navigation and editing.
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 the one used in 6.3. It clearly denotes ordering sections, headings, content to be included, etc. Share this as soon as possible, tag release and core leads, and share in the release squad channel on Slack. 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 and request input by a specific date. Use the same process you used for Beta 1 and the About Page.
Include the timeline and contribution ground rules directly in your document. Once your draft is ready, you can share it in the usual places noted throughout this guide.
Here is an example draft document used for 6.3.
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.0.
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.3”.
For translation statistics, you can find this data on your own. Visit the Translation Stats on the Polyglots Blog for data. For the 90% statistic referenced in the 6.3 release announcement, see the “locales” area and then add up the locales that are at 100%, 95%, and 90% to achieve the total metric.
You will likely be coordinating directly with the design team throughout the release. For the GA post, you will obtain the jazz artist a few days prior to the release date and work with the design team to obtain relevant artwork. Do not add the art to the Google Doc. Instead, draft an intro paragraph and share it with Josepha for approval or someone she designates.
A day before the ship date, move the doc to the CMS and 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. 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 (more on that below in the social media section).
For this announcement, change the post author to the release lead (in 6.3, that was Matías Ventura; 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 for more information.
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 Matt and Josepha’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 directly via Slack as a DM 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 lead for design to ensure you have the appropriate images, or have them add the image to the release post right after you add the text.
As mentioned, you can no longer leverage the Jetpack plugin for auto-posting milestone announcements directly through the CMS. Instead, coordinate with the social media team to manually post announcements.
The social media team manages official accounts for WordPress.org. This team 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 gather animations and images from the release folder used in the About Page and new release. However, you may also engage the design lead on the release squad to request specific assets. Be sure to provide specifics 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. Be sure to tag your posts and label them for the release campaign for internal reporting tracking purposes.
Have the release announcement posts ready to go (approved by necessary 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 download file and news announcement. But it is a good idea to understand that you’ll want to push these live as soon as the news release is published.
Here’s the public post about the 6.3 live product walkthrough event, the recap, and the archived recording. 90 minutes is recommended.
Anne McCarthy, a product wrangler, created this excellent post as a reference doc for folks presenting/moderating.
One or more hosts (typically release leads walk attendees through an outline of the major features and share their thoughts on functionality and the direction of the release via Zoom. A community member typically moderates Q&A. WordPress.org uses its own Zoom license, and you can contact Chloé Bringmann for more information.
Promotion of this event should occur 1-2 weeks prior and could include the official WordPress social media channels and Slack channels such as #core, #marketing, #announcements, and others.
A dedicated channel for this event exists in Making WordPress Slack, #walkthrough.
You’ll want to coordinate the date/time, agenda, and moderator ahead of time with the release leads and project architect. If Zoom is to be used, a dry run is probably unnecessary. 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.
Be sure to provide an event outline for the moderator and panelists; here is a sample outline for 6.1. But essentially, here’s a possible flow:
Some follow-up social media with a link to the recording and recap post would also be 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.
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.
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, and 6.3 discussions.
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 area or theme. For example, the 6.0 release included a guest from the design team (the design lead for the release), and for 6.3, one of the release leads.
There’s little need to announce the podcast episode ahead of time, and each episode already includes its social media promotion.
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 team 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.
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, including marketing, design, and developers.
The primary audience for the video has centered around existing WordPress users to showcase new features debuting in the release versus marketing the entire platform more broadly.
The mar/comms lead will own this project but rely heavily on support and execution from members of the design and developer teams. 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 visual assets as the same teams will create these.
Videos from prior releases:
New in WordPress 6.3, a public-facing microsite showcasing the release, was created through a collaboration among marketers, developers, and designers. It is expected this will be continued for future releases. The microsite is a mashup of the video, visual assets, key messaging (much from the About Page), and general information about WordPress (and how to download the release.)
When the release squad begins, this project should be queued up with the video and visual assets, as they overlap with the same teams and content.
Find some time to sync up with the Make WordPress Training team when developing 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, could be incorporated into release documentation.
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. You can also share it internally on your company’s Slack workspace if you are a sponsored contributor.
Proofreading is important! When you publish the release, it gets emailed to all the folks who have subscribed to the WordPress.org news blog, which is nearly two million as of June 2022. 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.0, 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. Therefore, 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 ensure this process is understood before release day.
Working with the technology and WordPress-specific media outlets is a relatively new exercise but worth noting in this guide. As of 2022, the WordPress project employs a full-time sponsored contributor who focuses part of their time on press and media relations. Therefore, as the release lead, you can collaborate directly with this resource while working openly and transparently.
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, it is worth considering connecting with one or more organizations for special interviews, articles, and podcasts before and after the release launch. Doing so helps nurture a positive relationship with these visible publications.
Outside the standard WordPress media are the mainstream tech media, such as TechCrunch, Search Engine Journal, 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. Therefore, with each release cycle, it is recommended that you partner with the sponsored contributor to build a PR strategy for the release. Together, you’ll identify the key pitch/angle/story you can share and potentially make senior leadership available for exclusive access.
Finally, collaborating with the sponsored PR contributor on a news release that loosely mirrors the WordPress.org news announcement is a typical step in the release communications process. Here is an example from 6.0.
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: