WordPress.org
Get WordPress
WordPress.org

Make WordPress.org Marketing

Marketing & Communications Release Cycle Guide

Marketing & Communications Release Cycle Guide

In this article

↑ Back to top

Overview

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:

  • Timelines
  • Processes
  • Documents / Assets
  • Resources
  • Points of Contact
  • Strategy
  • Tips for Success

This is a living document. Therefore, it’s expected to be updated to reflect the evolution of the role and processes regarding release communications. If you are helping lead (or co-lead) a release’s marcomms, please plan on updating this document as needed and reviewing it upon shipping the release to ensure it remains accurate.

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.

Planning and preparing

Your work and responsibilities begin when you are announced as a mar/comms lead, usually about a month before the BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 release. At that time, you’ll start working on two key items: the Beta 1 release post and the About page. These two assets will share content.

Before beginning work on the About page and the release posts, plan and prepare tasks, as that will help set you up for success early. Things can move quickly and tend to accelerate until the release day, so it will be easy to fall behind if you are unprepared. The following are some tasks to keep in mind for the planning phase:

  • Project overview/plan – Here’s an example from 6.5. This is useful to communicate and align expectations about what is part of the mar/comms role and what is planned to happen. By building and sharing this timeline, you can indicate due dates, milestones, and DRIsDRI Directly Responsible Individual – the people who are taking ownership or responsibility for a particular project or feature. (directly responsible individuals.) Include dates for drafts, feedback, etc. While that may seem like overkill, it is very helpful for communicating your obligations and expectations. You can consider making this a public post or a 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/ issue in the Marketing repo to allow the community to understand and follow the release work and docs.
    • Hold a kick-off call with your co-leads to review the project plan and this handbook, discuss roles and division of labor, assign DRIs, etc. Have everyone review this handbook before the call and set expectations regarding the release work.
    • Set up weekly or regular async or sync check-ins to ensure that work and assets are moving along and there are no blockers.
  • Consider opening a mar/comms 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/. channel for the release. In 6.4, the mar/comms squad moved their conversations to a new #6-4-marcomms channel (instead of keeping them private/in DMs) to work more openly and allow other contributors to observe, learn, and/or collaborate.
  • Templates – It’s never too early to prep templates for releases and other assets. This can save a lot of time and make your processes more efficient. Doing prep work early when you do not have any public deliverables means a little less work when you are in the depths of the weekly releases. You can create a public Google Drive folder to store announcements/posts, images, etc. Including a shortcut to the previous release can also prove helpful in getting started on the current release. Here’s the folder for 6.3 and the one for WordPress 6.4.
  • Outreach to others involved in the release – Your name as a release leadRelease Lead The community member ultimately responsible for the Release. will be published in the planning roundup, and it is recommended to introduce yourselves and connect with other release squad members, coordinators, and contributors in the Make WordPress Slack workspace since you will work alongside them. Additionally, you’ll want to be sure to join the following channels in that workspace:
    • 6-4-release-leads (or the name of your release) – This is where you will interact with the release’s primary leads. It is very important that you remain active and engaged (and responsive) in this channel.
    • Core – Where the magic (and release parties) happens.
    • Walkthrough—In some releases, mar/comms help organize a live demo event to showcase key features expected to debut in the release. See this section below for more information. This channel coordinates logistics for the event. (This event has been deprecated as of 6.4.)
  • CMS access – To ensure your processes run smoothly, upon taking the mar/comms lead role, you should confirm you have access to the CMS and can create and publish posts to the /news/ and /coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress./ sites. The release squad members and a MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. team member can typically assist you with this permission.
  • Familiarize yourself with writing for the WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ brand. Read and reference the WordPress.org Brand Writing Style Guide before and as you draft or review any release-specific content. This will help ensure consistency across channels in communications and marketing materials.
  • Use a proofreading tool such as Grammarly or similar to improve your writing. However, do not rely solely on automated proofreading tools, as they do not always work with technical writing or complex software concepts. You can also rely on manual proofreading techniques, such as rereading a document out loud for flow and clarity.
  • Release research (see below)

Release research

Writing about the release requires that you know what is going into the release. This can be one of the most challenging things about the role of the mar/comms lead. Don’t sweat it! Read as many resources about the release as possible. You will also want to review GitHub and Core TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. tickets, partner with other contributors, and collaborate with release squad members to gain the needed knowledge. Here are some posts/resources that come out early in the release cycle and are good to have on your radar:

Tips:

  • Bookmarking all these URLs and releasing resources is useful for easy reference.
  • You can subscribe to the Make Core blog via email to receive alerts for new posts. Note that this blog receives frequent posts, but it’s easy to glance over to see what you need and don’t.
  • Collaborate with contributors who serve in product roles and help create the source of truth doc (like Anne McCarthy) to learn more about key features slated for the release. They will be one of your best resources and typically are very close to the release process, understand the development cycle, and have a good idea of what to expect in the release.

IMPORTANT NOTE: There may be around 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. The “What’s new in Gutenberg” posts can be a nice guide to learn about some features planned for the release, but they are not a definitive list of what will ship with your release. Not all of the Gutenberg features will merge with core. Once you build a list of key features, you must validate it with product contributors, release coordinators, and leads from core, at a minimum. More on this below.

Communicating release value 

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 media folks who often report on the release. For example, 6.3 (Lionel) was the “official” end of the major work in Phase 2.

It is also important to highlight what goes on “under the hood” in a WordPress release. In other words, all the feature enhancements that went into the release are not all design/UIUI UI is an acronym for User Interface – the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing.-related or feature-based. These are sometimes more difficult to communicate because they are not always visible to everyday users. For example, each release has a lot of time and attention devoted to backward compatibility, a hallmark of WordPress. Along with backward compatibility comes a focus on stability and testing. Additionally, in recent years, a greater emphasis has been placed on accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) and performance. All of these topics should be addressed in release communications.

Maintaining visibility and accountability

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 release and other contributors know you are a mar/comms lead and can tag you when questions come.

  • Provide regular updates in relevant channels.
  • Be supportive and show your passive presence with emojis.
  • Comment on posts in the release channel.
  • Attend dev chats.
  • Attend all release parties.
  • Reply to all DMs and mentions promptly.
  • Communicate your availability and keep your Slack status(es) updated with AFKs, etc.
  • Have fun!

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:

  • Always be confident to speak up and ask questions to clear up assumptions. 
  • Ask for specifics and clarity when needed. 
  • Verify dates and information.
  • Seek concrete commitments.
  • Communicate regularly. 
  • Always assume positive intent.
  • CC/tag/mention your co-leads whenever possible.

Editorial support and reviews

Plan to ensure the documents you create are shared with the community and co-leads in various Slack channels. This should include the release mar/comms channel (if you set up one) and the release leads channel. The #core channel can also be appropriate. Developer input should always be welcome as that is a good perspective to help validate the content of a release document.

Marketing contributors can provide editorial support and review to ensure your post copy is clear and follows the Brand Writing Style Guide. 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.

About Page

**This asset is currently under review for 6.6/6.7. Therefore this content may be out of date… Refer to the Making WordPress Slack workspace and the 6.6 release squad channel for updates.**

The “About page” is a reference page displayed to admin users in the WP-Admin dashboard post-upgrade. The content on this page generally focuses on key features introduced in the release. It includes resources for finding more information about updates and features, such as the release notes documents, developer tickets, and so forth. The page also has sections on WordPress privacy, the freedoms of open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL., credits for the release contributors, and how to get involved. These four sections seem to remain relatively unchanged from release to release. However, it is reasonable to iterate improvements to the main part of the page by reorganizing the content a bit. For example, some releases featured a video.

Open a Trac ticket for the release About page, similar to this one for 6.4. Any contributor can do this, so check first to see if one does not exist by searching Trac or posting in the release leads channel. It does not require much data when creating the ticket, as it is a placeholder. This ticket will store links to the draft working docs for collaborating on content and design (e.g., a Google doc and a Figma file), preliminary artwork, discussions around the page, and the final approved materials and source code.

Create a working document (a Google doc in the shared drive). You can base it on prior release assets, like this one from 6.5 or 6.4. As you work on your content, collaborate with release and product contributors to ensure that you are clear on the key features to prioritize and the accuracy of the copy.

NOTE: If you include placeholder images in your draft documents, clearly indicate they are placeholders. Either watermark the image or use a color blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. that says “placeholder.” It is important that anyone viewing the working documents knows that the image is not a final one.

