Make WordPress Plugins

Updates from Jen Toggle Comment Threads | Keyboard Shortcuts

  • Jen 5:52 pm on January 4, 2016 Permalink |
    Tags: annual survey   

    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!

  • Jen 11:36 am on December 28, 2012 Permalink |  

    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!

    • Jane Wells 11:40 am on December 28, 2012 Permalink | Log in to Reply

      I’ll start off by listing stats similar to the ones suggested for themes:

      • Number of plugins in the directory (total, updated within past year, within past x months, etc)
      • Number of plugin developers in directory, high/low/average number of plugins per developer
      • Number of active plugin reviewers, high/low/average number of themes reviewed per person
      • High/low/average frequency of plugin updates/commits
      • Length of time from plugin submission to approval
      • Number of plugins per month accepted as is, rejected flat out, or given instruction on what to do to get accepted
      • Number of plugins closed at author request, and high/low/average amount of time since those plugins were last updated
      • Number of plugins closed for spam
      • Number of plugins closed for security issue
      • Number of plugins closed for breaking a directory rule
      • Ipstenu (Mika Epstein) 3:41 pm on December 28, 2012 Permalink | Log in to Reply

        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 | Log in to Reply

          “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 | Log in to Reply

      Number of plugins “compatible” with latest version(s) of WP

      • Ipstenu (Mika Epstein) 3:42 pm on December 28, 2012 Permalink | Log in to Reply

        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 | Log in to Reply

          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 | Log in to Reply

          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 | Log in to Reply

      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 | Log in to Reply

        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 | Log in to Reply

      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 | Log in to Reply

        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.

    • circlecube 6:26 pm on January 8, 2013 Permalink | Log in to Reply

      What about plugin ratings? Across all the teams plugins it could average the ratings or show the best rated plugin. Most reviews.

      Number of updates would be useful too (and/or frequency of updates), then you know if the plugin is tried and true or just went from 1.0 to 3.0.

    • rielf 7:07 pm on January 20, 2013 Permalink | Log in to Reply

      Where i can denounce a SCAM Pluguin?

      “Google adsense plugin” is scam….

      1: His donation system don t respect the google adsense terms and conditions and any google adsense account can be baned

      2: I insert my PUB correctly and all adds are from the pluguins programers.

      3: I setup de donation sistem in 0% and they are stealing my adds space whitout pay me.

      And i want to say that this pluguin is the worst adsense pluguin i never sawed, his configuration are simply ridicolous and you only can put the adds in the post….

      • Scott Reilly 5:03 pm on January 21, 2013 Permalink | Log in to Reply

        You should email plugins@wordpress.org to report abuse or spams/scams by plugins. Please include a direct link to the plugin’s page in the Plugin Directory so we know precisely which plugin you’re referring to.

    • Mark 10:45 am on January 29, 2013 Permalink | Log in to Reply

      Plugins, that are already outdated or haven’t used in years, can clearly be seen. Moreover, before updating the version, make sure it is compatible and last but not the least, don’t keep those plugins for too long that appears to be Spam/abuse and report them at your earliest!

    • zoranc 1:28 am on February 7, 2013 Permalink | Log in to Reply

      polling systems on the main plugin page(+api so it can be included in the plugin settings pages). This way users would be able to vote on features and overall plugin direction

    • David Lingren 8:53 pm on April 23, 2013 Permalink | Log in to Reply

      How about more information on the Support topics, e.g., average response time, time to resolve, number of unresolved topics? As a plugin author, one of my most frustrating tasks is looking back over all the topics and trying to find the items marked “Not Resolved”. I keep tripping over the “Not a support issue” topics.

    • Jason Kemp 12:01 am on December 12, 2013 Permalink | Log in to Reply

      Hi there,

      I’m not sure how to raise this as a related topic so please move it elsewhere if in the wrong place. Today I had a fatal erro on a plugin ( YARPP) it doesn’t happen very often but I was thinking if I could view the changelog for each plugin and see the dates each version was published on the repository it would be useful for finding those files when I need to do a fix. Also having dates in the changelog would give a better idea of how active a plugin really is. It may also help with stats which is the linkage here. I expect each version in the changelog has a date field but at present those dates are not displayed in the plugin repository so perhaps that could be a useful improvement to the plugin system generally?

    • Kalegley 4:25 am on August 8, 2015 Permalink | Log in to Reply

      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.

      Thanks !!

  • Jen 1:28 pm on December 24, 2012 Permalink |

    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!

  • Jen 2:34 pm on December 9, 2012 Permalink |

    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

    (More …)

    • Daniel Bachhuber 4:26 pm on December 9, 2012 Permalink | Log in to Reply

      I’d be interested…

    • Ipstenu (Mika Epstein) 5:22 pm on December 9, 2012 Permalink | Log in to Reply

      While I’m on the team, I’m content being a wrangler and not a lead. I could do it, but given my involvement with Support, obviously there’s a conflict there 😉

      • Jane Wells 5:28 pm on December 9, 2012 Permalink | Log in to Reply

        Well, what’s more important is which side you’d rather represent. If you’re more interested in being a plugins team rep, someone else could step up in forums. For that matter Scott could totally switch to meta team rep with Otto, too, if he’d rather.

    • mordauk 2:53 pm on December 11, 2012 Permalink | Log in to Reply

      I’m happy to step up.

    • Scott Reilly 11:04 pm on December 11, 2012 Permalink | Log in to Reply

      For those who don’t know, I’m currently the only active rep for the team.

      I am more than happy to continue in the role. However, there is also now the first official voting for reps for the meta team. Most likely Otto would be the de facto lead for that, continuing in his acting lead team rep position. That team doesn’t have very many candidates for potential reps (basically Nacin and I asides from Otto). If all the criteria Jane set forth are followed, it stands to reason I should be the secondary rep for the meta team, requiring me to relinquish my current status as a rep for plugins.

      Since Mika is most likely continuing on as a rep for the support team (at least for this term), Mark seems to have stepped back from involvement with the plugins team, and Nacin will likely continue as a team rep for core, that pretty much leaves Pippin as a prime team rep candidate.

      I’m cool with continuing on as a plugins team rep or moving on to the meta team, depending on where interest from others lie. If I remain we can prep Pippin as a secondary rep and follow Jane’s desired rep transition procedure, though leaving Otto as the sole meta team rep. If I switch teams, both plugins reps will be new and one will be simultaneously joining the team and becoming a rep.

      • Pippin (mordauk) 6:10 am on December 12, 2012 Permalink | Log in to Reply

        I’d prefer to step up as secondary rep, simply because I’m still getting used to being on the team in general. If you’d like me to go straight to full team rep, more than happy to do so, however.

        • Scott Reilly 8:51 am on December 12, 2012 Permalink | Log in to Reply

          That makes the most sense, and is my preference as well, for the two of us to be the team reps. Then you can continue on in the senior role next term, to be joined by someone else (either a new member to the team or one of the others who may be coming off a team rep role for another team).

  • Jen 9:48 pm on August 18, 2012 Permalink |  

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

    • dartiss 3:18 pm on August 19, 2012 Permalink | Log in to Reply

      Can I add a further topic? I believe the plugin repository is negatively affected by out-of-date and abandoned plugins. It’s fine to claim how many plugins are available, but if these haven’t been touched for years then I hardly think they’re both boasting about.

      I came across such a plugin recently but found I was unable to take ownership of it myself. I was advised that I should branch the code and make another plugin – this plugin was already a branch of another, abandoned version so was clearly not something I wanted to do.

      I was told that there is no way to assign clearly abandoned plugins to other authors who may be willing to take them on.

      As part of the metrics you’ve mentioned above, could we maybe have some kind of automated flagging system where admins can be told of plugins that clearly need looking at, with an automated mail being sent to authors. If no appropriate response if forthcoming the plugins can be marked as abandoned – other plugin developers can then taken them over.

      If a clear and robust process is put in place this should work and would improve quality over quantity.


    • JasonBC 7:31 pm on August 19, 2012 Permalink | Log in to Reply

      As a user, one item that I would like to see improved about plugins would be to see an install date field. This would be extremely helpful in tracking down what may have caused a certain problem or change in behavior. While it would probably be good to keep a personal log for each website, that’s easier said than done, so for me, just having an install date would be a lot of help.

    • Lance Cleveland 1:39 pm on August 20, 2012 Permalink | Log in to Reply

      As a WordPress admin, provide the ability to sort and/or filter by things like rating, last updated, and downloads (active installs) . To be truly useful, a need a combination filter. Rated 4+ and updated within 6 months. Both my clients and I spend days searching for, installing, uninstalling and generally “trudging through” plugins to find those that are functional and still supported our that can be easily forked and self supported.

      As a plugin author, commercial plugin support or at least acknowledgment would be great. I speak with a lot of plugin developers in our search to support our client’s sites and an alarming number have given up on plugins as they don’t generate donations. Many authors assumed their plugin work would at least buy them beer and pizza once-a-week and soon become disenchanted when they reach 6 months with not even enough to buy a cup of coffee.

    • Sergey Biryukov 4:41 pm on August 20, 2012 Permalink | Log in to Reply

      > What things are useful to users when deciding on a plugin?

      • Translations — being able to see whether the plugin is translated into their language.
      • Localized plugin directory — being able to read plugin descriptions and usage notes (or the whole readme.txt) in their language.
    • Greenweb 5:25 pm on August 24, 2012 Permalink | Log in to Reply

      Rating should be tied to a review like Amazon, this way the developer gets some feedback on why a the user had a bad experience. Hopefully the dev can use that as an opportunity to correct that.

    • DomainPawnshop 5:10 am on September 6, 2012 Permalink | Log in to Reply

      One thing that would be useful is some way to (easily) distinguish standalone GPL plugins from those that are just come-ons for a “premium” version of the same plugin (sometimes with a commercial license slapped on the package).

      In one example (WordPress Advanced Ticket System), the repository version of the plugin has more non-functioning features listed than functioning features. Each non-functioning “feature” reminds you that, “This feature only available in the premium version.”). And they also put a link in your WordPress footer that links to their “premium” plugin – even if you are using the repository version.

      In another example (All-in-One Event Calendar), the repository promises a free upgrade to the “premium” plugin, but neglects to tell you (either at the repository or on their site) that you are abandoning the GPL licenses by upgrading. (Somehow they magically made a commercial product derived from the GPL version of the plugin.)

    • Jane Wells 11:26 am on September 6, 2012 Permalink | Log in to Reply

      Only 100% GPL plugins are allowed to be promoted on wordpress.org. Looked at the ‘free premium’ one they push to, and it’s true, license not compatible. Labeled EULA.license, prevents distribution etc.

    • Thomas Michaela 7:55 am on September 7, 2012 Permalink | Log in to Reply


      would it be possible to hide the download counter so the plugin authors don’t need to fake the download numbers anymore, for example by releasing updates with no changes?


    • Daniel Chatfield 3:35 pm on September 8, 2012 Permalink | Log in to Reply

      Also could we *fix* the rating system – firstly I think we need to scrap the requirement to be logged into a wordpress.org account to rate (not many users have one), if authentication is really required (to prevent spam) then atleast offer other login providers like Google or twitter. Also could we have a separate metric for “ratings for this version” as almost all of the 1 star ratings for my plugin where made ages ago.

    • hiarlen 12:03 am on September 10, 2012 Permalink | Log in to Reply

      I’d love for the review process be moved to the dashboard. If I don’t like a plugin, I uninstall it and don’t go back to it in the repo.

      Uninstalling plugins could trigger a review process. This perhaps could be an opt it setting for Admins.

      Plugins I like should be reviewable right in dashboard. This would get more of the community involved.

      • elfin 7:46 pm on September 11, 2012 Permalink | Log in to Reply

        thereby increasing the negatives reviews. people are already more likely to leave a negative than a positive, this would just increase that.

        A better method of enticing users to rate etc should be found for the plugins that they do use and don’t uninstall would be a higher priority in my opinion.

        • donar 10:49 pm on January 13, 2016 Permalink | Log in to Reply

          hi i am new here not a developer , own 2 W/P sites , i would like to ask a question regarding plug ins in the forum but i do not know how ?? thanks donar

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar