Back in December, the core team meetup included a couple of chats about plugins and how to make the plugin directory better. The notes from that were never posted (mea culpa), so since there has been a surge of interest recently in this, I thought I’d finally post them for reference. Apologies for the stream of consciousness style, that’s part of why they didn’t get posted earlier. 
**********
There are multiple areas that we should discuss: directory/repo/3rd pty repos/
There are two different points of view to consider: dev/user ux
Users
What should we be thinking about and trying to improve?
Dashboard, search/discovery – updated, popular, directory, updates, what we expose re ratings, compat, confidence/trust, stats/metrics (inspire trust), don’t put ones you already have in the dashboard box
Developers
What are the pain points and/or things we need to make better?
Managing forums, support, getting stats, translations, doing code, collaboration, adoption/abandon process, security, bug tracking, plugin review team, submission process/onboarding, slug/username/link/description
Start a plugin (unreleased development, packaging/releasing) vs host a plugin – what things do you need for each?
Hide ‘recently updated’ in dash box now from rss feed
What things are useful to users when deciding on a plugin?
- # downloads — active installs would be better
- ratings — reviews by trusted sources would be better
- #of individuals working on plugin — active within x time
- support response stats – response time, % responded, % resolved
- # support requests/# installs
- # active users/#support requests
- version compat
- known conflicts
- author-driven metrics. ex total cache, very responsive
- trusted authors program? weighting in search? bump based on core contributions
18 mos/2 year cutoff not shown in search
Complaints: some quality plugins are not maintained (hyperdb 2.5 yrs, automatic); updates in directory sometime don’t go through and updated date gets frozen otto/nacin/adams can’t figure out why this is
repo refresh every minute with locking instead or 15 minutes? talked to barry
need to email when plugin hits the time limit — 2-3 weeks before cutoff date to update readme
send email to everyone who uses a filter when we remove it from core
Action Item: make.wordpress.org/plugins!
plugin directory needs a way to bring people in
provide route to get involved
duck -best practices/education
westi – user: finding good plugins; dev: writing good plugins (security, review)
nacin -
koop – provide every plugin own trace = ton of work. use 3rd party repo, grab readme. let people use their own tools
matt – we said no bc we lose ability to take them over or update it. still want to have everything duped on our svn etc
github integration: we still need the code in our repo. require full sync/every commit? or just port it over each release?
will that move the needle? current setup just doesn’t encourage collaboration.
Action Item: Change language to say it’s ok on the page so it is clear that it’s blessed.
Action Item: dev contact form? based on profile?
Plugin review team/plugin advisory
- security review team volunteers known to nacin
- best plugin devs
- core contribs who also do plugins
Action item: Learn.wordpress.org/plugins
courses, workshops
matt: if you had a friend who wanted to make a plugin, what would you do?
westi: would email links to simple plugins, something less than 20 lines
jane: screencasts of walking through the file and explaining the bits (like viper did)
Make/Learn
plugin review team’s home will be at make
hackers helpful conversations move to make
-hackers archives not a good resource
-stack exchange? no, karma system makes it less appealing for some new people who don’t have time to build up points
What’s going on in the world of plugins? How can we be a resource for this?
- make: monthlyish discussions of plugins (submit for review), get patches/suggestions to deliver to author. becomes a resource also
- start with a blog. initial team: westi. viper. duck, mark jaquith — initial posting group. restrict author status [ed note: since this time, the pluginrepo review group has formed, of Otto, Scott Reilly, Mika/Ipstenu, Duck, Nacin, and Mark Riley]. seed with: inexperienced people – what do we need to post about? focus group, get to-do list of posts to write/get guest authors.
content:
1. simple stuff, intro stuff.
2. review one popular plugin per month, bring in author, hopefully they stay involved
3. posting about things posted elsewhere – good posts about plugins, error-prone posts about plugins
posting once per week
contacting plugin authors
security advisories — if a plugin gets closed until fixed, then after it’s fixed, post about the problem, how we informed them, and the fix. now go your plugin for similar issues.
where to put that: make/a-mess (heh)
Action: create blog, add authors , westi talk viper, posting calendar, pick 1st plugin and contact author. write first post.
———————
More Action Items:
1. move to usage base/position instead of downloads
position is objective/harder to game
this is separate from ranking (tax matching + downloads would be tax+position)
2. banners. custom headers for plugin pages, icon, moor graphical elements. can expose those all over. chrome web store good example, itunes store
exclude images in zip files? maybe just exclude custom header [ed note: this is active now]
3/4/5. remove extra radio buttons from search page, search only by relevance
**********
So those are the notes! The discussion at dotorgplugins.wordpress.com can hopefully feed into some of these goals (many are the same, I think) and we can finally put together the broader plugins contributor group that we imagined but never got around to cultivating.
David Lingren, 
Jane Wells 11:40 am on December 28, 2012 Permalink |
I’ll start off by listing stats similar to the ones suggested for themes:
Ipstenu (Mika Epstein) 3:41 pm on December 28, 2012 Permalink |
Length of time from plugin submission to approval is averaging just around 48 hours, for a complete, fully working, plugin with a readme and no guideline violations (which is what ‘directory rules’ are). Once we get into people whom we push back, it’s as much up to their ability to reply to emails within 7 days as our ability to sort through the email
(holidays and weekends and ZOMG! busy! change that, ut we’re pretty good).
We’d need a way better way to track why a plugin was closed for the last four. Right now we have to document manually.
Jane Wells 4:44 pm on December 28, 2012 Permalink |
“This is brainstorming… don’t think about APIs or if/how it could be collected, just throw out ideas in the comments of what information you think it would great to start seeing”
In other words, don’t worry about how it could or couldn’t be done, that’s a different conversation.
Marcus 1:57 pm on December 28, 2012 Permalink |
Number of plugins “compatible” with latest version(s) of WP
Ipstenu (Mika Epstein) 3:42 pm on December 28, 2012 Permalink |
Marcus – the problem there is we don’t test them after submission, so it’s up to the developer to remember to update their readmes. And the lack of an update doesn’t mean the plugin isn’t compatible. That distinctions way too wibbly-wobbley to rely on.
Jane Wells 4:44 pm on December 28, 2012 Permalink |
I think Marcus’s suggestion is a good one. At the very least, gathering the stats on which ones say they’re compatible to which version will be useful.
Marcus 1:12 pm on December 29, 2012 Permalink |
True, but that’s why I used quotes when saying “compatible”
Agreed it’s not perfect, in my case for example I do have some plugins that aren’t marked as compatible for the latest version (haven’t had time to update readmes), yet they are.
I think it’d still be nice to know because it is still somewhat of an indicator of what plugins are getting updated for latest WP updates.
I’d say another bit of data that could be use is the Works/Doesn’t work, but then this info isn’t that reliable either I’ve found.
Charleston Software Associates 3:37 pm on December 28, 2012 Permalink |
Plugin aging report = number of plugins in these groups: updated 0-30 days ago, 30-90 days, 90-180, 180-365, 1y+. Provides a general “age” of the plugin repository at several strata.
Is the plan to publish this for the general public somewhere near the plugins home page? Some of these metrics would be nice to know for site developers & plugin authors.
Jane Wells 4:46 pm on December 28, 2012 Permalink |
There’s no plan yet, since none of these stats are being collected yet. Eventually I’d like to be able to post nice monthly stats reports on the wordpress.org blog, and team-specific stats could also live in the team site and the public sections of wordpress.org. First we need to decide what information is worth having, then figure out how/if we can gather it, THEN decide where it gets published.
Pippin (mordauk) 11:32 pm on December 28, 2012 Permalink |
Number of abandoned plugins (ones without updates for 2 years).
Number of plugins with over xxx downloads.
TCR 1:01 pm on January 22, 2013 Permalink |
Agree with these. would be useful to have a filter on the plugin searches to exclude plugins that haven’t been updated for 2 years. etc.
jquindlen 5:35 am on April 12, 2013 Permalink |
I love this idea, it would save me so much time, and I think many other users would agree.