Share it for review and feedback. Once you have a draft, share a link to this document in the Trac ticket and with the release leads and mar/comms contributors. When sharing the doc, provide some ground rules for collaborating and set clear expectations on the feedback expected and when (this applies to all release documents). For example:

  • Contributors should track all changes using Google Docs’ “suggesting” or “commenting” features unless the change is self-explanatory, like correcting a minor typo.
  • Add comments using the “comments” feature 
  • Contributors should be identifiable and not anonymous
  • Provide a timeline, such as:
    • Initial input/content due by week 1
    • Doc is then cleaned up and revised by you
    • 2nd round of input is due by week 2
    • Doc is then cleaned up and revised by you
    • Final draft by a certain day; the doc is locked from editing, and contributors may only comment. During this time, you are reviewing for technical accuracy and editorial flow.
    • The whole process can take weeks or a month during the beta cycle.

Collaborate with design contributors. Collaborating closely with design contributors is important as you finalize the content. The About page usually follows specific layouts, so the copy will likely need changes as contributors work on its design, such as tweaks to avoid orphans and widows, shorten some sections, etc.

Timeline: The About page should be completed one week before 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. It is recommended by core committers that the content be completed by Beta 2 to allow for time for feedback and design to work out the layout. RC 1 includes a “hard string freeze.” This means the text copy is locked from edits so Polyglots can translate it. The only changes made to the doc after RC 1 should be changes that correct factual errors – and if so, those changes should be communicated in the release leads channel and added to the Trac ticket.

Tips: In Google Docs, you can change the page setup to “pageless” to remove page breaks since they are unnecessary for this document. Also, you can name versions as you progress through the editing process and/or add a changelog to the doc to help track changes and understand the evolution of the document.

For more context on the About page asset, this handbook page discusses its history and what goes into it, referencing the design work and the news post. However, note that it is outdated and no longer actively maintained. By viewing recent About page examples and the guide you are reading now, you should have a good starting point. If you need more information or guidance, ask previous mar/comms co-leads.

Notes on iterating assets

Before introducing any change, make sure you can clearly explain the value it brings, address possible concerns in advance, and prepare to have some discussion. Of course, it is much easier to make small changes during the release cycle than big ones, so keep that in mind. Bigger changes might need to be introduced, discussed, and tabled so that the release process can continue and be reintroduced for the next release cycle. This is perfectly okay and a natural part of working within open source. Embrace it!

Setting expectations

When sharing the link in any public channel, clearly state what you share. Explain the process and resources you used to produce the document. This helps to provide context to the community on how you made your decisions. Here’s an example of the RC 3 post for 6.0 in the release leads channel. Knowing what context (or lens) everyone else uses to read and interpret your comments is impossible, so taking extra time to communicate thoughtfully is very beneficial in the project. It also makes it much easier to reference your work in the future.

Pre-release announcements (template)

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, an updated template/format was used as the basis for all the Beta and RC posts. While posts will still vary from one to the next, following this general structure should create consistency and efficiency.

  • Title
  • Intro
  • What’s new / Highlights (H2)
  • Ways to contribute (H2)
  • (B1/RC1 only) A snippet about open source
  • How to get the release/build (H3)
  • Search for vulnerability (H3)
  • (RC only) Update your 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 and/or theme (H3)
  • (RC only) Help translate WordPress (H3)
  • Haiku (H2)
  • Credits

Here’s an example of the above outline in action for 6.3 RC3 and another similar example for 6.4 RC3.

Beta 1 announcement

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.

It is challenging to fine-tune the list of what will be in the release. Like the About page, lean early on folks who serve in product roles and other project technical areas for their keen insight and visibility into the release specifics.

Collaborate with them on a feature list summary and get clarity on priority features ahead of the first drafts of the Beta 1 post and About page. This will help you get consensus/buy-in on the list and reduce the back-and-forth during the drafting, editing, and publishing processes down the road. You can also tag authors of tickets/features so they know you are requesting their assistance. If there’s work on assets like the highlight grid, that information can help, too.

By researching various GitHub/Trac tickets and following the core channel in Slack, you should also be able to learn and gain a better understanding of each feature. Do not hesitate to ask questions. Moving further into the release cycle, you will become more familiar with the major features.

Examples of Beta 1 Posts:

Create a Beta 1 post template 3-4 weeks before. This will ensure that you can continue researching the features in the announcement. Later announcements will benefit from the early preparation of the Beta 1 announcement. Therefore, your drafts of the other milestone announcements can likely follow a shorter window.

It is important to note that numerous versions of Gutenberg are merged into core for a major release. Still, not all the features from the Gutenberg plugin may make it into the release. It can also happen that during the release cycle, some features initially slated for the release require further testing and are punted to the next major release. You are expected to be proactive by regularly checking and understanding what goes into the release. Read the release leads Slack channel for updates, review relevant tickets on GitHub or Trac often, and confirm with release contributors about any features before their inclusion in the Beta 1 post or other release assets.

