Proposing a New Plugin for Performance Lab

Do you have an idea for a new performance-related feature for WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.? Excellent! The Performance Lab plugin is a great way to implement and share the feature early on so that it can be tested on live sites and refined prior to an eventual WordPress core merge.

The 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 Plugin Directory or can be cost-based plugin from a third-party refers users to several other standalone plugins which are part of the overall Performance Lab program. Each of these plugins is a feature project for WordPress core and should be maintained in the WordPress/performance repository 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., which is a monorepo to centralize the development of all the performance team’s plugins with common infrastructure and best practices. This article explains how to propose a new plugin to add to the repository.

Lifecycle of a plugin as part of Performance Lab

  1. Plugin proposal: This is where the plugin is proposed, by opening a new plugin proposal issue in the WordPress/performance repository. Following the requirements around feature projects, the issue should briefly explain why the project is important to WordPress and how it fits in with the values and philosophies of WordPress. During this stage, the plugin purpose and scope, as well as basic information like plugin name, slug, and ownership are defined. The Performance Team then discusses the proposal in one of the weekly SlackSlack Slack is a Collaborative Group Chat Platform The WordPress community has its own Slack Channel at meetings and eventually makes a decision whether the plugin proposal is accepted or needs to be refined.
  2. Definition and initial implementation: This is where the primary plugin’s future implementation is being fully defined, after the plugin proposal issue has been accepted. This phase should begin with research and discovery around the feature, which then leads to a design doc and/or a proof-of-concept pull request for the plugin’s foundation. Most plugins will require multiple issues and pull requests to be completed, but it can help to build a solid foundation through the initial pull request, so that a first version of the plugin can be reviewed and tested. If multiple pull requests are required to implement a MVPMinimum Viable Product "A minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development." - WikiPedia, a feature branch should be used. The branch should then only be merged into “trunk” once the MVP implementation has been completed.
  3. Core feature announcement / proposal: This is where the feature is shared with a wider audience and proposed for eventual inclusion in WordPress core. After the initial definition phase for the feature, the next step is to formally propose it as a core feature project and share it beyond just the Performance Lab plugin users. This is done by publishing a feature proposal post on the Make WordPress Core blog as well as creating a ticket on Core Trac. The post should reference the standalone plugin as well as the overarching Performance Lab plugin as the recommended ways to follow along, contribute, and test the feature. This stage is where many more WordPress community members will become aware of their project – expect a lot of additional feedback at this point!
  4. Continued implementation: This is where the plugin continues being developed and eventually completed for its intended scope. Based on the feedback on the feature proposal, the initially envisioned approach may require a few adjustments. The MVP from the initial implementation can now be iterated on, or alternatively the implementation can begin from scratch. As the enhancements to the plugin are published via updates, users of the plugin will continuously be able to test the latest version of the feature.
  5. Core merge announcement / proposal: This is where the completed plugin implementation is proposed for a near-future merge into WordPress core. This is done by publishing a merge proposal post on the Make WordPress Core blog. This post should go a bit more into depth on the feature implementation eventually decided on, explaining some of the decisions made and referencing back to the original feature proposal post as applicable.
  6. Core patch: This is where the plugin implementation is ported into a WordPress core patch or pull request. Depending on the complexity of the feature, it may see more or less feedback after the merge proposal, and in most cases, a few refinements will be necessary to further improve the implementation based on contributor feedback. There is no fixed recommendation on when to create the core patch. It can be started before publishing the merge proposal, but it may be a good idea to wait for the initial merge proposal feedback in order to avoid having to do duplicate work (since preferably any necessary refinements would need to go into the plugin and the core patch).
  7. Core merge: This is where the feature actually gets merged into WordPress core. Once there is consensus among the core developer community that the core patch is good to go, it can be committed to WordPress core. It will then be included in the upcoming WordPress release. 🎉
  8. Dev note: This is where the finished implementation is described in detail, with a technical focus on any customization or extension capabilities. This is done by publishing a dev note post on the Make WordPress Core blog. It does not need to happen right after the core merge, but it should happen any time between the merge and the RCRelease Candidate A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. release of the version in which it ships.

It is important to understand and think through these stages when proposing a plugin, as getting a plugin into the Performance Lab program should be a temporary state that is a stepping stone to getting the feature into WordPress core. Every proposed plugin should have at least one defined owner that takes responsibility for eventually moving the plugin forward.

It is understandable that this can feel like quite the tedious task – however, rest assured that the rest of the Performance Team is there to help. If you have never posted anything on the Make WordPress Core blog, don’t worry – there are people on the team who can get you access and review your post drafts. If you have never contributed to the WordPress core codebase, don’t worry – there are people on the team who can review your code for core best practices. If you have never committed anything to WordPress core, don’t worry – there are people on the team who can do that for you. You can always ask any questions you have in the #core-performance Slack channel or, even better, during the open floor segment of the weekly chats in that channel.

Top ↑

Requirements for a new plugin

Based on the above lifecycle for a module, there are a few initial requirements for proposing a new module. The Performance Team would like to ensure that modules inside the Performance Lab plugin keep moving forward over time, and the requirements outlined here help set the foundation.

Other than outlining the purpose and scope of the module, every module proposal issue should define the following by using the new plugin proposal issue template:

  • The plugin name, i.e. what users see as the name for the feature inside the Performance Lab plugin. It is a good idea to use something that eventually can also act as the name for the feature project for WordPress core.
  • The plugin slug, i.e. the internal identifier for the plugin. Usually, this can be based on the plugin name, “slugified” (e.g. “My Plugin” becomes my-plugin).
  • One or more owners for the plugin (via GitHub usernames), to take responsibility for the plugin on its path towards WordPress core, also to be added as code owners for the plugin.

Every plugin proposal issue must have the “[Type] Plugin” label to indicate it as such. The new plugin proposal issue template should be used when opening such an issue.

Top ↑

Technical requirements

​​Implementing the foundation for the plugin’s key functionality as part of the initial plugin proposal PR can be useful (even just as proof of concept), but is not necessary.

However, as part of the initial pull request, the new directory for the plugin should be added, and the CODEOWNERS file should be amended to include the new plugin’s directory and the GitHub usernames of the plugin owners.

In addition to that, a new label for the plugin like “[Plugin] My Plugin” (where “My Plugin” should be the actual plugin name) should be created on GitHub and assigned to the initial plugin proposal issue and later any other issues related to the plugin.
For technical requirements of writing the actual plugin, please refer to the article of writing a plugin for Performance Lab.

Last updated: