Dev Chat Summary, January 31, 2024

Start of meeting on Slack

This Dev Chat continues the experiment to focus chat time on discussions related to open CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. proposals and release issues, rather than repeating links already highlighted in the curated agendas.

Announcements

Following announcement of yesterday’s 6.4.3 release, @jorbin noted that there was one issue of note, but that there were workarounds available at this time. @jorbin further gave props to those who helped facilitate the release.

@hellofromtonya shared that @joemcgill has accepted his nomination to serve as a 2024 Core team rep 🎉. The search continues for a co-rep, where it’s been noted that a contributor from the Core Editor team would be a great compliment, though not required. Nominations remain open until April 1, 00:00 UTC.

Discussion on open proposals in Core

Field GuideField guide The field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page. Publish Date

Link to post: Proposal: An update to the Field Guide

Conversation start link

Comments:

  • @jorbin was under the impression that neither the dev blogblog (versus network, site) team nor 6.4 release leads were interested in moving forward with the proposal. @webcommsat shared that 6.4 docs release leads didn’t see 6.4 as the deadline, and discussions were continuing. @joemcgill agreed that the proposal wasn’t release specific, but rather an adjustment to timing of when field guide information is released. @hellofromtonya also added that the dev blog team has opened a discussion to track the second part of the proposal.
  • @jeffpaul referred to @chanthaboune‘s comment of where best to separate field guide content based on audiences, suggesting the proposal could be adjusted accordingly. @jeffpaul added that some folks have difficulty processing field guide information to determine what is relevant and actionable, which @hellofromtonya agreed should be explored. @webcommsat agreed with the notion to target field guide content to particular audiences, but also to look at how it relates to other new content produced for the release.
  • @jeffpaul suggested the potential to target content according to the five user groups identified in Care and influence: a theory about the WordPress community.
  • @ironprogrammer asked if the field guide info would be more easily consumable if it was split into a canonical structure, such as wordpress.org/6-5/field-guide/, with subpages that match particular areas or audiences.
  • @webcommsat noted that segmentation between audiences has grown, and suggested it’s a good time to use teams’ audience-specific insights to improve the field guide format. She added that exploring how best to utilize the limited people and time for the Docs team would be an important factor in implementing improvements. @jeffpaul agreed with concerns around challenges in gathering/publishing content, but noted that the issue should be considered as separate from the proposal.
  • @jorbin shared that the original published field guide was the result of an overly long email sent to 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 developers.
  • First-time Docs Co-Lead @estelaris 🎉 asked about adding additional comments to the proposal. @jorbin noted that Make/Core comments close automatically after 180 days (~6 months). @costdev shared that adding the #keep-comments-open tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) would reenable them, but recommended removing the tag once an updated timeframe for feedback has been reached. @jorbin updated the Core handbook to reflect this info.
  • @joemcgill pointed out that the team should review all current channels where field guide-related content is published, to check whether only updating the field guide [in one place] would sufficiently improve the broader sharing of release updates to the community. He suggested engaging with the Docs and Marketing teams to move forward, and @estelaris noted she would begin by sharing with Docs. @webcommsat suggested looping in Training as well. @laurlittle noted that the Marketing team could brainstorm on the proposal for future releases, if not 6.5.
  • In response to @joemcgill, @webcommsat noted that there have been past lists of channels and audiences, and suspects more current info should be available. She also suggested it might be helpful to have a single post that links out to the various user groups identified earlier, and to link to that post from the About page.
  • @jorbin referred back to @jeffpaul‘s input and asserted that the dev blog and other team areas might be better places to communicate field guide information, as opposed to Make/Core. @hellofromtonya asked if, considering this perspective, the proposal was actionable by the Core team, or if the proposal should be re-worked as a cross-team collaboration. @jorbin suggested that the teams publishing the field guide info would take on the proposal.
  • @joemcgill noted that it can be difficult to know the status of a proposal, suggesting some way of flagging these posts. @marybaum suggested a visual system to convey “stalled”, “live”, etc, and @joemcgill raised the idea of a 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. pattern. @desrosj shared that in past proposals (example) he has added status info to the top of the post, assuming the status was clear.
  • @hellofromtonya wrapped up the discussion based on the chat, concluding that the proposal be marked closed (“not accepted”), or must be picked up by another team(s).

