<div style="text-align:center"></div><div>
<p><a href="https://make.wordpress.org/core/2023/01/09/performance-chat-agenda-10-january-2023/">Meeting agenda here</a> and the full chat log is available <a href="https://wordpress.slack.com/archives/C02KGN5K076/p1672761606730749">beginning here on Slack</a>.</p>
<h2 class="wp-block-heading">Announcements</h2>
<ul>
<li><a href="https://profiles.wordpress.org/mxbclang/" class="mention"><span class="mentions-prefix">@</span>mxbclang</a>: This week’s chat will be dedicated to discussing next steps on Matt’s request to split out features from Performance Lab (see <a href="https://make.wordpress.org/core/2022/12/20/help-us-test-the-sqlite-implementation/#comment-44225">blog post comment</a>, <a href="https://wordpress.slack.com/archives/C02KGN5K076/p1672762227564509">Slack</a>, and <a href="https://github.com/WordPress/performance/issues/618">GitHub issue</a>). We’d like to hear opinions on the <a href="https://github.com/WordPress/performance/issues/618#issuecomment-1370365866">three options outlined in the issue</a> so that we can ultimately hold a vote and make a decision on how to move forward.</li>
</ul>
<h2 class="wp-block-heading">Discussion: Unbundling Performance Lab</h2>
<ul>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: Want to emphasize that we should decouple how we <em>develop</em> these features from how we <em>distribute</em> them, with this conversation focused on the latter. We can keep working in a mono repo to keep development overhead low no matter which approach we choose for distribution.</li>
<li><a href="https://profiles.wordpress.org/olliejones/" class="mention"><span class="mentions-prefix">@</span>olliejones</a>: It seems like any attempt to figure out what a “canonical plugin” is might be a waste of time, as it’s up to Matt, not us
<ul>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: The canonical plugins topic is related but not really connected. Agreed it’s not on us to decide, but also don’t think we need to do that to determine how to unbundle Performance Lab. The ask is to distribute the features as individual plugins – whether or not they’ll become “canonical” plugins isn’t directly relevant to the unbundling.</li>
</ul>
</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: As comment notes, we’ve considered three options so far:
<ul>
<li>Option 1: Keep PL as is, but additionally deploy modules as individual plugins</li>
<li>Option 2: Make PL a “wrapper” focused on central infrastructure and recommendation of individual plugins</li>
<li>Option 3: Deprecate PL completely in favor of individual plugins</li>
</ul>
</li>
<li><a href="https://profiles.wordpress.org/masteradhoc/" class="mention"><span class="mentions-prefix">@</span>masteradhoc</a>: Don’t see SQLite as something that needs to be in PL and WebP can also be standalone. How do you define if a feature should get into the plugin or be standalone? Would go for option 3 to keep everything separated and have some sort of list to keep track on what is being worked on. However, this still doesn’t solve the bigger issue – what happens if the argument is still to not merge them into core? What will make a canonical plugin in the end? How can we really move WP further in performance?
<ul>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: The idea is that <em>all</em> modules of PL are standalone features, so option 3 would mean each module would become its own plugin. The PL plugin has a lot of benefits that we would lose if we go with this option, which is why it’s the most unfavorable to me. There are several feature plugins that weren’t merged into core – either they continue to be developed to eventually get there or they get archived.</li>
<li><a href="https://profiles.wordpress.org/masteradhoc/" class="mention"><span class="mentions-prefix">@</span>masteradhoc</a>: In that case, think more of option 2. Wouldn’t do option 1 as it seems like duplication.</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: Yes, there would be duplicates, but it’s not necessarily bad. It’s the best of both wolds, similar to how Jetpack works as of today.</li>
</ul>
</li>
<li><a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a>: Could a feature be both a standalone plugin and in PL?
<ul>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: Yes, that’s option 1</li>
</ul>
</li>
<li><a href="https://profiles.wordpress.org/olliejones/" class="mention"><span class="mentions-prefix">@</span>olliejones</a>: We have one canonical plugin now, Akismet, that’s available to every WP install but not required – is that what Matt wants for performance?
<ul>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: Nothing would be pre-installed; let’s focus on unbundling as opposed to canonical plugins since we don’t know what those are</li>
</ul>
</li>
<li><a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a>: It seems to only make sense to break off larger feature like WebP or SQLite into separate plugins
<ul>
<li><a href="https://profiles.wordpress.org/masteradhoc/" class="mention"><span class="mentions-prefix">@</span>masteradhoc</a>: I wouldn’t install a plugin just to get additional Health Checks</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: It’s a blurry line – it would require the overhead of a discussion on every single feature to decide if it should be a standalone plugin. Would be in favor of a single consistent decision to save ourselves the overhead later. This is how feature plugins have always worked. FWIW several plugins have only ~50 installs because they’re so specific.</li>
</ul>
</li>
<li><a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a>: Could have a Performance Lab module and a GH repo template for them, would help with maintenance</li>
<li><a href="https://profiles.wordpress.org/joegrainger/" class="mention"><span class="mentions-prefix">@</span>joegrainger</a>: If we deploy modules as individual plugins, will they have their own repos and if so will they be in the WordPress organization?
<ul>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: Yes, only on wp.org would there be separate repos</li>
</ul>
</li>
<li><a href="https://profiles.wordpress.org/mxbclang/" class="mention"><span class="mentions-prefix">@</span>mxbclang</a>: Are we comfortable that keeping PL <em>and</em> deploying separate plugins fulfills Matt’s request? We would still have a single plugin with all of these features
<ul>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: We’ll have to see of course, but main ask was individual plugins</li>
<li><a href="https://profiles.wordpress.org/adamsilverstein/" class="mention"><span class="mentions-prefix">@</span>adamsilverstein</a>: Not sure this really meets his requests, he very explicitly said of SQLite that we should “stop putting additional things like this into Performance Lab”</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: From my perspective, since Jetpack does Option 1, this should be a reasonable approach</li>
</ul>
</li>
<li><a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a>: Jetpack is an example of a mono repo with multiple plugin projects: https://github.com/Automattic/jetpack/tree/trunk/projects/plugins, which is a good example of how Option 1 would work
<ul>
<li><a href="https://profiles.wordpress.org/kraft/" class="mention"><span class="mentions-prefix">@</span>kraft</a>: Jetpack system uses composer packages for things shared between plugins and they get called in via them, happy to answer any questions about the setup</li>
</ul>
</li>
<li><a href="https://profiles.wordpress.org/mxbclang/" class="mention"><span class="mentions-prefix">@</span>mxbclang</a>: Option 3 is also a burden for support, since each plugin has its own support forum that would need to be monitored</li>
<li><a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a>: Marketing is also an issue, where do we push people to?
<ul>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: Depends on the context, likely PL primarily, but individual plugins would also be available. A feature proposal post would highlight both as equal options for testing.</li>
</ul>
</li>
<li><a href="https://profiles.wordpress.org/olliejones/" class="mention"><span class="mentions-prefix">@</span>olliejones</a>: Option 1 lets us keep moving on development, but it carries the risk of Matt pushing back
<ul>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: FWIW both Options 1 and 2 carry that risk</li>
<li><a href="https://profiles.wordpress.org/adamsilverstein/" class="mention"><span class="mentions-prefix">@</span>adamsilverstein</a>: Makes me lean toward Option 2</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: Benefit of Option 1 is that it would continue to work as is for the people who have PL currently installed; Option 2 would require a complex migration that users likely would not understand</li>
<li><a href="https://profiles.wordpress.org/adamsilverstein/" class="mention"><span class="mentions-prefix">@</span>adamsilverstein</a>: Good point, thinking more of the end user who hasn’t tried “feature X” yet and having a separate plugin might be a better experience</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: Options 1 and 2 would be have separate plugins for each module</li>
</ul>
</li>
<li><a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a>: Having each functionality in its own plugin helps with testing</li>
<li><a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a>: What defines a module? Would the current Site Health checks all be together, for example? SQLite and WebP are clearly their own modules, but what about smaller things?
<ul>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: Great question and another thing to discuss for the future</li>
<li><a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a>: Defining how we break the plugin up helps with what option we pick – don’t want a bunch of “sub”-plugins</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: Yes, but this doesn’t affect which option we choose</li>
<li><a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a>: It does for Option 3</li>
</ul>
</li>
<li><a href="https://profiles.wordpress.org/olliejones/" class="mention"><span class="mentions-prefix">@</span>olliejones</a>: Plugin discoverability is a huge issue in today’s WP ecosystem and Option 1 helps discoverability. The category “canonical plugin” does seem to help with discoverability.
<ul>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: Fair to say that discoverability would suffer with Option 3.</li>
<li><a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a>: Marketing and support would also suffer</li>
<li><a href="https://profiles.wordpress.org/adamsilverstein/" class="mention"><span class="mentions-prefix">@</span>adamsilverstein</a>: Not sure about discoverability, if I want a SQLite feature for my site, a canonical plugin that does just that would be easier to discover than a feature within PL</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: Yes, but the standalone plugin would <em>always</em> exist with any option</li>
</ul>
</li>
<li><a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a>: If there’s a standalone plugin, will anyone bother with a PL plugin? What’s the point of it?
<ul>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: Depends on the audience. There are people that want one feature at a time and others who want everything in one place.</li>
</ul>
</li>
<li><a href="https://profiles.wordpress.org/olliejones/" class="mention"><span class="mentions-prefix">@</span>olliejones</a>: Happy with Option 1 for now. Taking a step back, discoverability is a REALLY big problem for WP themes, plugins, etc. The reason I suggested working on the definition of “canonical” is that it has the potential to address that. Know that we can’t solve that problem but it’s what Matt cares about.
<ul>
<li><a href="https://profiles.wordpress.org/masteradhoc/" class="mention"><span class="mentions-prefix">@</span>masteradhoc</a>: Agree, maybe next meeting could focus on how these initiatives can be moved forward</li>
</ul>
</li>
<li><a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a>: Personally think that all PL functionality should be opt-in</li>
<li><a href="https://profiles.wordpress.org/adamsilverstein/" class="mention"><span class="mentions-prefix">@</span>adamsilverstein</a>: Love the idea of canonical plugins at install time, Drupal does something exactly like this with their 10-minute install</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: That’s how I’ve been thinking about canonical plugins, as well, with WP core providing contextual recommendations</li>
<li><a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a>: Maybe we could have a setup wizard where you opt-in to the features that you want, like Web Stories</li>
<li><a href="https://profiles.wordpress.org/olliejones/" class="mention"><span class="mentions-prefix">@</span>olliejones</a>: Is there any way to get Matt’s approval of our choice, or do we have to do a bunch of work and risk it getting shot down?
<ul>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: We’d definitely reach out to him with a proposal once we have alignment within the team; we wouldn’t start any work before having buy-in from him</li>
<li><a href="https://profiles.wordpress.org/olliejones/" class="mention"><span class="mentions-prefix">@</span>olliejones</a>: Who will do that?</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: Potentially, will help in figuring out how to do that</li>
</ul>
</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: For next week, perhaps: I think are our options when it comes to the scope of how the current modules would be distributed as plugins:
<ul>
<li>Every module becomes its own plugin</li>
<li>Modules are grouped together based on their focus into a few “topic specific” plugins</li>
<li>Decisions are made individually, some modules become standalone while others are grouped into a topic specific plugin</li>
</ul>
</li>
</ul>
<p><strong><a href="https://github.com/WordPress/performance/issues/618#issuecomment-1377598692">Voting on an approach is now open in this GitHub comment</a> through Friday, January 20.</strong></p>
<p><strong>Our next chat will be held on <a href="https://www.timeanddate.com/worldclock/fixedtime.html?iso=20230117T1600"><abbr class="date" title="2023-01-17T16:00:00+00:00">Tuesday, January 17, 2023 at 16:00 UTC</abbr></a> in the <a href="https://wordpress.slack.com/messages/core-performance/">#core-performance channel</a> in <a href="https://make.wordpress.org/chat/">Slack</a>.</strong></p>
<p><a href="https://make.wordpress.org/core/tag/core-js/" class="tag"><span class="tag-prefix">#</span>core-js</a>, <a href="https://make.wordpress.org/core/tag/core-media/" class="tag"><span class="tag-prefix">#</span>core-media</a>, <a href="https://make.wordpress.org/core/tag/performance/" class="tag"><span class="tag-prefix">#</span>performance</a>, <a href="https://make.wordpress.org/core/tag/performance-chat/" class="tag"><span class="tag-prefix">#</span>performance-chat</a>, <a href="https://make.wordpress.org/core/tag/summary/" class="tag"><span class="tag-prefix">#</span>summary</a>, <a href="https://make.wordpress.org/core/tag/hosting-community/" class="tag"><span class="tag-prefix">#</span>hosting-community</a></p>
<p class="o2-appended-tags"><a href="https://make.wordpress.org/core/tag/core-performance/" class="tag"><span class="tag-prefix">#</span>core-performance</a>, <a href="https://make.wordpress.org/core/tag/meta/" class="tag"><span class="tag-prefix">#</span>meta</a></p>
</div>

The WordPress Foundation and WooCommerce have joined Automattic and Matt Mullenweg in countersuing WP Engine,…
The first-ever CloudFest USA Hackathon, taking place November 4 in Miami, will bring together contributors…
Canada’s largest gathering of WordPress enthusiasts drew a strong turnout at Carleton University last weekend,…
WooCommerce 10.3 was released this week, introducing one of the most requested features for store…
Automattic has hired GiveWP co-founder Devin Walker as Artistic Director for Jetpack, where he will…
WordPress 6.9 Beta 1 was released on Tuesday for testing ahead of its planned December…