WordPress Documentation Team Closes 200+ Issues — and Needs Your Help

The documentation team needs help, especially from coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., themes, and support contributors. As part of an overhaul, the Documentation Team has triaged and labeled nearly 800 issues in the 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 by the repository owner. https://github.com/ documentation issue tracker, closing 200 so far. Many of the open issues belong to your teams. Find your area below, then:

  • Close stale issues that are no longer relevant, or comment “Close this” if you don’t have access
  • Comment with corrections or updated information when you spot something wrong
  • If possible, draft doc changes and comment with markdown or a link to your draft

If you have permissions to close issues or update docs directly, even better. If not, your comments are exactly what’s needed to help the docs team take action.

Here are the open issues by area:

Questions? 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.” @estelaris in #docs on 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/.

7.0 documentation and other projects

Besides the overhaul, the docs team is focusing on WordPress 7.0 documentation and a revision of the handbook to include the recommendations given by @rossanatrujillo, a student from the WPCredits program.

Props to @awetz583 for reviewing this article and @supernovia for clarifying

#docs

Documentation Team at WordCamp Asia 2026 in Mumbai

Hello WordPress Documentation Team contributors! 

We’re excited to see you, collaborate, and reconnect in person at WordCamp Asia 2026 in Mumbai, India. Events like this offer a unique opportunity for contributors across the Asia-Pacific region and beyond to gather, exchange experiences, and support each other in strengthening the WordPress project — both locally and on a global scale.

This year, WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Asia 2026 takes place in Mumbai, India, and will feature Contributor DayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/, conference sessions, networking, and community-building activities. If you’re planning to attend, we’d love to see you at the Documentation Team table during Contributor Day!

WordCamp Asia 2026 Details

Here are the key details for WordCamp Asia 2026:

Documentation Team at Contributor Day

Contributor Day is one of the most welcoming and energizing parts of any WordCamp. It’s a dedicated day for attendees to contribute to the WordPress open-source project by joining one of the many Make WordPress teams.

For the Documentation Team, Contributor Day is a chance to:

  • Welcome new contributors,
  • Reconnect with existing contributors,
  • Review and write WordPress documentation for end users and developers,
  • Review and write documentation for WordPress release 7.0

First time at Contributor Day? No prior experience is needed to get involved. The Documentation Team table is the perfect place to discover how the team operates, explore the different ways you can contribute, and find out how your skills and interests can make a meaningful impact within documentation.

Detailed Contributor Day Schedule

Location: Documentation Team Table, Lotus Hall, Jio World Convention Centre, Mumbai
Date: April 9, 2026

08:00 am IST Registration Open and Networking Time

09:00 am IST – Opening Remarks
09:30 am IST – Family Photo
09:45 am IST – Contributing to WordPress/Workshop/Open-Source Library
10:00 am IST – The Making of a WordPress Release: Conversations with Past Release Squad Members

12:00 pm IST Long Break and Networking Time

01:45 pm IST – Table Leads Photo
02:00 pm IST – Contributing to WordPress/Workshop/Open-Source Library
04:30 pm IST – Closing Remarks

05:00 pm IST Contributor Day Wrap-up

What to Expect at The Documentation Team Table

At the Documentation Team table, participants may work on:

  • Onboarding new contributors,
  • Reviewing and updating documentation for coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. blocks,
  • Reviewing and/or writing user documentation for WP 7.0 release

Table Leads

This year’s Contributor Day at WordCamp Asia, the Documentation Team will be led by @clk87 with both @bph and @rollybueno will help with the onboarding of new contributors.

If you have experience contributing to the Documentation Team, we would love to invite you to take part in the new initiative introduced by Contributor Day Team – Contributor Buddy.

Contributor Buddy is a new initiative that makes Contributor Day feel more approachable, especially for newcomers. Experienced contributors volunteer at team tables to help others understand how the team works, find beginner-friendly tasks, and get started with confidence.