Actions:

  • Part 1: Move Make/Core field guide publication ahead one week, aligning with last scheduled 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., rather than RC1. Not accepted ❌
  • Part 2: Start publishing a simplified field guide to the WordPress Developer Blog. Not accepted ❌
  • Other teams to explore revising and adopting this proposal:
    • @estelaris to share the proposal with Docs.
    • @laurlittle to raise the proposal to Marketing for possible brainstorm.
    • @webcommsat to 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. in Training to gauge their interest in furthering the proposal.
    • To highlight in dev blog.

Open Floor

Props @hellofromtonya for peer review.

#6-4, #6-5, #core, #core-editor, #dev-chat, #meeting, #summary

Performance Chat Agenda: 30 January 2024

Here is the agenda for this week’s performance team meeting scheduled for Jan 30, 2024 at 16:00 UTC. If you have any topics you’d like to add to this agenda, please add them in the comments below.


This meeting happens in the #core-performance channel. To join the meeting, you’ll need an account on the Make WordPress Slack.

#agenda, #meeting, #performance, #performance-chat

Dev Chat Summary, January 24, 2024

Start of meeting on Slack facilitated by @webcommsat

This DevChat starts with an experiment to shift the chat to synchronize discussions on open coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. proposals and release issues rather than reproducing links highlighted in the curated agendas.

Discussion on open proposals in Core

Interactivity APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.

Link to post: Proposal: The Interactivity API – A better developer experience in building interactive blocks

Conversation start link

Comments:

  • The API is well beyond the proposal stage, with nothing actionable in discussion.

Actions:

  • The proposal should be considered “accepted”.

HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. API: Introduce WP_HTML::tag() for safely creating HTML

Link to PR (draft): https://github.com/WordPress/wordpress-develop/pull/5884

Conversation start link

Comments:

  • This PR was raised along with the question of how items should be added to the agenda. It was clarified that topics can be added as comments to the previous week’s chat summary, or to the current week’s agenda post (typically published on Tuesdays). And of course, any item can be raised during the open floor section of Dev Chat.
  • @dmsnell indicated that the PR for consideration is a scaled back version of a larger templating system proposal, which will not be ready for 6.5. The PR adds a helper utility, WP_HTML::tag(), to conveniently generate single HTML tags with attributes. The impetus for this feature is to provide Core and extenders a safer way to generate HTML tags, compared with reliance on proper usage of functions such as esc_attr(), which might be overlooked and introduce HTML injection vectors.
  • @jorbin would prefer that any new APIs be used by Core itself, and that there be accessory patches prepared that demonstrate how the function integrates and operates in Core. It was also suggested that a Make/Core proposal would help with gathering broader input.
  • @azaozz pointed out that enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. tickets in TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. are another form of “proposal”, and can also result in healthy discussion. He suggested starting the discussion in Trac, and then utilizing a Make/Core proposal if the ticketticket Created for both bug reports and feature development on the bug tracker. isn’t sufficient to establish consensus.
  • There continued discussion around how Core generates HTML currently, which relies on proper use of esc_*() and echo(), as well as a broader discussion around safely generating HTML. Got feedback? Join the conversation 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 leave a comment below.

Actions:

  • @dmsnell to create a Trac ticket and/or Make/Core proposal to discuss introduction of WP_HTML::tag().
  • @dmsnell to consider a future Make/Core proposal for the HTML API templating system, and continued discussion around generating safe HTML.

Forthcoming releases

6.4.3

Conversation start link

  • @jorbin shared the remaining open tickets for this milestone, which are scheduled for review and commit prior to a Thursday (Jan 25) RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta).:
    • #60025 – This needs additional review and testing. Any help is appreciated
    • #59866 – @peterwilsoncc and I have been work on the one and I should have an update in the next 12 hours.
  • @joemcgill requested help reviewing the approach proposed in #5926 Cache locate template paths, which would address both #60025 and #60290.

6.5

Conversation start link

See this section in the agenda for updates, helpful links, and information for the 6.5 release.