Share an outline of the Beta 1 post with the product or technical liaisons for the release to ensure the highlighted features and messaging are accurate. After your first draft, once you have received feedback and cleaned the doc up, re-share the document to confirm technical accuracy.

Share your next draft, 1-2 weeks before publishing, with the release leads for feedback and pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” specific persons (owners of tickets referenced in the post or team leads for entire sections such as “performance” and “accessibility”) to help review the information. This will give you extra time to fine-tune the post before sharing it with a broader audience.

Tip: If someone suggests that you add/remove/edit something in the post, you should attempt to verify the request (e.g., fact-check). Obviously, if the request comes from a release lead, it likely can be highly trusted for accuracy. However, contributors sometimes suggest something is missing or wrong with a section. You’ll need to understand if the request is a matter of personal preference or historical precedence and/or if necessary. It’s always fine to ask for clarification as to why the suggestion is being made and to verify it with a member of the release squad.

Remember to set ground rules and timelines for contributing when sharing the document. Be specific about who you seek feedback from, the type of feedback you seek, and when you need it. See more tips in the About page section above.

You can reshare a final draft in the release leads channel and lock the document from editing before publishing, just allowing comments. However, you should understand that feedback and some data/stats may arrive at the last minute. You must be able to accommodate last-minute feedback and collaborate quickly with folks across the project to determine if any change is necessary.

An announcement tradition: Release posts have included historical quotes or poems (such as Haiku) at the end of the announcement. This keeps with the casual and fun tone of the WordPress project. Although well-received by the community, it is optional. Whatever you do, be sure that what you write is consistent with the voice of WordPress and can be universally accepted. In other words, avoid writing things that might create risk for the project from a public or community relations standpoint.

Tips: Enable the public preview after moving the post to the CMS so folks can review it during the release party. Check/click all your links to ensure they resolve to your intended destinations. Some links, such as the ones to download the release package, may be case-sensitive. See this checklist for announcement posts for more tips.

Feel free to include a link to the live demo walkthrough when appropriate. Finally, you’ll want to share the announcement code from the CMS in the #Polyglots channel. See the section entitled “Polyglots” below.

Beta 2 and beyond

The next few release posts will typically cover the planned Beta 2 and Beta 3 releases. These announcements will be made on /news. Some prior releases (6.2, for example), these were shipped to /core. However, it ultimately was decided that posts would continue to ship on /news.

These two posts will look similar and typically include a call for testing, links to fixes in GitHub and Trac, a list of key fixes with links to their corresponding tickets when needed, and any other important information (ping and ask the release leads what else should be included if anything.)

Use the general template shared above in the Beta 1 section of this guide.

Given the typical milestone release cadence (weekly), it is recommended that the release announcement template be drafted and shared the day after the prior release. So, if a release announcement for Beta 1 happens on the 1st, you would draft and share the Beta 2 announcement on the 2nd. Things move fast!

You’ll then want to update the post the morning of the release party with the latest statistics and re-share the link with the release squad for a final technical check. Release squad leads will peek at your shared links at various times and offer feedback. They are very helpful with verifying queries for counts of issues resolved, helping you identify key tickets or issues you should include, and general proofreading. Feel confident in asking questions, as folks will be willing to help.

Finally, remember to share the announcement code from the CMS in the #Polyglots channel. See the section entitled “Polyglots” below.

Examples of Beta 2 & Beta 3 Posts:

RC 1 announcement

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 explain what an RC is and the different ways to contribute, including a call for testing specific to extenders (theme and plugin authors) and a call for translation help. It can also include a recap of what is expected in the release from a high-level feature standpoint. Consult the outline shared in the Beta 1 section for additional guidance. While referencing/reviewing prior release posts is helpful, the most recent post typically reflects accumulated edits to processes and structure. Therefore, use the most recent post as the primary point of reference for structure.

Beta 1, released only one month prior, may contain a good list of features you’ll want to recap in RC1. You can also link back to RC1 rather than simply copy/paste. For the feature recap, it is important to verify with a member of the release squad that the list is still accurate.

You can leverage the same weekly “draft and share cadence” as you did for the Beta cycles. Share the draft the day after the prior release for review and feedback.

Finally, you should share the announcement code from the CMS in the #Polyglots channel. See the section entitled “Polyglots” below.

Examples of RC 1 Announcements:

RC 2 and beyond

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 must 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 should share the announcement code from the CMS in the #Polyglots channel. See the section entitled “Polyglots” below.