If you are planning to join the Documentation Team and have previous contribution experience, simply reach out to @clk87 or @rollybueno and express your interest in becoming a Contributor Buddy. If appropriate, they will provide you with a Contributor Buddy badge.

Things to prepare before WC Asia

If this is your first time contributing to the Documentation team, please make sure you have the following accounts:

Make sure you join #docs 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. Once there, just wave 🙂

The following videos/onboarding sessions can be helpful for performing the tasks we plan to work on:

For general details on how 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 by the repository owner. https://github.com/ works, check out GitHub’s Getting Started Guide.

When you find issue you’d like to work on in the Docs Team Issue Tracker here on GitHub:

  1. Please leave a comment in that issue so that we can assign you and to avoid more people working on the same issue, and
  2. In that comment, also be sure to tag the team rep responsible for the handbook that your chosen task is about.

For example, if your task is for the 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. Editor End-User documentation, you would tag @atachibana.

Check out the Team page in the Documentation Team Handbook for a list of team reps.

Join Us in Mumbai

Whether you are an experienced contributor or completely new to the WordPress project, we’d love to see you at the Community Team table during Contributor Day.

Come learn, contribute, connect, and help shape the future of WordPress communities.

Joining us in Mumbai? Stop by the Documentation Team table and be part of the conversation. Let’s build community together!

Props @estelaris for preparing the callout post

Documentation team meeting notes – March 3, 2026

Where: #docs channel on 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/
When: Tuesday, March 3, 2026, 14:00 UTC
Meeting Facilitator: @milana_cap
Note Taker: @awetz583
Find the complete meeting on Slack.

Next Meetings

Discussion Meeting

Where: #docs channel on Slack + Video call
When: Tuesday, March 10 2026, 14:00 UTC
Facilitator: @estelaris

Discussion Meeting

Where: #docs channel on Slack
When: Tuesday, March 17 2026, 14:00 UTC

View upcoming dates on the Documentation Team meeting calendar.

Facilitation Resources

Helpful resources for facilitating the meeting and writing the meeting notes.

Project Checks: Contributions

  • @awetz583 Worked on Video block, Verse block, Image block, and File block which are ready for review.
  • @milana_cap
    • Completed and closed Pullquote block and List block.
    • Recorded 3 short videos for documenting the 7.0 release and uploaded them to wordpress.tv (these will be available soon.)
    • Created a Github project for 7.0 Documentation, added automation with 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 by the repository owner. https://github.com/ workflow to add issues with 7.0 label automatically and added access to release team to the project.
  • @rollybueno Completing working on 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. overhaul including Quote block and Code block.
  • @supernovia Contribution Pathways is now on Github and will continue to receive updates.
  • @parinpanjari Working on updates for Get started with WP article.

The team is now down to 657 open issues, with 28 issues closed in the past week.

Documenting WordPress 7.0 release

@estelaris proposed changes to the WordPress release day workflows, including reversing the order of the WordPress Versions page to show the latest version first, removing the Roadmap page from the team’s responsibilities, and updating the History and “Learn about WordPress origins and version history” pages. The team discussed the challenges and potential solutions, including exploring automation and using Contributor Days for manual updates.

Open Floor

Reviewing the Documentation Review Process

@supernovia asked the team to review the documentation review process and @estelaris and @milana_cap plan to provide feedback.

Switching to Video Meetings

@milana_cap proposed switching some of the team’s meetings to video calls, as video discussions tend to be more productive than Slack-only meetings. The team decided to add additional video calls to the monthly schedule.

New schema for docs meetings:

#docs, #meeting, #summary

Proposal to change the user documentation workflow

The workflow currently used by the Docs team to update user documentation is likely a key reason why documentation is often not ready by release day.

Current Workflow Overview

