# [Canonical Plugins Revisited])
The plugin directory is great, but many plugins are controlled by a single dev or company, and often end up going a direction of a premium or pro version, sometimes even removing functionality that used to be in a plugin and pushing it into the pro version. This can also create an incentive to put something into a SaaS service that is easily done in a more distributed fashion locally to the site. Even accepting donations can create some weird incentives for how to divide those among a number of contributors.
WordPress itself thrives because it’s a collaborative effort of many people with many varied interests, but coming together to create something that is explicitly open source, free, and available to all. We need to evolve the plugin directory to make it easier to accept code and documentation contributions. (We’re pretty good with translation contributions already.) Also I think we should build on the successful history of canonical plugins like MP6, Gutenberg, and REST API to have more community-developed plugins, called canonical because they will be the official first-choice recommendation by core and w.org for an area, that share in the ethos and approach of WordPress itself but to a more niche area that might not be right for core.
We are reaching a point where core needs to be more editorial and say “no” to features coming in as ad hoc as they sometimes do, and my hope is that more Make teams use this as an opportunity to influence the future of WordPress through a plugin-first approach that gives them the luxury of faster development and release cycles (instead of three times per year), less review overhead, and and path to come into core if the plugin becomes a runaway success. I am very conscious that when people are aiming to have something in core, a “no” or “not now” can be frustrating and sometimes create artificial pressure to put something in before it’s ready, as I believe happened with the REST API in WP 4.4.
Canonical plugin ideas for each make team:
**Design:** More admin themes.
**Mobile:** (not sure)
**Accessibility:** An alternative API-based admin designed for accessibility and simplicity.
**Polyglots:** Inline translation submissions for core and plugins and themes.
**Support:** Related threads or documentation pages dynamically loaded from w.org for the “help” dropdowns on every page.
**Documentation:** Experiment with adding more inline documentation to wp-admin interfaces. Gather opt-in stats on what is actually read and used, which links to .org get clicked on.
**Themes:** Better previews of theme customizations, activation workflows that allow customization of colors / images / typography.
**Plugins:** Inline rating and feedback for plugins, crash and compatibility data reporting back.
**Community:** Experiment with the dashboard widget that promotes events to call to action for organizing when there’s not a local meetup, and better incorporates online events including workshops and cohort classes.
**Meta:** Login with .org login account. Dashboard with all of your linked WPs on w.org. Monitor versions, install plugins with one-click, etc.
**Training:** Courses or training in every help dropdown.
**Test:** Opt-in JS or PHP error catching that reports back to a tracking server.
**TV:** Integration with help dropdowns, inline tutorial videos.
**Marketing:** Widgets and blocks for people to link back to W.org, like super-charged “powered by”, and promote their liked or favorite plugins and themes.
**CLI:** N/A.
**Hosting:** Experiment with standard hooks, icons, and menu items for hosts to link or embed things like email, domains, contacting support.
**Tide:** Show the data more places in wp-admin.
**Openverse:** Should actually just come into core more, but perhaps plugin would be a good place to experiment with submitting something to openverse and CC licensing any media upload. Community and collaborative tagging of uploads and openverse items.
**Photos:** Similar to openverse, make it possible to submit uploads and search directory.
**Core performance:** WebP conversions for new uploads and batch processing to convert old images. Show before-after space usage and page performance. ([Previous post on WebP in 6.1 that inspired this]).)
This is not meant to be an exhaustive list, and I’m sure the teams themselves could come up with much better ideas and options, but I hope it sparks discussion at contributor day and beyond on how we can utilize plugins better to increase the speed of evolution for WordPress, keep core light, fast, and opinionated, and do so while saying “yes” to more ideas and experimentation.
[ad_2]