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. :)