The 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 by the repository owner. https://github.com/ project template contains 13 status columns, intended to reflect multiple review stages before publishing on 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/. Some columns are used for Dev Notes, while others are for user documentation:

  • No Status
  • Unknown
  • To Do
  • In Progress
  • F.G. and Misc.
  • Needs 1st Review
  • Needs 1st Review (Peers)
  • Edits After 1st Review
  • Needs 2nd Review
  • Needs 2nd Review (Copy)
  • Reviewed: To Revise / Migrate
  • Ready to Publish: Make CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.
  • Done

Problems with the Current Workflow

Currently, once the Source of Truth article is available, contributors begin writing drafts—usually in Google Docs. These drafts often sit more than a week waiting for a first review. After revisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision., they then wait again for a second review.

Sometimes the second reviewer publishes the article in WordPress; other times, articles wait weeks longer, and by the time they are updated, the release has already shipped, forcing additional updates.

This process leads to:

  • A growing backlog of unfinished documentation,
  • articles being updated out of release order (e.g., 6.4 → 6.6 → 6.5), resulting in confusion,
  • inconsistent documentation when users report outdated content

Proposed Workflow Change

For WordPress 6.9, the HelpHub documentation was written directly in WordPress, scheduled for release day, without review waiting time.

To ensure accountability, issues were still created in GitHub to track both new and updated articles, and reviews should occur after publication.

Recommendations

  • Skip most review stages before release.
  • Form a small writing team dedicated to each release.
  • Reviews should be optional before publishing (if a reviewer is available.)
  • Schedule completed articles to publish on release day.
  • Perform a second review after publishing, correcting any issues as needed.
  • Simplify the GitHub project template to remove unnecessary review columns.

Key improvements shown by the new workflow

BeforeAfter
Multiple review bottlenecksStreamlined review — optional pre-release
Work stored in Google DocsWork completed directly in WordPress
Delayed publishingRelease-day publication
Articles often outdated before launchQuick updates post-launch
Large backlog that rarely clearsContinuous improvement, smaller backlog

The stepping away of a team member

The Documentation team’s leadership has asked Jenni McKinnon to step away from the team.

Recent changes in the structure of the WordPress release squad started a discussion about the role of the Documentation team in documenting the release. While the team was working with the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team, the release squad, and Mary Hubbard to find a solution for this and future releases, Jenni posted comments that were out of alignment with the team, including calls for broad changes across the project and requests to remove certain members from leadership roles.

This ran counter to the Documentation team’s intentions. Docs leadership reached out privately in an effort to de-escalate the situation and asked Jenni to stop posting such comments, but this behaviour did not stop. As a result, the team has decided to ask her to step away for a period of time to reassess her involvement. We will work with her to explore rejoining the team in the future, if it aligns with the best outcomes for both her and the team.

As a team, we apologise to the community and to the individuals mentioned for any inconvenience these comments have caused. These do not reflect the views of the Documentation team, and we are committed to ensuring that they are not perceived as such.

The Documentation team reps: @kenshino, @atachibana, and @milana_cap.

Online monthly Docs Team Contributor Day September 23, 2025

The Documentation Team holds an online, monthly Contributor Day on the fourth Tuesday of every month. Any one may join who wishes to contribute to the team and who follows the Code of Conduct.

The next Docs Team Contributor DayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/

The next monthly online Docs Team Contributor Day will be:

When: Tuesday, September 23, 2025, 2:00 PM UTC for 3 hours.

Where: #docs channel on Slack, and on Google Meet.

Please also see the ongoing Contributor Day post on 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 by the repository owner. https://github.com/ for onboarding and other important details.

Onboarding

In addition to the details in the GitHub issue for this Contributor Day, folks who are in need of onboarding can ask in 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/ or on the video call.

If at any time you have any questions, please feel free to ask in the #docs channel on Slack or on the video call throughout the day.

To all contributors

To every contributor and attendee: Thank you. We’re so grateful for your time, care, and dedication. Cookies 🍪🍪🍪 and kudos all around! While no token of appreciation could ever match the depth of your impact on the WordPress project and our community, we hope you know just how seen, valued, and celebrated you truly are – even when words fall short.