Comments:

  • @oglekler pointed out that there are several early 6.5 tickets that need attention, asking for review as some might have the potential to be completed in time for 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..
  • @hellofromtonya indicated that the 6.5 cycle is past the “early part of alpha”, suggesting these may need to be punted if they truly require a long runway for soak time and discussion.
  • @azaozz agreed that the early keyword indicates a need for comprehensive testing, and possible reconsideration of the milestone if the testing hasn’t occurred. He also suggested that while not required, it might be preferable to fix old/known bugs during alpha, and allow beta testers to focus on “new” bugs introduced from Beta 1 and onward.
  • @jorbin suggested two interpretations of early; i.e. actually early in the alpha cycle, or just before Beta 1.
  • @hellofromtonya noted that since Beta 1 is the puntpunt Contributors sometimes use the verb "punt" when talking about a ticket. This means it is being pushed out to a future release. This typically occurs for lower priority tickets near the end of the release cycle that don't "make the cut." In this is colloquial usage of the word, it means to delay or equivocate. (It also describes a play in American football where a team essentially passes up on an opportunity, hoping to put themselves in a better position later to try again.) milestone for enhancements/features, that in her perspective, early should apply to early in the alpha cycle. She cited changes to WP_Query as an example where early would apply.
  • @afragen observed that it doesn’t seem that many early tickets are committed early in the cycle.

Open Floor

Props @hellofromTonya for peer review.

#6-4, #6-5, #core, #core-editor, #dev-chat, #meeting, #summary

Performance Chat Agenda: 23 January 2024

Here is the agenda for this week’s performance team meeting scheduled for Jan 23, 2024 at 16:00 UTC. If you have any topics you’d like to add to this agenda, please add them in the comments below.


This meeting happens in the #core-performance channel. To join the meeting, you’ll need an account on the Make WordPress Slack.

#agenda, #meeting, #performance, #performance-chat

Dev Chat summary, January 17, 2024

Start of meeting on Slack

This DevChat starts with an experiment to shift the chat to synchronize discussions and away from dropping of links.

Discussion on open proposals in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.

Default Theme Task Force for 2024

Link to the post: Proposal: Default Theme Task Force for 2024

Dev Chat slack link

Comments in Dev Chat focused:

  • positive feedback and highlighting that people can self-nominate their ability to help triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. those open default theme issues
  • promote the call to encourage people to be active in triaging and resolving those 436 Bundled Theme tickets

Latest position from @desrosj :

  • advised the idea has been accepted: t’s rallying a group of folks to get through and clean out the Bundled Theme component backlog on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.
  • three self nominations and more expected to be confirmed by end of the week
  • aim to start before the end of January 2024, currently 437 tickets in the Bundled Theme component
  • Jonathan will be leading the team as a mentor and someone with commit privileges, and other committers are welcome to help as well)
  • the week to week working arrangement will be depends on the team’s availability. Stay tuned! 
  • confirmed the new theme task force group will remain under core team purview. More detail on this in the comments section of the post. More contributors for the Themes team welcome to help out too. “It’s a balance though, My goal here was to allow those contributors to continue exploring what new themes look like while this team handles cleaning up some of our cruft and backlog for pre-existing ones.”
  • expecting ‘as a side effect, cleaning out the backlog also will effectively “retire” these themes in some ways, and going forward, the majority of the tickets will be 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 support related (hopefully).’ 

Actions:

  • more volunteers needed and will increase the speed can go through the outstanding tickets in the component
  • to assist, contact @desrosj 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/. on in the comments for the post itself

Proposal to improve the editor tech workflow for major releases

Post link: Proposal

Dev Chat Slack link

Context: This proposal was started in 6.4. With 6.5 underway, thinking the learnings from 6.4 could be built upon for how to continue improving the Core merges from 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/ during 6.5. Core Editor and Core chats are now combined into Dev Chat as an experiment.

