This post is part of the conditional merge of the WordPress REST API.
Tracking and measuring specific success metrics is a priority for the WordPress REST API Content Endpoints project. The aim is to be able to look back at the implementation of the feature project to see how it went after the fact, and to utilize that information to inform future decision making.
A submission form will be created to help track implementations, in addition to automated scripting and analysis. Feedback will be grouped based on which metric it applies to. Developers and implementers will be polled to determine usage, where automation is a challenge.
It is very important to note prior to analyzing individual goals, that these goals and the achievement of them does not automatically indicate success, or that not achieving them means a lack of success. For instance, one metric that’s very hard to capture in goals like those that follow is the impact of a singular implementation. One highly impactful implementation could indicate a great deal of success, but would not be fully captured by the following metrics. These goals are established to help identify success metrics that would offer clear insight on the project, but they are not all encompassing or definitive alone.
Metric #1: Plugin utilization
Per the “Popular” plugins page of the WordPress Plugin Directory, the following can be determined:
- 21 plugins have 1m+ active installs
- 126 plugins have 200,000+ active installs
- 232 plugins have 100,000+ active installs
Many of these are not good candidates for utilizing the REST API, but there are a number of plugins that are.
The following goals are proposed:
- 15% utilization of plugins with more than 1 million installs.
- 7% utilization of plugins with more than 200,000 installs and fewer than 1 million.
- 3% utilization of plugins with more than 100,000 installs and fewer than 200,000.
Additionally, it is proposed to seek 5-10 examples of non-directory or otherwise prominent plugins, that may not fit the above metrics, to showcase their utilization of the API, and how it has benefited them. This may include commercial plugins.
Timeline for analysis: three major releases after merge (5.0 release day).
Metric #2: Distributed theme utilization
Popular themes are a bit of a misnomer in the WordPress landscape. The default themes or themes that have been around for a very long time account for a significant percentage of all active themes. And feature development isn’t as common for existing themes as it is for existing plugins.
In addition to polling free theme makers, top theme shops (according to Alexa) should be polled to determine usage of the API for theming purposes.
Additionally, coordination can occur with the Theme Review Team to identify usage of the API in newly submitted themes, to determine adoption.
The API could be useful in themes themselves, as well as complimentary plugins, which are not likely to be picked up by the plugin analysis. However, it’s difficult to know exactly how WordPress themes may use the content endpoints in a distributed theme context. It could be part of efforts within the customizer, page building, custom widgets, etc.
A goal of 2% adoption of the API in new themes is proposed, determined within three major releases, and analyzed amongst distinct ecosystems:
- New WordPress.org theme review submissions
- Third party theme shops (A shop using the API in any capacity, likely new releases, would count as “yes”, rather than theme by theme)
- Analysis of page builder or helper plugins
- Distinct theme communities with “builder”, “framework”, or “starter” themes.
Metric #3: Custom development implementations
The WordPress REST API is immediately useful for custom development projects, where the developer has control over the environment. The REST API in core provides a vote of confidence to outside developers that they are building with an API that has the full backward compatibility and stability expected of features in the core project.
It is proposed to identify 50+ projects in production or under development utilizing the Content Endpoints, within two major release cycles.
The likelihood is that there will be far more consumption-only applications, versus those that manipulate content. Within the same two release timeframe, the goal is to identify at least 12 custom projects that utilize the Content Endpoints beyond a read-only use case.
Metric #4: Core development and feature projects
The WordPress REST API can aid core development and feature projects. Items like Quick Draft, Press This and a menu bar revisions browser are test cases for using the API in a core context with WordPress 4.7.
Utilization of the API for additional core features and feature projects will be tracked over the next three major release cycles. It is proposed to identify 6 core features or patches than can utilize the API, as well as 1 feature project, within three major releases.