We may not be able to thank you enough today – but maybe one day we can, because we’re part of an incredible community that can make it happen. Whatever “it” is, we’ll do it. Together.

#contributor-day, #docs

Docs team participation in WordPress releases

The release team is experimenting with a smaller team with the goal to reduce the overhead on the Release Squad.

” This streamlined structure places more emphasis on collaboration with the various Make Team Reps, who are encouraged to help coordinate efforts from within their respective teams.  The goal is to reduce the overhead on the Release Squad while still ensuring each team’s contributions and priorities are represented throughout the cycle.” as explained in the Announcement the WordPress 6.9 Release Squad

The release team does not include representation from the documentation team. Why is this a problem? Because often documentation gets overlooked in release planning and project-wide coordination: Documentation is not a “nice-to-have,” it is a survival requirement. It’s not something we might do if someone has time; it’s something we must do — or the whole thing breaks down at scale. Removing the role from the release squad, we are not just sending the message that documentation is not important, we are showing new contributors that working on docs will never get them to the top of the credits page, therefore showing that we don’t even appreciate contributing to the Docs.

To support the smaller release team experiment, we agreed with @4thhubbard to compromise on having a Docs Liaison for this release. But this needs to be rethought on every release. Docs needs a structure/inclusion in future releases which should be a lead.

The feedback from the docs team so far on the experiment is the lack of communication from the release team and the perception that Releases are only open to coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team members.

For now, we will not give access to the docs site to core committers who are not members of the docs team. @audrasjb @desrosj @jeffpaul @johnbillion @peterwilsoncc @poena and @sergeybiryukov currently have access and this will not be revoked. We can revisit this discussion after the experiment of a reduced release squad.

Why is important to have a release docs lead

The documentation team maintains the user documentation, including the WordPress version pages and parts of the developer documentation.

For short, not everyone is willing to understand and follow thru with the full process and pages remain incomplete, like this or this.

Documentation team lead role in past releases

In past releases, the documentation team lead has been given to anyone that asks for, even when they are not members of the documentation team. The results have been a mix of good and bad. There are two reasons, one is because of the misunderstanding of what the role is; and two, because the contributor chosen is not a member of the team thus they are unfamiliar with documentation.

Since 6.8, we have worked on updating sections in the core handbook related to documentation. Yet, the Role of the Documentation team lead is incomplete. Beginning with the Documentation Wrangling title, “wrangling” should not be on the title as it reads like the team only “wrangles” dev docs. It is also missing reference to the user documentation, whether is updating old articles or writing new ones for new released features.

The actual documentation process

This is a summary, the articles are linked for further explanation.

  1. Open a project in GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner. https://github.com/ – Documentation Issue Tracker, example from 6.8
    • In this project, DevNotes and User docs are tracked.
    • DevNotes are written by core committers or whoever has been involved in a feature. User docs are written by the docs team members.
    • Who creates the lists? DevNotes list is created by either the release tech lead or the release docs lead. User docs list is written by the release docs lead.
    • Both DevNotes and User docs should be written during the release cycle. Although, there is never enough time and both lists can be incomplete by the end of the release cycle. Docs team continues working on user docs. Any missing devnote is only updated if requested.
  2. Before and on release day of a major version, other items need to be updated by the release docs lead. Full description on the Documentation process during a major version release article in the documentation handbook. The publishing of the pages has an order that is explained in the core handbook – releasing major versions.

For minor releases, only the HelpHub or Version release page is created and the WordPress Versions page gets updated.

After the release cycle ends

When the release cycle ends, the docs team focuses on updating or writing new user documentation articles. The work is tracked in the GH documentation issue tracker for both, user docs and developer docs.

Props to @milana_cap, @ninianepress and @4thhubbard for their feedback and review of this post.

Proposal: Responsible AI workflow for creating new documentation for WordPress 6.9

As part of our ongoing commitment to improving the contributor experience and the efficiency of our documentation efforts, this post outlines a proposed workflow for responsibly using AI to assist in drafting new 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/ end-user documentation articles for release 6.9.