Discussion:

  • @joemcgill raised the question of the right venue to push this forward. “In my opinion, the current status quo is error prone and unsustainable (as well as taking a lot of manual overhead from contributors).”
  • @jorbin: If we want to try early syncing for 6.4.3, https://core.trac.wordpress.org/ticket/59828 just needs a second committers review and we can get all the updates into the 6.4.x nightly
  • @hellofromtonya: I’m not sure either what the “right venue for pushing this forward” is. Needs a discussion with both Core and Core Editor folks to figure out the needs and how to improve these workflows. Seems earlier the better as 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 is fast approaching
  • @jorbin suggested one way to mitigate the issue would be nominating the release team, or at least the editor tech, for the next release before the current release ships. An interim editor tech to help get the ball rolling while an official team has not been announced. @joemcgill agreed having an identified set of release leads for 6.5 to discuss how they want to handle things for this release would help. The Community Summit conversation was very helpful. A working group to continue that conversation and come back with concrete proposals would be helpful, if a release team is not the right venue. A working group had positive feedback in the dev chat discussions as these workflows are continuously improving and span more than one major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.. @jorbin suggested @tellthemachines should be given right of first refusal to continue leading the effort since she kicked off the proposal.
  • Ideas included: a proposal needed to address the identified set of problems, a hallway hangout similar to the ones @annezazu and others have done.

Actions:

Forthcoming releases

6.5

Slack discussion link

See this section in the agenda for updates, helpful links, and information for the 6.5 release.

Blockages/ items need discussion for progress:

  • Font Library:
    • Discussion:
      • As a follow-up from @joemcgill‘s questions last week, @hellofromtonya has added the Core merge criteria/expectations to its Trac ticketticket Created for both bug reports and feature development on the bug tracker.. The critieria is the same as in 6.4, except Tonya is suggesting returning to the expectation the feature is merged before or by Beta 1.
      • Query raised on the criteria aspect of “running on wp.com, and not being reliant on any specific host testing this. @hellofromtonya: The reason for wp.com is: it’s a normal workflow in Gutenberg as it gains a huge amount of sites running it. @jorbin
      • @annezazu suggested some of the contributors who have worked on this feature could comment. Also noted current timeline for the feature https://core.trac.wordpress.org/ticket/59166#comment:21
      • Question: Is this anything beyond what we’d normally expect of a feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins.? @hellofromtonya: Same expectations except for REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. part of it , as I’m suggesting a maintainer needs to give a thumbs-up to its design.
      • jorbim: I don’t want to discourage that in any way, I just wonder if we would ever set a requirement like “Is running on Altis with no major issues”
    • Actions:
      • Update the criteria from the discussion. Done ✅
      • Gather expectations from the REST API maintainers and then update the criteria accordingly. Done ✅

How was the first experimental new DevChat?

@jorbin said: “I think one of the most productive meetings in a while”

@afragen shared there was no extra time to raise other tickets for discussion.

What to change?

Next week, reserve 10-15 minutes for open forum / floor discussion.

Props @hellofromTonya for peer review.

#6-4, #6-5, #core, #core-editor, #dev-chat, #meeting, #summary

Phase 3 Media Meeting: February 7, 2024

Date and time: February 7, 2024 at 24:00 UTC
Location: #core-media
Duration: 1:00 hr

The Media Component team is coordinating a meeting with the Editor team and other interested stakeholders to work on planning for the proposed Phase 3 Media Library. There are a few issues already open about the Media Library proposal, but this major development depends on close coordination between the Media and Editor teams to work effectively together.

In a recent Media Component meeting it was suggested that there should be a dedicated meeting time to kick off a round table discussion about some of the opportunities and challenges ahead in the development of Phase 3. The Media Component Maintainers hope to find areas of focus where contributors can lean in to align efforts with folks working on Phase 3.

In previous meetings the team has gone through the backlog of over 600 issues and categorized tickets as phase-3-media-triage for discussion around how Phase 3 could potentially solve these tickets alongside a rebuild of the Media Library. Some of these tickets are an opportunity to change lower level issues like db structure, but the redesign is a good time to address these possibilities.

Relevant Pull Requests, Issues, and Posts:

Phase 3: Collaboration > Media Library

PR Dataview: media view

Proposed meeting agenda:

  1. Introductions
  2. Brief presentation on the goals and vision of Phase 3 redesign for the Media Library
  3. Discussion on alignment of CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Media focus to help the process
  4. Agree on communication channels and checkpoints for regular updates
  5. Review of Phase-3-Triage Tickets

A more detailed agenda will be published prior to the meeting.

If you would like to join this meeting please join the #core-media channel February 7, 2024 at 24:00 UTC. This time seems to align with most of the world as a decent hour to meet for stakeholders and folks active in Media.