Examples of RC 2 and RC 3 Announcements:

Unplanned “silent” betas and RC milestone releases

Sometimes, the release squad determines the need for an extra milestone release as part of the beta or RC cycle (or both!). The original roadmap usually doesn’t include a call for extra milestones like Beta 4 or RC 4. Yet, the squad sometimes needs to add these milestones into the release cycle, which usually does not change the timeline for the final release date. Their reasons regarding development and testing processes will not be covered here. 

Sometimes, the responsibility of writing and publishing silent release posts remains with the technical leads. Therefore, you should ask and verify before working on a draft.

These are called “silent releases,” and publicly announcing them on the /news/ blog is not required. Instead, it is recommended that they be shared on the /core/ Make WordPress blog. Incidentally, if you have made it this far into this guide, you should consider working with the release squad to obtain access for posting in the CMS on the Make Core blog.

Examples of Silent Release Announcements:

Despite not being publicly announced, the silent releases can typically follow the same formats as other posts. If the silent release addresses a specific issue or set of issues, a small section detailing the issue(s) may be relevant.

Silent releases need not be announced on social media, as they are primarily for the dev and testing communities.

GA post

The General Availability (GA) post is typically the final post in the release cycle. It is the most visible post and requires significant preparation, similar to the Beta 1 post. The good news is that there are well-defined examples from prior releases.

Sample GA Announcements:

Here is a sample release checklist for the “big day.”

For the feature summary, you can reuse the material from the About page, including the visuals. For releases like 6.3, 6.4, or 6.5, more specific visual assets were created for the /news posts (here’s an example). Coordinate with the design contributors who work on the About page and other creative assets to help you with assets and, optionally, have them add the images directly into the CMS post after the final Google doc draft is complete.

It’s recommended that you start work on this post at least three weeks before publication, with the first week spent compiling all the sections. Use obvious placeholders tagged with comments for links, queries, images, or other unavailable assets.

Share an outline first, like this or the one used in 6.4. It denotes ordering sections, headings, content to be included, etc. Share this with your co-leads and other release squad members on Slack as soon as possible. TagTag Tag is one of the pre-defined taxonomies in WordPress. Users can add tags to their WordPress posts along with categories. However, while a category may cover a broad range of topics, tags are smaller in scope and focused to specific topics. Think of them as keywords used for topics discussed in a particular post. specific people if you need input by a specific date. Use the same process you used for Beta 1 and the About Page.

Once your first draft is ready, you can share it in the usual places noted throughout this guide. Include the timeline and contribution ground rules directly in your document. Here is an example draft document used for 6.4 and the one used for WordPress 6.5.

You can perform a few rounds of editing, with timelines for contributors to provide input. Then, you can clean up the document and request release leads to fact-check any particular areas.

Be sure to obtain a tentative final ticket count from the release leads and leave some wiggle room to avoid accuracy issues. For example, if 1123 issues and enhancements are completed, you could say “more than 1000” or “1000+”. This gives you some room. The media will likely use this figure, so it’s important it holds up.

Someone on the release squad will likely identify and compile the list of contributors. You can get an estimated count from this person and use the same strategy, such as “more than 500”, etc. It would be prudent to check in with the person providing the count to confirm that the list is accurate on the release day. There are some last-minute list “cleaning” activities where some contributors may be removed or added. Therefore, keep your estimate broad. Here’s an example of the spreadsheet that was used for 6.4.

To include the full list, you only need to use the “shortcodeShortcode A shortcode is a placeholder used within a WordPress post, page, or widget to insert a form or function generated by a plugin in a specific location on your site.” block in the CMS and add the following shortcode: [wpcredits X.y]. “X.y” is the version number, such as “6.4”.

For translation statistics, you can ask 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/. to help. According to this Polyglots Slack thread, you should 1) look at the locales listed at least 75% or more in the /admin/ translate project and 2) look at locales listed at least 90% or more in the /dev/ translate project. Then, only count the locales that are on both of those lists to get the number. Since this is a somewhat tedious task, you can use tools such as ChatGPT to check the number of locales with such requirements in both lists. If you see the total number is 63, keep it estimated (e.g., “more than 60 locales).

For the GA post, you will obtain the jazz artist a few days before the release date and work with design folks to obtain relevant artwork. Do not add the art or the name to the Google Doc. Instead, draft an intro paragraph and share it with project leadership (Josepha) for approval or someone she designates.

A day before the ship date, move the doc to the CMS, set up all the metadata, upload the images to the media library, format, and proofread. Then, you’ll share a public preview with the release squad for final feedback.

During the release party, turn off the public preview and update the draft in the CMS. Then add in the jazz artist info and image(s). You are now ready to ship!

The GA announcement should feature an image (the jazz artist), and it is recommended that you turn off the Jetpack social sharing if it’s not already turned off (more on that below in the social media section).

For this announcement, change the post author to the release lead (in 6.4, that was Josepha; in prior releases, it was Matt Mullenweg.)

Update the slug to include only the name of the release jazzer, not the release number.

Finally, you should share the announcement code from the CMS in the #Polyglots channel. See the section entitled “Polyglots” below.

Notice on the timing of shipping assets on release day

Three assets have some shared dependencies. Accordingly, they need to ship simultaneously (or within a few seconds of one another. It is best to coordinate this ahead of time. These assets are:

  1. Homepage of WordPress.org (contains new content specific to the release)
  2. The microsite
  3. The announcement post

These often link, so ensure you know they are publishing together.

Minor “dot” releases

After the major release, work will quickly pivot to future releases, including the next major release and one or more minor and maintenance releases. WordPress development is global and 365/24/7 – it never sleeps!

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. In recent releases such as 6.3 and 6.4, the mar/comms leads have not been asked to assist with communications for minor releases. So, this does vary from release to release.

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 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. 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 can request social media amplification of a minor WordPress release announcement using the “Request for Minor Release Amplification” GitHub form.

Jazz artists

You will receive the jazz artist’s information a few days before release. It is the project’s tradition and the project leadership’s wish to keep this information as confidential as possible. Some people will know, but only those doing work around release documents.

Do not add the jazz information to the Google doc, CMS, or any other public space. Do not share it over Slack, even in a DM, if possible. You will draft the jazz section of the release announcement locally on your laptop and then share the passage for approval privately with Josepha (Josepha is the one who will share the information with you initially.)

On release day, a few minutes before publishing the release, you can add the passage into the CMS after disabling the public preview. Once you have the jazz artist information, coordinate with the release leads or design contributors to ensure you have the appropriate images on time for the release announcement.

Checklist for Announcement Posts

  • Check links (some downloads may be case-sensitive)
  • Ensure the post has the right 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. and alternative text
  • Preview the post yourself to review formatting/layout (check on desktop and mobile)
  • Proofread and use a spell check utility such as Grammarly
  • Check your excerptExcerpt An excerpt is the description of the blog post or page that will by default show on the blog archive page, in search results (SERPs), and on social media. With an SEO plugin, the excerpt may also be in that plugin’s metabox.
  • Enable public preview and share that link with the release leads in Slack so they can preview the release announcement (with NO jazz info in the final post announcement)
  • Have the release leads verify your queries for accuracy
  • Have a technical lead verify your descriptions of features/tickets
  • Tags
    • For milestones, your tags should be development, releases, [release-number]
    • For the main release, your tags should be releases, [release-number]
  • Categories
    • Development, Releases (only releases for the final post announcement)
  • Jetpack social settings
    • As of mid-2023, Jetpack no longer works with Twitter. Therefore, it is recommended that social posting be disabled and that you coordinate with social media folks to amplify the post on social media.
  • For the GA announcement, change the author to Matt (or the release lead) and remove the release number from the slug
  • Share the announcement code from the CMS in the #Polyglots channel. For more information, see the section “Polyglots” below.

Social Media

As mentioned, you can no longer leverage the Jetpack plugin to auto-post milestone announcements directly through the CMS. Instead, coordinate with social media contributors (typically Brett McSherry) to manually post release announcements.

The social media contributors manage official accounts for WordPress.org. They can help you draft content, find images, schedule, and more. As they manage all official WordPress social media accounts, you should feel confident collaborating with and delegating to this team.

Open a ticket in the Marketing Github repository to track your work on social media content, including requests for copy and visual assets. Coordinate with the contributors who manage social media by opening a Request for Amplification ticket for the release in the Marketing GitHub repository. You need not create an issue for each post, just the release. You can use that single ticket to track work.

As part of the release communications, you will want to develop a social media posting plan (similar to WP 6.4 Social Drafts)—or ask social media managers to create it for you—to promote the release milestones and key features. A good starting point is to begin promotions (beyond the release milestones) about two weeks before the GA announcement.

Design contributors’ images, such as the highlight grid or “coming soon” assets, can be used for social media purposes. Collaborate with them during the release (more on the section below), follow design work, and request specific assets when needed. Be sure to be proactive, provide specifics as soon as possible, and allow for ample time.

If a video accompanying the release is available, that can be used on social media. Sometimes, the main video is also sliced into segments that can be used.

Have the release announcement posts ready (approved by necessary social media folks) a day or so before the release. You may have to update them with information about the jazz artist and provide links to the landing page and/or news announcement. But it is a good idea to understand that you’ll want to request these live as soon as the news release is published.

Release design assets and microsite

As mentioned above, it’s important to coordinate and partner with the release design contributors and helpers as soon as possible, as they will create different creative assets that mar/comms will contribute to and leverage for social media purposes. In 6.4 and 6.5, for example, there were different GitHub tracking issues for each asset, including:

Jazz artist’s assets are handled differently, but you should also remember them.

Open GitHub tracking issues for all the visual release assets you anticipate needing as soon as possible and communicate this request in the release squad Slack channel so that the design leads are aware.

Additionally, since WordPress 6.3, release design, developers, and marketing contributors have worked on a public-facing landing page for the release (microsite). See 6.3, 6.4, and 6.5 sites. It is expected this will be continued for future releases. The microsite features short videos, visual assets, key messaging (much from the About page), and other relevant information about the release (with call-to-actions to download the release). Sometimes, expanding and adjusting the landing page copy might be necessary. Mar/comms should help ensure consistency with the rest of the release messaging and deliverables. These are the GitHub issues where work happened for collaboration on the microsite:

When the release squad begins, this work and design assets should be queued up with the video, if there’s one, as they might overlap with the same contributors.

The content (copy and visual assets) for the About Page and the Microsite can be the same. Furthermore, this same content can also be used for the GA Release Announcement.

Live product walkthrough

For some releases, such as 6.1, 6.2, and 6.3, there have been opportunities to produce live sessions to spread awareness for what’s in the release ahead of time in a more visual/interactive manner. These events help build excitement with our developer audiences and enthusiasts alike. For 6.4 and 6.5, there was no product demo or walkthrough. This is up to the release squad and should be publicly discussed as release planning begins.

In these live product demos, one or more hosts (typically release members of the squad) walk attendees through an outline of the major features and share their thoughts on functionality and the direction of the release. Should you want to continue with this type of event, you’ll want to coordinate the following with the release squad well in advance.

Date/time: For some releases, the event date was just after RC 1 to ensure that the features shown were the most likely to be within the release.

Moderator and presenters/hosts. Ensuring that the moderator and presenters or hosts represent the WordPress community as much as possible will ensure the event’s well-received. Anne McCarthy, a product wrangler, created this excellent post as a reference document for folks presenting/moderating.

Agenda and outline: You must also provide an event outline for the moderator and presenters; here is a sample outline for 6.1. But essentially, here’s a possible flow:

  • Welcome, intro, housekeeping Zoom (5 minutes)
  • Product walkthrough (40-50 minutes)
  • Panelists’ intro/comments (10-20 minutes)
  • Q&A (20-30 minutes)
  • Closing remarks

Duration: Allow 60 minutes, as attention spans wane after a while. However, some releases may merit up to a 90-minute session because of question-and-answer times.

Logistics: You should plan on confirming logistics about four weeks in advance. WordPress.org uses its own Zoom license, and you can contact Chloé Bringmann for more information. However, live streaming the event onto Facebook or YouTube might be beneficial in reaching a wider audience. In that case, some additional prep work may be worthwhile. Irrespective of the platform, a dry run is useful. Consider how and where questions can be asked to avoid searching multiple locations.

A dedicated channel for this event exists in Making WordPress Slack, #walkthrough.

Promotion: Promotion of this event is key for attendance and should occur 1-2 weeks prior. Announce the event in a brief post on /news and promote it on the official WordPress social media channels. You can include regular reminders in channels such as #core, #marketing, and #announcements. Follow-up social media posts with a link to the recording and a recap post are also worthwhile, especially for folks in time zones where attending live is inconvenient. In that vein, WordPress did advertise in the post that people could pre-submit questions.

Here’s the public post about the 6.3 live product walkthrough event, the recap, the Q&A follow-up post, and the video on YouTube.

Hosting a second walkthrough during the RC phase of the release cycle may also benefit the community and build excitement around the release. This has not occurred previously but could be considered in the future.

The release video

Some releases may include a video trailer or overview. 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 internally and then publicly the day before the release, along with the release embedded into the About page and news release, among other places such as social media and YouTube.

Video is a newer and evolving element of release communications, involving many teams of contributors, including marketing, design, and developers.

The video’s primary focus is to showcase new features debuting in the release. The mar/comms lead will coordinate this project, relying heavily on support and execution from design and developer contributors. An external contractor produced the video for 5.9 and 6.0.

Planning for the video should begin when the release squad is announced, before Beta 1, and should coincide/overlap with coordination on design assets.

Videos from prior releases:

Podcast: WP Briefing

Josepha has featured a preview of the release for the past few releases as part of her bi-weekly podcast series. Here are links to the 5.9, 6.0, 6.3, and 6.4 episodes.

There’s not a lot of work for mar/comms regarding 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 before the release to help build momentum and excitement around the release. The podcast topic can also focus on a particular topic and/or include guests from the release squad.

After the release

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:

  • Sharing the release announcement on Slack the same day (see the section below)
  • Release retrospective (providing feedback to the release coordinators)
  • Your retrospective 
  • Share suggestions to update this document with new information/learnings/tips
  • Share the release code (from the CMS) in the Polyglots channel for translation (see separate section below)
  • Checking in for support on minor/patch releases as needed via Slack (see the section on minor releases)

Slack announcements

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.

  • Making WordPress

Polyglots

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.

  • Log into the CMS and go to the release announcement post
  • In the editor, click the triple dot menu in the top right corner and select “copy all blocks”
  • Paste that content into your notepad or a similar notes app, and save the file as a binary file (not RTF or doc, as you do not want any formatting.)
  • Visit the Polyglots Slack channel
  • Share a brief announcement about the release with a link to the URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org and attach this file explaining it is the source code for the release announcement.
  • If you have trouble creating the attachment, you can copy/paste the source code as a “code block” in Slack. However, you must split the post into at least two parts due to Slack’s character limitations.

LearnWP

Find some time to sync up with the Make Training team to know if they are developing any short video workshops around new features in the release.

It should be possible to work with them and identify at least 3-5 short video workshops on some of the forthcoming new features that could be produced using beta or RC software. These videos, such as the Field Guide and About page, can be incorporated into release documentation. Here’s an example from the 6.4 release notes/documentation page.

Self-hosted statistics

Some good data around self-hosted WordPress usage may be sometimes helpful when writing and communicating about the release.

Release parties

Release parties typically last about an hour and occur on the days of milestone releases (betas, RCs, etc.). They occur in real-time via Slack, usually in the #core channel. The release coordinators run the 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, which 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 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 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. 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, the party lead will prompt you to publish the announcement.

Proofreading is important! When you publish the release, it is emailed to everyone who subscribes to the WordPress.org news blog. Are you nervous yet? A typo or wrong link will then be emailed to those folks. While you can easily correct the post itself, you cannot retroactively update the email that goes out.

Release notes

Release notes, like these for 6.4, are also published on the same day as the announcement. There’s a bit of a circular reference because the release notes link to the news announcement, and the news announcement links to the release notes.

The announcement should have precedence. Ideally, the release notes should be published first so the news announcement can include a link to the notes. The notes page can then be retroactively edited to include information on the jazz artist, a download link, and a link to the news announcement. Coordinate with the release leads to align and coordinate this process before release day.

Email to plugin authors

For 6.4, mar/comms contributors were asked to help with the email sent to plugin authors after RC1 (once most of the dev notes and the Field Guide are published). This does not mean you must work on this in the next release. Check with the release leads and coordinators to align expectations, ensure someone is in charge of this effort, and/or if your help is needed.

The 6.4 email followed the template of previous releases, with minor improvements in the copy to improve readability and clarity.

The main work for this email consists of updating and identifying dev notes and backward compatibility changes relevant to plugin developers. To do this, you can ask for help from the release squad, such as the documentation folks working on the Field Guide and dev notes. In parallel, connect with contributors like Scott, who typically help with this effort. They can offer you further guidance and access to the Plugin Team’s private P2P2 P2 or O2 is the term people use to refer to the Make WordPress blog. It can be found at https://make.wordpress.org/./blog so you can share the draft with them. They will take care of sending the email.

Final thoughts

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, think ahead, proof your work, and remain calm. 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!

First published

Last updated

WordPress.org
WordPress.org
Code is Poetry
s
search
c
compose new post
r
reply
e
edit
t
go to top
j
go to the next post or comment
k
go to the previous post or comment
o
toggle comment visibility
esc
cancel edit post or comment