This initial phase focuses only on the creation of new articles, using approved style guides to generate structured drafts while keeping human contributors fully in control of fact-checking, editing, and publishing. The goal is to responsibly introduce AI as an augmentative tool – never as a replacement for contributor expertise.

In future release cycles, this workflow will expand to include automated updates to existing documentation, integration with tools like the WordPress Playground for screenshots, and additional opportunities for guided automation. We will document and refine each step as we iterate.

Responsible AI workflow for WordPress.org documentation

This proposed structure outlines a safe and effective way to integrate generative AI into the WordPress.org documentation process. It assumes human oversight at every step and is designed to uphold best practices, contributor safety, and content accuracy — all while increasing efficiency through thoughtful use of AI.

1. Set clear scope and intent (human-led)

Before prompting AI, contributors should define:

  • What needs to be created (e.g. a new feature doc).
  • Audience: WordPress users with some (limited) technical knowledge.
  • What type of article it will be (how-to, reference, landing page, etc.).

Please consider: Think of this like writing a good issue tracker ticket – be specific, but flexible enough for collaboration.

2. Generate a structured draft with AI

AI should be used only to produce a first draft, not a finished product. When prompting:

  • Include a separate list of links at the end for internal referencing to dev notes, TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/./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 by the repository owner. https://github.com/ issues, and related documentation.
  • Specify the intended audience and type of document.
  • Request content aligned with the Docs Style Guide and the WordPress Brand Style Guide.

Reminder: AI-generated content is never final. It’s a starting point – the expertise still comes from our contributors.

3. Fact-check and human edit

Every AI-generated draft must be:

  • Fact-checked (AI-assisted) against canonical sources such as the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. codebase, as well as the corresponding GitHub pull requests, Trac tickets, and any applicable and related documentation.
  • Copyedited for grammar, voice, 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 clarity.
  • Reviewed by at least one other contributor to confirm technical accuracy.

4. Run it through style and inclusion checks

AI or human contributors can help ensure the content:

  • Uses plain language when appropriate.
  • Avoids passive voice and unnecessary jargon.
  • Uses accessible formatting (semantic headings, code blocks, etc.).
  • Follows inclusive language practices.

Option to consider: You may ask AI to assist with a style pass, but this must be followed by a human final review.

5. Publish with accountability

Before publishing:

  • Make sure articles and corresponding GitHub commits indicate whether AI was used.
  • Include a changelog comment summarizing the workflow.
  • Close the Pull Request with a summary of contributors to be included in the release credits (This will only be applied to major releases.).
  • Flag the article for follow-up if the feature it covers is experimental or subject to change.

Keep in mind: Transparency builds trust and helps us trace content lineage.

6. Reflect, iterate, and document the process

This pilot is just the beginning. Contributors are encouraged to:

  • Record what worked (and what didn’t) in their prompts or workflows.
  • Share findings in team meetings, 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/, or GitHub issues.
  • Suggest improvements or automation opportunities for future releases (e.g. using AI to detect outdated content).

Guardrails to keep in place

To protect the integrity of WordPress.org documentation:

  • Never publish AI-generated content without human review.
  • Avoid hallucinations by grounding all prompts in verifiable sources.
  • Do not train AI models directly on private or unpublished WordPress.org content.
  • Always use a “human-in-the-loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop” approach for oversight and editing.

A note on ethics

AI is not here to replace contributors. It is here to support them.

The goal of this workflow is to reduce friction in the drafting process so contributors can spend more time on high-value tasks like strategy, mentorship, and refining content. This approach upholds the core values of the WordPress project by emphasizing collaboration, transparency, and inclusion.

Developing prompts collaboratively ahead of 6.9

For the upcoming WordPress 6.9 release, we will begin developing AI prompts in advance of the release cycle to support the creation of new documentation articles. This will be a collaborative, iterative effort involving contributors from the Docs Team and beyond.