This meeting happens in the #core-media channel. To join the meeting, you’ll need an account on the Make WordPress Slack. Props @joedolson for helping prepare and proofread this post.

#agenda, #media, #media-library, #meeting, #phase-3

Dev Chat Summary, January 10, 2024

The WordPress Developers Chat meeting took place on  10 January 2024 at 20:00 UTC  in core on Make WordPress Slack.

Key info

Chat Summary

Nominations for 2024 Core Team Reps:

@desrosj reminded Gutenberg and Core development contributors to update their local Node.js/npm as:

.. the versions of Node.js and npm required for WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. development are now 20.x and 10.x.

In order to continue contributing to WordPress through wordpress-develop or WordPress/Gutenberg, you’ll need to upgrade the version of Node.js installed on your machine to one that’s greater than or equal to 20.10.0 (currently the most recent generally available version 20.x version). This should also update npm to the correct, expected version appropriately (10.2.3 or higher is required).

Release Updates

Next 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.: 6.4.3

@jorbin shared an update:

  • Timeline coming before next devchat.
  • No pressing issues – okay to wait “a few weeks for the next minor.”
  • Reminder to “milestone any tickets” needing addressing.

Next major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.: 6.5

  • Release squad: call to join the squad ended Jan 12th.
  • Current: in Alpha.
  • Next milestone: 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 is Feb 13th.

Tickets / Issues that need assistance

  • #60227 @jonsurrell asked for feedback to use an external library for testing the HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways..
  • #60025 @jorbin requested help (it’s in the 6.4.3 milestone) and noted:

Joe did a great job of summerizing and shared some paths forward that I think could be good to explore

Open Floor

Discussion of changing DevChat

@jorbin opened the discussion for changing DevChat, i.e. to get to the important things to chat about (rather than half or more of the meeting dropping links):

As we are now 43 minutes into the meeting and it’s been almost all link sharing thus far, I wonder if perhaps 2024 should be the year we explore some alternatives for this meeting? I’m not sure that a link dump is doing it

The discussion summary:

socializing to folks leading/working on feature projects or specific items targeted in a current major release that devchat is a good place to come and share blocks/problems/areas for feedback they have.  Chatting through those things synchronously can help find alternate paths forward for those things that are of importance to the project.

advance those conversations towards an acceptance or finding iterative ways to improve those proposals.

When to start? Experiment starts next meeting.

Call for Volunteers to review the open proposals on Make/Core and create a list of unresolved ones to discuss during the DevChat meeting.

Font Library – avoid merge roadblocks

@joemcgill asked for Font Library update and plan to avoid the roadblocks experienced during 6.4. See the discussion in the Slack thread which includes Core merge criteria.

Next Meeting

The next meeting will be on 17 January 2024 at 20:00 UTC . This DevChat will experiment with a new approach

Are you interested in helping draft DevChat summaries? Volunteer at the next meeting!

Props @webcommsat for peer review.

#6-4, #6-5, #core, #core-editor, #dev-chat, #meeting, #summary

Performance Chat Agenda: 16 January 2024

Here is the agenda for this week’s performance team meeting scheduled for Jan 16, 2024 at 16:00 UTC. If you have any topics you’d like to add to this agenda, please add them in the comments below.

  • Announcements
    • Welcome to our new members of #core-performance
    • Performance Lab 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 release today for version 2.8.0
  • Priority projects
  • Open floor

This meeting happens in the #core-performance channel. To join the meeting, you’ll need an account on the Make WordPress Slack.

#agenda, #meeting, #performance, #performance-chat

Performance Chat Agenda: 9 January 2024

Here is the agenda for this week’s performance team meeting scheduled for Jan 9, 2024 at 16:00 UTC. If you have any topics you’d like to add to this agenda, please add them in the comments below.


This meeting happens in the #core-performance channel. To join the meeting, you’ll need an account on the Make WordPress Slack.

#agenda, #meeting, #performance, #performance-chat

Performance Chat Agenda: 2 January 2024

Here is the agenda for this week’s performance team meeting scheduled for Jan 2, 2024 at 16:00 UTC. If you have any topics you’d like to add to this agenda, please add them in the comments below.


This meeting happens in the #core-performance channel. To join the meeting, you’ll need an account on the Make WordPress Slack.

#agenda, #meeting, #performance, #performance-chat