Estela Rueda 2:05 pm on December 2, 2025  

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 be 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

Milana Cap 9:35 am on September 19, 2025  

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.

Jenni McKinnon 3:40 pm on September 18, 2025
Tags: ,   

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 be 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

Estela Rueda 1:21 pm on September 10, 2025  

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 be 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.

Jenni McKinnon 7:34 am on July 24, 2025
Tags: ai, , proposal   

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 be 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

Jenni McKinnon 5:18 pm on July 22, 2025
Tags: ,   

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 be 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

Jenni McKinnon 3:44 pm on June 24, 2025
Tags: ,   

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 be 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

Jenni McKinnon 7:04 am on June 18, 2025
Tags: ,   

Online monthly Docs Team Contributor Day June 24, 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, June 24, 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 be 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

Milana Cap 4:47 pm on April 2, 2025  

Proposal – the Documentation team meetings time

Lately, it has been noticed that the majority of attendees of Documentation team meetings are from Europe and Asia. Currently, team meeting time is 2 PM UTC, while online Contributor Days are from 1 PM to 3 PM UTC. This is not the most convenient time for the Asian community, especially from the Far East.

During the last meeting, it was concluded that Tuesday, as the meeting day, fits everyone. For the timing, moving back up to 5 hours could improve everyone’s experience and overall attendance.

Therefore, we propose the following options (NOTE: we will not apply a new time to the next meeting):

  1. Tuesday, 9AM UTC
  2. Tuesday, 10AM UTC
  3. Tuesday, 11AM UTC
  4. Tuesday, 12PM UTC
  5. Tuesday, 1PM UTC
  6. the same as it was
  7. something completely different (please, explain in comments)

Please let us know which option is the best for you in the comments. Also, keep in mind that Contributor Days last for 3 hours. They start 1 hour before the usual meeting and end one hour later.

Voting will be open until the next meeting, 8th April, to make sure everyone has enough time to add their vote.

Next meeting timeTuesday, 8 April 2025, 2PM UTC
Next online 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/. time
Tuesday, 22 April 2025, 1PM UTC

to

Tuesday, 22 April 2025, 3PM UTC

Sagar Gurnani 6:18 am on April 2, 2025
Tags: , ,   

Summary for Discussion Meeting (01-Apr-2025)

Attendance

@milana_cap @sagargurnani @estelaris @karthickmurugan @kafleg @Dhruvang21 @nikunj8866 @snilesh @sirlouen @stephenaturner999 (async)

Housekeeping

Find the complete Transcript of the meeting on Slack.

Upcoming Meetings

Project Checks

@milana_cap reviewed the issues completed by @karthickmurugan and she also has a list of duplicate issues to sort out.

@karthickmurugan had completed many issues which can be seen by here.

Open Floor

@milana_cap raised a concern that the majority of the team at the moment is from Asia. She believes 14:00 UTC is not the best time for the team to attend the meeting because it becomes very late for the team members living in APAC timezones. So, she would propose a poll for new meeting time that will include earlier hours on Tuesdays. The poll would be held today i.e. 02-Apr-2025 and would be initiated by herself.

@sagargurnani discussed how to attract more contributors to be the part of the #docs team and to work on the  #docs. To which @milana_cap said that it needs pushing and announcing it regularly on social media and every single 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. maybe we can work on docs per project, and treat every project as “job posting” create a call, share it everywhere record videos how we do stuff, so that people can be onboarded more easily maybe we need new onboarding stuff.

@estelaris mentioned Matt’s plan for one 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. per year and this will give us opportunity to catch up with all issues and documentation and there’s a need for a plan for that.

P.S. – Please drop your comments with your ideas for attracting more new contributors to the #docs team.

#meetings, #summary