Rather than providing a fixed prompt template from the outset, we’ll work together to explore:

  • What types of prompts produce the most accurate and useful first drafts.
  • How audience type, feature complexity, and prompt structure affect output quality.
  • What tone, format, and phrasing align best with our style guides and contributor expectations.
  • Which prompt patterns reliably reduce friction and avoid common AI issues (e.g. hallucination, redundancy, overly generic content).

We’ll test prompts during regular contributor meetings, in Slack, and through hands-on documentation issues tied to 6.9. These findings will inform the development of prompt libraries and usage guidelines that reflect real contributor experiences and lessons learned.

As we gather results, we’ll document successful prompt themes, refine our approach, and share reusable examples with the broader community to support future releases.

This process ensures that our use of AI remains grounded, transparent, and shaped by the needs of our contributors – empowering more people to participate effectively while maintaining the quality and trustworthiness of WordPress.org documentation.

Next steps

This proposed AI workflow will apply to WordPress 6.9 and focus solely on creating new documentation. Future iterations will expand to include AI-assisted updates to existing articles and explore automation tools such as AI-generated screenshots from the WordPress Playground.

We’ll continue to iterate, document, and refine this process across upcoming release cycles to ensure it meets the needs of both our contributors and the broader WordPress community.

The contributors to this proposal: 

@estelaris, @milana_cap, @ninianepress

#ai, #docs, #proposal

Online monthly Docs Team Contributor Day August 26, 2025

The Documentation Team holds an online, monthly Contributor Day on the fourth Tuesday of every month. Any one may join who wishes to contribute to the team and who follows the Code of Conduct.

The next Docs Team Contributor DayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/

The next monthly online Docs Team Contributor Day will be:

When: Cancelled until September 2025 for the Documentation Team’s summer break.

Where: #docs channel on Slack, and on Google Meet.

Please also see the ongoing Contributor Day post on 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 by the repository owner. https://github.com/ for onboarding and other important details.

Onboarding

In addition to the details in the GitHub issue for this Contributor Day, folks who are in need of onboarding can ask in 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/ or on the video call.

If at any time you have any questions, please feel free to ask in the #docs channel on Slack or on the video call throughout the day.

To all contributors

To every contributor and attendee: Thank you. We’re so grateful for your time, care, and dedication. Cookies 🍪🍪🍪 and kudos all around! While no token of appreciation could ever match the depth of your impact on the WordPress project and our community, we hope you know just how seen, valued, and celebrated you truly are – even when words fall short.

We may not be able to thank you enough today – but maybe one day we can, because we’re part of an incredible community that can make it happen. Whatever “it” is, we’ll do it. Together.

#contributor-day, #docs

Online monthly Docs Team Contributor Day July 22, 2025

The Documentation Team holds an online, monthly Contributor Day on the fourth Tuesday of every month. Any one may join who wishes to contribute to the team and who follows the Code of Conduct.

The next Docs Team Contributor DayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/

The next monthly online Docs Team Contributor Day will be:

When: Tuesday, July 22, 2025, 2:00-5:00 PM UTC

Where: #docs channel on Slack, and on Google Meet.

Please also see the ongoing Contributor Day post on 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 by the repository owner. https://github.com/ for onboarding and other important details.

Onboarding

In addition to the details in the GitHub issue for this Contributor Day, folks who are in need of onboarding can ask in 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/ or on the video call.

If at any time you have any questions, please feel free to ask in the #docs channel on Slack or on the video call throughout the day.

To all contributors

To every contributor and attendee: Thank you. We’re so grateful for your time, care, and dedication. Cookies 🍪🍪🍪 and kudos all around! While no token of appreciation could ever match the depth of your impact on the WordPress project and our community, we hope you know just how seen, valued, and celebrated you truly are – even when words fall short.

We may not be able to thank you enough today – but maybe one day we can, because we’re part of an incredible community that can make it happen. Whatever “it” is, we’ll do it. Together.

#contributor-day, #docs