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 aims to serve as an overall summary of the role and processes for the role of Marketing & Communications lead 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:
It’s a living document, so as you move through it, please feel free to update sections. After all, just like the rest of WordPress, the mar/comm processes should evolve and adapt to new trends over time (and so should this document!)
Your work may start sooner than you expect in this role. It will also require a great deal of accuracy, communication, and collaboration. Additionally, you’ll need to bring patience, confidence, and humility to the role. Above all though, don’t stress this role. Like many parts of the WordPress project, there is a community of contributors waiting to help you succeed.
Much of your actual work will begin about a month prior to 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 work on two key items: the About Page and the Beta 1 release post.
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 up until the release day, so it will be easy to fall behind if you are not prepared.
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! There are many people that 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
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.
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/, Automattic, and also concepts such as semantic version (which the project does not use.)
It is also very important to highlight a lot of what goes on “under the hood” in a WordPress release. In other words, all the feature enhancements that went into the release which are not 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 more difficult at times 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 the nearly 20-year-old platform. Along with backward compatibility comes a focus on stability and testing. Additionally, in recent years, a greater emphasis is being 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 what you are doing so they can ask questions and resolve assumptions. Ensure that the Make Marketing team reps know you are the lead and tag you when questions come into the Making WordPress marketing channel, or elsewhere.
Will you miss a release party? Plan ahead and be sure to have a backup represent you and your role 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 be made aware that you’ll be out and have a substitute. If your backup is not familiar with the release process, plan ahead and have that person tag along with you for an earlier release to observe. Typically, anyone on the release squad can serve as a backup but note that they have other responsibilities. There are other members outside the squad who may also have release announcement experience, so just ask around (especially full-time sponsored contributors).
Additional tips:
Plan on ensuring the documents you are creating 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 and editorial support, along with validating content.
The make marketing contributors often provide valuable insight into making sure your post copy is properly internationalized for idioms, for example. Also, be sure to explain times 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 that is 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, such as the recently featuring a release video, and also recently adding more resource links.
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. This can be completed by any contributor, so check first to see that one does not exist by either searching Trac or posting in the release leads channel. It does not require much data when the ticket is created, 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 could also use a refresh as it was last updated a few years ago). This discusses some history of the page as well as what goes into it. Some of the doc references design work as well as the news post. However, between viewing the 6.0 asset and this doc, you should be able to have a good starting point.
The About Page should be completed before RC 1 ships – by at least a few days. RC 1 includes a “hard string freeze”. This means that text copy at this point is locked from further edits so it can be translated by 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/.. 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.
NOTE: If you are including placeholder images in your draft documents, clearly indicate that the image is a placeholder. Either do this by watermarking the image or just 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 would know that the image is not a final one.
It will be your responsibility to create the working doc from scratch (Google doc in the shared drive). You can base it on prior release assets, like this one from 6.0.
You’ll need to 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 by when. For example:
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. It is much easier to make small changes than big ones, of course, so also keep that in mind. Sometimes a change might need to be introduced, discussed, and tabled, so that the release process can continue, and then reintroduced for the next release cycle. This is perfectly okay and a natural part of working in open source. Embrace it!
When sharing the link in any public channel, be sure to clearly state what you are sharing. 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. It’s impossible to know what context (or lens) everyone else is using to read and interpret your comments, so taking extra time to thoughtfully communicate is very beneficial in the project. It also makes it much easier to reference your work in the future.
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 in the developer relations roles 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.
As you move further into the release cycle you will become more familiar with the major features, of course. 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 be shy in asking questions, directing 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 with those two groups (release leads and dev/rel) 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.
Examples of Beta 1 Posts:
Create the template for the Beta 1 post about three weeks prior to the publish date. This will ensure that you can continue to research the features that will be included 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.
Share your first draft with the release leads for feedback. This will give you a little extra time to fine-tune the post before it is shared with a broader audience.
Two weeks prior to publishing, you can then share a cleaned-up version with the release-leads channel and the marketing channel, for input. Remember to set ground rules and timelines for contributing.
You could also create Make Marketing 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/ tickets for each announcement, or just the general release for all docs. In those tickets, you should re-post the “ground rules” for contributing, deadlines, and other pertinent information. Again, remember that contributing to an open source community can sometimes mean sharing information in multiple channels to ensure transparency.
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, there are times when someone in the community may suggest something and 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.
One week prior to publishing, you can then share a final draft in the release-leads channel and then lock the document from editing – just allowing comments.
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, avoiding writing things that might right create risk for the project from a public relations or community relations standpoint.
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 Beta 2 and Beta 3 planned releases. These announcements will be made on make/core so it reaches an audience passionate about the weekly builds. 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 (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 release leads and ask what else should be included if anything.)
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 release 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, which is why it is recommended to create a single placeholder ticket for all docs related to the release.
Release squad leads will take a peek at your shared links, at various schedules and offer candid feedback, both via the channel and via 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:
Over the past few releases, there have been opportunities to produce live sessions to spread awareness for what’s in the release. These insights help build trust and excitement with our developer audiences.
In 6.2 a live product demo was organized to highlight the various features within the release. 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 timing was just after Release CandidateRelease Candidate A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. 1 to ensure that the features shown were the most likely to be within the release itself.
There were two release squad members involved who prepared and presented the demo with the help of a community post. The composition of this squad should endeavor to include community voices as best as possible. 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. Follow up any additional questions with a dedicated Q&A post on /core.
Previous editions called a product walkthrough provided an opportunity for Matias to walk attendees through an outline of the major features. This may be something some folks find useful as a sorting mechanism for t-shirt sizing and as such can be considered although the most recent co-leads contended this format was well organized and more useful for the general WordPress audience. A moderator with podcast or webinar experience truly helps.
In terms of platform, most recently the MarComms co-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. Think ahead about how and where questions can be asked to avoid searching multiple locations for the answers. 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 be worthwhile as well, especially to those folks in time zones where attending live is not convenient. 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 that the release cycle is entering its final phase. As such this post will be made on /news. Posts should include an explanation of what an RC is, a call for testing specific to extenders (theme and pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party 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. Note, on the last point, this was done in 5.8 and 6.0, but not 5.9. This is why when looking for historical context, you should review multiple releases, sometimes as many as five (that’s why this guide includes five release links for each type of post.) For future releases, this may not be entirely necessary, despite the fact it has been done on and off over various releases. Beta one, only one month prior, contains this list. RC 1 is to the same audience, so you could even just link to Beta 1 “for a list of what will be included in the release.”
For the feature recap, it is important to verify with a member of the release squad that the list is still accurate. Your feature list can often be a copy/paste from the Beta 1 post.
You can leverage the same weekly draft and share cadence as you did for the Beta cycles – drafting and sharing 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 releases follow a similar structure to RC 1, with three modifications. First, you can remove the feature list, as you shared it in RC1 (likely a week prior). Second, instead of listing out major issues that have been resolved since the prior milestone, you can opt to simply provide links to Github and Trac queries for issues that are resolved since the prior milestone. Third, these posts will be announced to make/core similar to Beta 2 and 3 posts.
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 are accurately capturing the changes between milestones. It’s not perfectly accurate, as the queries use date ranges, and it is possible 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 out 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 have to do with development processes.
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, then you should consider working with the release squad to also 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 either as they are primarily for the dev and testing communities.
The General Availability or GA post, is the final post in the release cycle, typically. This is the most visible post and requires a significant amount of 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 release checklist you can use for the “big day”.
For the feature summary, you can reuse the material as-is 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, as you can add the images to the Google doc. You can choose to skip this to keep the doc more 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 assets that are not yet available. Here is an example. This helps inform the community that certain parts are still pending.
Be sure to include the timeline and contribution ground rules directly in your document. Once your draft is ready, you can share it in the usual places – release leads and marketing Slack channels, as well as the Marketing Github ticket. Solicit input and highlight areas where you do or do not need assistance.
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 there are 1123 issues and enhancements 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.
There is likely someone on the release squad that is in charge of identifying and compiling 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 day of the release. 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, all you need to do is 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]. Where “X.y” is the version number.
For translation statistics, you can find this data on your own. Visit the Polyglots blog and navigate to the section entitled, “Translations”. For the 90% statistic that is referenced in the 6.0 release announcement, see the “locales” area and then add in the locales that are at 100%, 95%, and 90% to achieve the total metric.
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 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 as well as 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 release and the 6.0 beta 1 release. 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 that 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 that are in the release and a list of props. You cannot use the WPCredits shortcode as you did for the major release, however. 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, very similar to a Beta 2 or RC 2 release announcement.
You will receive the information on the jazz artist a few days ahead of the release date. It is the tradition in the project, and the wish of both Matt and Josepha, 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. In fact, 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. Coordinate with the release lead for design to ensure you have the appropriate images or have them add the image to the release post as well, right after you add the text.
As mentioned in prior sections, you can leverage the Jetpack plugin for auto-posting of milestone announcements directly through the CMS. Just be sure to write unique, Twitter-friendly copy, and include a hashtag.
For the main release announcement, you should disable auto-posting and opt for manual posting by coordinating ahead of time with the Automattic-sponsored marketing folks who currently use a tool called Sprout for managing the official accounts. This way you can further customize the posts and share them across more networks, such as Instagram and LinkedIn. This team can help you with drafting content, finding images, scheduling, and more. You should feel confident in collaborating and delegating to this team as they manage all of the 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 that were 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 which can be used as well. Be sure to tag your posts and label them for the release campaign in Sprout, for internal reporting tracking purposes.
Have the release announcement posts queued up and ready to go (approved by necessary folks) a day or so ahead of 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.0 live product walkthrough event and the recap along with the archived recording. 90 minutes is recommended as prior events were set to 60 minutes and more could have been covered, had time been allotted.
Matias walked attendees through an outline of the major features and shared his thoughts on functionality and the direction of the release via Zoom. Q&A was moderated by members of the dev/rel team who also provided the Zoom webinar license for the event (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/ Times via Birgit Pauli-Haack).
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.
There is a dedicated channel for this event 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 be worthwhile as well, especially to those folks in time zones where attending live is not convenient. In that vein, WordPress did advertise in the post that people could pre-submit questions.
It may also be beneficial to the community and to build excitement around the release to host a second walkthrough during the RC phase of the release cycle. This has not occurred previously but could be considered in the future.
For the past few releases, Josepha has featured a preview of the release as part of her bi-weekly podcast series.
Here are links to the 6.0 release discussion and the 5.9 release discussion.
There’s not a lot of work for mar/comms in regards 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.)
There’s little need to announce the podcast episode ahead of time, and each episode includes its own social media promotion already.
But wait, there’s more! After the release announcement is published, your contributions as mar/comms lead may still continue. Here are some additional responsibilities you may have in the weeks to come:
On release day, share a link to the announcement, along with a personalized note of thanks to the contributors on Slack. If you are a sponsored contributor, you can also share on your company’s Slack workspace.
The Polyglots team will translate the news announcement into many other languages. To assist with this process, you’ll need to send the team the source code from the CMS.
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 developer relations, not to mention the 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 marketing and design teams. For 5.9 ad 6.0, an external contractor was leveraged for the production of the actual video. Given that this requires an expense of money, Automattic has traditionally sponsored this specific project. The mar/comms lead should connect with Automattic-sponsored marketing contributors for this project.
For 5.9 and 6.0, the videos were well-received and experienced a large viewership. Both 5.9 and 6.0 received tens of thousands of views in their first few days.
Find some time to sync up with the Make WordPress Training team and the Automattic-sponsored Andromeda team when it comes to developing short video workshops around new features in the release.
It should be possible to work with both teams and identify at least three to five short video workshops that could be produced using beta or RC software on some of the new features forthcoming. These videos could then be incorporated into release documentation such as the Field Guide, the About Page, and more.
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 real-time via Slack, usually in the #core channel. Release parties are run by the release coordinators and involve the release squad as well as many other contributors.
If you’d like to back scroll and review some release parties, here are a few:
As a release lead, you should attend all release parties, so mark your calendars. You should also 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 ultimately 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 you may have. Once you have a final draft, you should plan on locking 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 provided in this guide to proofread your release, and then share the public preview link in the release-leads channel for final review.
During the party itself, 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, as of June 2022, is nearly two million. 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 the same day as the release 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 that 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 one 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 still 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 of these organizations for special interviews, articles, and podcasts leading up to and after the release launch. Doing so helps nurture a positive relationship with these visible publications.
Outside of the standard WordPress media, there are the mainstream tech media, such as TechCrunch, Search Engine Journal, and Smashing Magazine, for example. 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 that 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 have to embrace some of the chaos too. Just remember that this is not heart transplant surgery. No one will die if you skip a step or make a mistake. The important thing is to ask for help when you need it, 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: