2015 Contributor Survey

Hi plugin review folks! Thanks for all your hard work and contributions in 2015. Could you contribute few more minutes to fill in the 2015 contributor survey? It will help us establish some baselines around the contributor experience so that we can see how things change over time.

**This is being posted to all the Make teams, so if you subscribe to a bunch of p2s and keep seeing this post, know that you only need to fill the survey in once, not once per team.**

The survey is anonymous (so you can be extra honest), all questions are optional (so you can skip any that you don’t want to answer), and we’ll post some aggregate results by the end of January. It took testers 5-10 minutes to complete on average (depends how much you have to say), so I bet you could knock it out right after you read this post! 🙂

There are two sections of the survey. The first has questions about team involvement, recognition, and event involvement, and is pretty much what you’d expect from an annual survey (which teams did you contribute to, how happy are you as a contributor, etc).

The second section is about demographics so we can take a stab at assessing how diverse our contributor base is. All questions are optional, but the more information we have the better we can figure out what we need to improve. If there’s some information you’d rather not identify, that’s okay, but please do not provide false information or use the form to make jokes — just skip those questions.

The survey will be open until January 15, 2016. Whether you have 5 minutes now, or 10 over lunch (or whenever), please take the 2015 contributor survey. Thanks!


Plugin/Plugin Team Stats

We don’t track our progress as a project very well. We have relatively few stats that we look at over time to see how we’re growing/changing, and those we do have are largely cobbled together with various combinations of manual labor and scripting. One of the things I want to do this year is get us going in the direction of collecting stats on our work and participation levels, and to make as much of it as possible an automated process. I recognize that this stuff is non-trivial. That said, I can’t create an overall wishlist for Otto to shoot down until we figure out what stats would be good to have.

What stats would be useful/helpful/just plain cool to know around your team? 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, say on a monthly basis. List any and all ideas, including stats you are already collecting. I’ll collate all the teams’ ideas and see what the Meta team says we can do.

@coffee2code: As team rep, can you try to rally your group to make suggestions over the coming week? Thanks!

Team Rep Results

9 people voted. Results: Scott Reilly as first lead, Pippin Williamson as second lead. New team rep terms starts with the new year, so I’ll get in touch with you guys to make sure everyone is on the same page re expectations. Congratulations, and thanks for your willingness to serve!


Team Rep Voting

Time to vote for team reps again! If you haven’t seen the spiel on one of the other team blogs about how team reps/voting/terms work, the longer explanation is after the jump. tl;dr version: time to elect reps for the first half of 2013. This past time it was Mark Riley and Scott Reilly, but since then Mark has stepped back from heavy involvement with plugins so you need at least one new rep.

Note: It can’t be folks who are already the team reps for other teams, and it should be folks who want to the responsibility (mostly posting weekly updates on team activity to the weekly updates blog). Since there are some newer members of this group it might be nice for one of them to level up and learn the ropes from Scott? Up to you guys. Anyone interested in being a plugin team rep should leave a comment saying as much so people know who they can/should vote for. Voting is open until December 15, and results will be posted here once voting closes.

Vote for Plugin Team Reps

Continue reading


Back in December the core team meetup included…

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


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

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)


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.


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. 🙂