I’ll be the first to admit that I think the WordPress Plugin Repository does some great things for WordPress and for its user base. When they rolled out the updated forums and the some of the new features, I was really excited about it.

But as time has passed, I’ve come to believe that the repository is more user-centric than developer-centric. Don’t read me wrong: I’m not claiming that this is an either/or situation. Ideally, both should be elevated to the same level.

On one hand, this makes perfect sense. After all, you have thousands of plugins all of which are available for users to search and download not only from the web, but from within the WordPress dashboard.

But plugins are created by developers – often times for free, obviously – but I don’t think that the repository does such a good job of supporting the work of the developers.

Sure, I agree that free hosting of your plugins is great and the ability to generate a landing page with several rich features based solely on a README is impressive, but each of these things also results in a number of issues that simply make it difficult to stay motivated to continue contributing plugins to the economy.

All that to say, I think the repository is a fantastic resource where users are the first class citizens. To that point, I want to outline several issues that I’ve experienced while using the WordPress plugins repository as a developer.

And for those of you who have read this blog, you know that I dislike when people offer problems without proposed solutions, so I’m aiming to provide those, as well.

1. Support Forums

Support Forums

Out of the box, I actually really like the fact that the WordPress Plugin Repository provides users with the ability to share their support requests with the developer.

Ideally, it should provide a centralized place for users to share their issues, and I also think there should be a place for users to submit feature requests. It should also notify the developer when a new issue has been created.

Unfortunately, it still places the burden of monitoring the support forums on the developer.

Whenever a developer releases a new plugin into the repository, a Support tab is automatically created on the plugin’s homepage. This is where user’s should go in order to dialog with the developer.

The problem is that the support system is basically a pull system and it puts the burden of pulling the new issues on the developer.

This means that every time I release a new plugin, I need to check that plugin’s support forum. If a new issue arises, I can subscribe to that particular issues thread via email, but only after I check the forum first.

Also, Brad reminded me of the RSS link available for each plugin at the bottom of the plugin page. Again, this is absolutely better than nothing at all, but it <em>still</em> creates the problem of a pull system.

As such, I have to have weekly reminders to check the support forum for each of my plugins and subscribe to any new issues.

As soon as the plugin is live, I should automatically receive emails when a user posts an initial issue, and then I should have the opportunity to opt-in to future emails on a per-issue basis (just like it works now).

2. The Rating System

The Rating System

The rating system in the WordPress Plugin Repository is the feature that I take issue with the most. I understand the need for ratings – it’s meant for users to vet the software that they are about to install in their WordPress setup.

But the rating system places too much power into the hands of users without vetting the reasons for the user’s action.

Case in point, I have one plugin that has received a 1-star rating that reads:

Does not do anything.

There’s no support forum request or anything feedback to let me know what issues this person has experienced. That very same plugin has a couple of five star ratings.

That’s a serious gap, isn’t it?

The problem is that user’s can give a plugin a single star if they think that it doesn’t work, if they dislike it, or out of pure malicious intent. This will bring the entire rating of the plugin down greatly and there’s no way for me – the person who authored the plugin – to contest that rating.

Secondly, I believe that the rating system should be behind a pay wall. The WordPress plugin repository automatically generates a donate link based on the URL provided in the plugin’s source code, but I can tell you that the ratio of donations to downloads is less than 1% – at least for me.

I believe that only people who have made a donation and who have opened a support ticket and have had it resolved should be allowed to leave ratings.

3. User’s Don’t Read (A Lot Of Work and No Return)

FAQ

Finally, I receive a number of questions via email about why certain things work the way they do, or if something is going to be incorporated in a future release.

First, I want to admit that there are very few things more rewarding to a developer than hearing from someone who uses your work and wants to see it improved.

That said, I’m one of those developers who makes sure to detail issues in both the forums, in the changelog, and occasionally in the FAQ so that users can always find the answers to most of their questions.

But users don’t read.

9 times out of 10, I’ll receive questions that I’ve already answered in some form or fashion in the support forum or on the plugin’s homepage.

Despite all of the tools that the WordPress plugin repository provides, users will always take the path of least resistance and go directly to the source if s/he is available. I don’t blame them. I’d do the same. It’s human psychology, right?

And this is where user interface design and user experience come into play. If users can’t find the information they are looking for despite the fact that the developer has provided it, then I’d argue that the user interface is failing the user and improvements need to be made.

Developers as Second-Class Citizens

In speaking with other developer friends, these issues aren’t above aren’t the only ones that developers experience, but I can only speak out of my own experience.

To that end, the issues above are the three main issues that I’ve experienced as trying to contribute back to the WordPress economy with plugins.

But I think that this breeds a much more significant problems for developers at large: One of the biggest issues with the WordPress plugin’s repository is the quality of the plugins that are approved.

Though this process is getting better (as I know and have massive respect for some of the developers who are involved with the approval process), this doesn’t discount the thousands of other plugins that have been approved, and that are still available for download.

The problem that this creates is that those of us who love WordPress and its associated software, try to contribute back to that economy, and that attempt to provide quality applications for WordPress are simply dealing with more frustrating than reward.

This motivates us to go about selling, supporting, and managing our own plugins potentially decreasing the quality of plugins and developers who are sharing their work in the WordPress plugin repository.

And on one hand, that really sucks. But on the other, if user’s are motivated and rewarded to do all of the above, then developers have their own motivations, as well.

Category:
Articles
Tags:

Join the conversation! 101 Comments

  1. Have you checked this out: http://plugins.uproot.us/

    It doesn’t address everything but it’s pretty sweet.

  2. Regarding your pay wall suggestion, what are your thoughts on this situation?

    Someone installs a plugin and for some reason is unable to get it working. So they open a support ticket and the developer never helps / has stopped supporting the plugin / is oblivious.

    The ticket is never resolved and the user is never able to leave feedback. So you have a (potentially) bad / broken plugin that can receive no bad ratings because of tickets never resolving.

    ( I like where you’re heading with the idea, just wondering what you thought about that. Great post! )

    • You bring up an excellent point. Some of this is also addressed in my comments with Pippin, but I think the use case is perfectly valid.

      The most, I’m clearly outlined the ideal use case, but the fringe cases or these cases where a user’s cash is taken and they are provided no value is certainly bad.

      So perhaps there must be a two way transaction: The user doesn’t pay to rate the plugin, instead, the user offers to pay and the cash is held – much like with Kickstarter – and then when the problem is addressed, their are debited.

      If, after X number of days, the problem isn’t solved, then the cash never performs a transaction.

      Realistically, this is a lot of overheard and I don’t pretend to oversimplify the problem. But simply put, perhaps there needs to be a greater “handshake” mechanism in place.

      • Applaud all of you for running with this thread. To improve the quality and quantity of ratings, automatically add a rater profile with the rater handle (Yelp like):

        1. “Rate the Rater” and 2. “Present rater stats (# of ratings. average rating. link to all raters ratings and comments).

        Like Jon Brown suggested “Third the crowd needs to be sourced by empowering them to filter bad reviews out”. And like Tom said, make it effortless for the user.

        And re: Donations: The perfect time to donate is after you’ve been using the plugin for a while and confirm it’s usefulness. Granted, by waiting it’s easier to get busy and forget but with some form of public recognition, donations would go up. i.e. Display a $ sign as another Rater Profile stat to encourage donations.

        • I may be misunderstanding your point above (which is possible considering it’s late and I’m tired), but are you saying that we should be able to rate the person rating the plugin, or that the rating of the rater (that’s a mouthful) is based on his/her aggregate of ratings?

          Either way, that’s too much rating for me ;).

          All kidding aside, there is clearly a problem with the rating system, but there’s not a clear solution hence the discussion that’s ensued.

          If a developer has control, then he can simply remove the rating
          If a user has a control, they can provide negative ratings without any real merit on properly using the plugin or contacting the developer.

          The more I think about it, the more I think ratings need to be bound to support requests. ‘

          And re: Donations: The perfect time to donate is after you’ve been using the plugin for a while and confirm it’s usefulness.

          Developer could build in time-sensitive nag screens, but I’ve mixed feelings on that. I don’t want to hound people for cash (really, I don’t!). Plus, I want the donation to be out of generosity and utility.

          You’d think that a person who was enjoying a free plugin would think “Hey, how can I show this developer I appreciate his work?”

          But I think there’s a whole other issue wrapped up in this that I’m debating whether or not to cover in another post. It basically deals with a sense of entitlement that’s bred as a result of receiving something for free.

          I don’t know if I wanna tread in those waters, though!

          • To clarify, not saying “we” should rate the rater. The system should automatically show aggregated rating history across all plugins by user next to their comments.

            Main points:
            1. Show rater stats so readers can judge quality
            2. Link from a comment to all other comments from that rater across plugins.
            3. Crowd source ratings to weed out unjustified ones.
            4. Include donation icon next to user to encourage giving.

            Thanks again for awesome topic.

  3. While I am completely with you on the problem of ratings (I find users use them as support requests), requiring that a user submit a support ticket and have it resolved before they can leave a review really doesn’t work. What about users that have tried to get support but the developer has given none? That justifies (sometimes) a poor rating. What about users that simply want to leave praise for the plugin and have never had a need to raise a support ticket?

    I’d personally prefer to have ratings as they are now than to have them behind a pay wall that requires donations. If users had to donate before they could rate, my plugins with dozens or hundreds of ratings would have, at max, maybe two or three.

    I do have a quick solution to the notification problem. Anytime you release a plugin, simply create a sticky “Support Policy” thread. Once there is at least one thread, you can subscribe via email to all new topics.

    The problem with existing crap code is a big one, but one thing you (and everyone else) can do is report any and all bad plugins to plugins(at)Wordpress(dot)org. For example, find a plugin that is loading custom jQuery, let us know and we will disable it.

    • What about users that have tried to get support but the developer has given none? That justifies (sometimes) a poor rating

      I think we’re on the same page here, but I figure I’ll go a bit longer with this :).

      This is a really good example. There’s a question here, though: Let’s say the plugin actually does work, but the user opts to give the user a 1-star rating because they don’t understand how it works or don’t take the time to read the documentation.

      It could be a well-built plugin, following coding standards, use best practices, etc., but if the user fails to understand how to use it if they’ve not read any of the documentation (I know, there’s a lot wrapped up about UI/UX in this statement alone, but I digress … at least for now), should they still be allowed to leave a rating? Or perhaps they should be allowed to amend the rating.

      Can they even do that? That’s a legitimate question as I honestly don’t even know.

      I’d personally prefer to have ratings as they are now than to have them behind a pay wall that requires donations. If users had to donate before they could rate, my plugins with dozens or hundreds of ratings would have, at max, maybe two or three.

      I like the pay-before-you-rate model more. In the post, I should’ve done a better job of clarifying that, but this is what comments are for, right?

      I do have a quick solution to the notification problem. Anytime you release a plugin, simply create a sticky “Support Policy” thread. Once there is at least one thread, you can subscribe via email to all new topics.

      I view this as a “solution-hack” type deal. I know several local plugin developers who have done exactly this and have still suffered from low ratings, people saying she won’t support the plugin, people leaving incorrect comments, etc.

      Admittedly, I love little things like this that get us one step closer to something better, but I still don’t think this is enough.

      The problem with existing crap code is a big one, but one thing you (and everyone else) can do is report any and all bad plugins to plugins(at)Wordpress(dot)org. For example, find a plugin that is loading custom jQuery, let us know and we will disable it.

      Absolutely. And you’re one of the developers I was referring to in my post :). In fact, I may do a follow-up post to this one specifically highlighting that developers can be proactive in helping to filter out the bad plugins.

      That’s certainly something that we all – as the plugin community – need to do. From supporting a premium WordPress product, I can tell you that poorly written plugins are one of our number one offenders.

      • Oh I will never argue against there being a problem with users leaving ratings that aren’t justified. I get them a lot, but I fear locking them behind a pay wall would actually cause a more significant problem by resulting in zero ratings.

        One improvement I’d love to see is the ability to convert a rating into a support ticket. For example, I see a lot of ratings that go like this:

        1 star
        I can’t seem to make it work, can you help me?

        Clearly that should be posted as a support ticket.

        In terms of amending ratings, yes, you can do that. The person that left the rating has the ability to change it.

        • I fear locking them behind a pay wall would actually cause a more significant problem by resulting in zero ratings.

          I shared with TIm that perhaps there should be a greater handshake mechanism for payment.

          I’d rather have few, honest ratings, that are behind some type of paywall, than a free-for-all-rate-all-the-things-however-I-want.

        • I like the idea of converting ratings into support tickets. How about a system that worked like this:

          1. User leaves a low rating.
          2. Developer converts rating into a support ticket (initial rating is removed from the aggregate rating score) and has a pre-defined time limit to respond to the ticket. If developer fails to respond within the time limit, initial star rating is approved.
          3. If developer does respond, the response time limit is removed. Once the developer feels the issue is resolved, he/she asks user to rate the plugin again, based on the support they have received. This new rating replaces the initial rating. Once the developer has responded, the user is free to re-rate the plugin at any time.

          This process would only apply once. If a rating has already been converted into a support ticket, it should not be possible for the developer to repeat the process.

          Obviously for this to work well, developers would need to receive notifications of ratings and support tickets.

          • I like the idea of converting ratings into support tickets.

            Funny – I just mentioned something like this in this comment before reading this.

            But, dude, your idea. I really dig it. Nice stuff here.

          • I’d like to propose some modifications to my previous Rating to Support Ticket ideas. I’d also like to propose as darrinb suggests, that aggregate rating scores are weighted. So, how about something like this…

            1. User leaves a low (1 star) rating.

            2. Developer (and only the developer) has the ability to converts rating into a support ticket. As before, the initial rating is temporarily removed from the aggregate rating score while this process is in motion).

            3. Reviewer receives notification (by email) stating the developer of the plugin would like the chance to assist them with whatever issues they’re having by changing the review into a support ticket. Reviewer has the choice to agree or leave the rating as is.

            3.1 If the reviewer agrees to convert the rating to a support ticket, the developer has a set amount of time (to be defined) to try and resolve the issues.

            3.1.1 If the developer has made attempts to help the reviewer, he/she can then ask the reviewer to rate the plugin again. This new rating replaces the initial rating. The new rating score is of course dependent on whether the reviewer is satisfied with the outcome of the support request.

            3.1.2 If the developer makes no attempt to resolve the issue within the allocated time period, the initial rating is restored and is included once again in the aggregate score.

            3.2 If the reviewer does not agree to convert the rating to a support ticket, the initial rating is used, but the weight (relevance) of this particular rating is further reduced when calculating the aggregate score. Also, since a review must be submitted to rate a plugin, a notice is displayed next to this particular review stating that the developer offered to assist with any issues the review was having, but the reviewer declined the invitation.

            As stated previously, this conversion process should only happen once for each rating. If a rating has already been converted into a support ticket, it should not be possible for the developer to repeat the process.

            Also, I believe plugin authors should be able to specify that they do not wish to provide support for their plugin. If support is not provided, the option of converting a rating to a support ticket will not be available, and plugin authors must simply bare the consequences where ratings are concerned. However, if support is not offered for a plugin, this should be clearly stated on the plugin description and/or support page. I initially thought it might be easier to just disable the support page for the plugin, but it is often the case that if the developer of a plugin does not offer support, other rockstar community members gladly try to help. Maybe a setting in the plugin’s README file could include a setting for “unsupported”. Obviously, for backwards compatibility, it would be assumed that plugins without this setting in their README are supported by the author.

            It would also be great to show an arbitrary source code repository URL for a plugin on the Developer page/tab, which could also be defined in the plugin’s README file. This would allow developers to display a link to their plugin’s GitHub (or any other VCS) repo. As stated, this should only appear on the plugin’s “Developers” page/tab, maybe under the “Browse the Code” section, and titled “Development Repository” or something similar.

            I think this process would provides a pretty fair balance between the reviewer and developer. What do you think?

            • Overall, I think this is an extremely well-thought out and reasoned response.

              Personally, I’m still not sold on weighted-ratings simply because of the lack of clarity that this would introduce from the user’s end. I think we could claim that users are non-the-wiser to how the ratings are generated, but they do have expectations that it’s simply an average of sum total of the ratings.

              After all, isn’t that what we all assume when visiting other sites?

              Other than that, I think you’ve hit on some really good ideas.

          • I really like the idea – but sometimes users are just not responsive (see this example where the user only initially responds and then stops, nor adjust the rating).

            What happens then? Does the rating stick?

            • I think after the author responds to a support ticket conversion like that the reviewer should be prompted once to revise or delete their rating, but ultimately the reviewer can ignore it and let it stand as is.

              That’s review is a good example. The reviewer is using an incompatible version of WP, perhaps your plugin should check for the WP version and not activate. His review is valid, he had a bad experience.

              I know that if I looked at that review thread I’d be WAY more likely to use your plugin than if there was no 1 star review with a clear support response.

          • I like this approach Emzo.

            I’ve got a few 1 and 2 ratings on my plugins and I have absolutely no clue as to why I got them, especially since I’ve actively supported all the plugins I have in the repository and indeed have many users who are happy with the plugin.

          • Absolutely brilliant… I agreed so much with this article but this really does seem like a way to even the keel on the ratings.

    • Pippin is right, there can’t be a paywall, or a requirement for having an answered support post just to rate a plugin.

      I have a plugin with 5k downloads that has six 5-star ratings out of six total reviews. The plugin has also had zero donations. Would I still have any of those six 5-star reviews on there if it required a donation? Maybe, but not likely. Besides, it’s not a “donation” if it’s required. No-one is even required to purchase an item on Amazon in order to write a review of it, and those factor into their item ratings.

      The whole point of those ratings is that anyone can leave whatever rating they want to on there for *any* reason what-so-ever. As long as your plugin is doing better than the average, what does it matter? If the abuse is really just random as you’d suggest, it should be across the board on everyone’s plugins and themes.

      The best thing WP.org could do is what they already did – require that you at least actually type something up when you give a star rating. I can tell that just by doing this, the number of ratings actually coming in has dropped significantly already. Although, it would be interesting to see what the average rating was for those empty reviews compared with ones that are filled out.

      • I have a plugin with 5k downloads that has six 5-star ratings out of six total reviews. The plugin has also had zero donations. Would I still have any of those six 5-star reviews on there if it required a donation? Maybe, but not likely.

        Though I genuinely agree with you, I think this becomes of a question of what’s more important to the developer – the donations or the ratings?

        Personally, I don’t have an answer. It’s purely subjective, but I do know that for the amount of support that I get in my inbox on a weekly basis, I’d much rather have the donations for the time spent helping users than a rating that I have no way to know if it’s being used.

        The donations are measurable. The ratings impact are not.

        Again, subjective, but that’s my take and hence the reason I’m moving back to the whole premium model.

        Besides, it’s not a “donation” if it’s required. No-one is even required to purchase an item on Amazon in order to write a review of it, and those factor into their item ratings.

        Oh, definitely. It’s a payment :). I’m with you there.

        But is it fair to draw an analogy between the ratings of a software application for open source software that someone may not understand to ratings on a site where a user may have conceivably used the product after purchasing it elsewhere, or have incentive to review (such as some point system, Amazon credit, etc)?

        Again, just playing devil’s advocate. I’m not being snarky against your comment as I do appreciate it.

        This conversation is something that’s important to me – anyone that’s read my previous posts on what I’m working on doing knows that I’ve probably talked this to death.

        • what’s more important to the developer – the donations or the ratings?

          I have no standing here to comment as I have no plugins on .org, however I’m going to anyway. If people want to sell their plugins there are plenty of venues to do that and I highly encourage the practice. If a plugin is on .org I feel like the author has explicitly forgone any expectation of getting paid for it and that reviews and code contributions are way more valuable than a few small donations. Maybe I’m naive and plugin authors really do value donations.

          • As someone who has a few plugins in the .org repository, I can personally vouch for the fact that I don’t value donations for the work of building the plugin, releasing the plugin, and maintaing the plugin.

            I do value donations just as someone values a “Thank You” card in the mail for a job well done; however, the act of supporting the plugin is something that becomes an overwhelming responsibility at times.

            The thing is, I’m not sure you can have it both ways.

            Sure, you can opt to say “Here’s the plugin, but I don’t provide support for it,” but I know people personally who have done that, have done great work, but received 1-star ratings for that.

            FWIW, you’re not naive – you bring up valid points :).

  4. I’m pretty sure when I release a plugin I automatically receive emails for any posted support topics – I don’t need to go and check.

    If not, click on the support tab and under the list of topics you should see a “Subscribe to Emails for this Plugin” link to receive emails whenever anyone posts a new topic.

    • You’re not the first person to have mentioned this to me – but it’s never worked for me. I’m totally cool accepting the fact that this may be an isolated incident and I’m just on the receiving end of it, too.

      Oh! And I know there’s an RSS feed link at the bottom of each support forum topic, too. I meant to mention that in the post, so I’m going to amend it after this comment, but my main problem with that is that it’s:

      Still a pull system (in that I have to subscribe and check my feeds)
      The size of the link is so small that it’s easy to miss if you’re not looking for it or expecting to see it

    • The problem is that there isn’t a list of topics for a new plugin. This link doesn’t exist. I’ve had the same issue as Tom and Pippin.

  5. I have similar gripes with the Plugin Repository. I’ve chosen to not release certain plugins in the WordPress Repo (and leave them in GitHub) because then it’s less of a headache to respond to GitHub issues.

    • I’m debating whether or not to move all of my plugins to GitHub. I am leaning in that direction and I plan to cover it in another post, but I will say that I’ve noticed for the plugins I do have on GitHub, I only get developer / really-techy feedback.

      This is great, but I think we must provide an alternative for our customers that’s incredibly easy for them to get in touch with us with their day-to-day issues.

      • I love github-only plugins, but by doing that you immediately lock out the non-tech users. Assuming your plugin isn’t meant for developers only, this is an obvious problem. Sure you can get around it by publicizing your plugin on your own site or whatever means you have, but that then raises the issue of creating your own support system. I run my own support forums (and the WordPress.org forums) so I’m a strong proponent of that but it’s not for everyone.

        • I agree 100% with the GitHub-only plugins. I think that this is part one of the two part system for managing plugins better.

          First, it brings the techies to your plugin who can contribute and make it better – that’s a win because of the target audience.

          Secondly, and I think it was discussed in this post, the support component has to be absolutely as frictionless as possible for customers.

          So GitHub is fine, but only when it’s coupled with the best support system that I can find which is ultimately what I’m aiming for.

  6. Would be nice if you could associate a GItHub repository URL in the readme.txt, then have some sort of nice GitHub integration there for real workflow (read: feature enhancements, bug reports, enhancements, etc) outside of the normal support threads.

    Something I haven’t seen yet though is what you find on WordPress.com support forums, when you start typing your support request, aren’t there “suggestions” that come up? I think that should be implemented here, and show suggestions by forum. So if you’re posting in a plugin’s support forum, it should show suggestions related to what you’re typing about but only in that plugin’s support forum. Would be nice if it was implemented across the .org forums too, but I would find this would really help.

    It could also be beneficial to recommend codex pages based on keywords too, incase the user is brand new to WordPress too.

    • Would be nice if you could associate a GItHub repository URL in the readme.txt, then have some sort of nice GitHub integration there for real workflow (read: feature enhancements, bug reports, enhancements, etc) outside of the normal support threads.

      Yes and no. Personally, I don’t want my users or customers to have to learn GitHub. New developers have a hard enough time. Asking a user to do it just seems like a bad move.

      Now if they are a techy user, I’m all for it because they’re likely already on it or can figure it out.

      That said, using a user-friendly support system is key for creating the least amount of friction for the users to share their requests.

      I think that should be implemented here, and show suggestions by forum. So if you’re posting in a plugin’s support forum, it should show suggestions related to what you’re typing about but only in that plugin’s support forum

      Ooh. I dig this.

      I wouldn’t even mind seeing a “Did you mean…?” because I’ve had people ask questions about another plugin on my plugin’s support forum.

      That’s a whole other post, though :).

    • Your idea made me think of something else that could be done: parse the FAQ, the plug-in’s read me and/or previous questions to point the user to those threads instead. Similar to Stack Exchange websites. I think that would be useful to both developer & user.

  7. For developers with multiple Plugins hosted in the directory, there is an incredibly handy RSS feed for support topics for all Plugins by a given committer:

    http://wordpress.org/support/view/plugin-committer/{username}

    This is, for me, the only possible way to keep track of support requests for multiple Plugins.

  8. Lately I am beginning to like the plugin repository better. Perhaps they added to many features and it’s take some time for useful information to accumulate.

    I do have a beef on the way developers manage their plugin site.
    Information is presented inconsistently. Many plugins have empty tags.

    As I am not a developer I am not aware if the Codex has guidelines or not for developers on how things should be presented.

    Also, it would be nice if plugin sites ALWAYS certain information. For example – multisite which for most plugins can be answered very quickly and for the others the developers are probably documenting it already.

    • Lately I am beginning to like the plugin repository better. Perhaps they added to many features and it’s take some time for useful information to accumulate.

      And based on your comment, you are a user to it’s great to here your thoughts. It does reinforce the idea that the repository is geared more towards users than developers, though, and I think there’s a happy medium still to be had.

      I do have a beef on the way developers manage their plugin site.
      Information is presented inconsistently. Many plugins have empty tags.

      No argument here: This is just lame on developer’s part.

      Also, it would be nice if plugin sites ALWAYS certain information. For example – multisite which for most plugins can be answered very quickly and for the others the developers are probably documenting it already.

      Agreed! I think there should be a standard ‘set of instructions’ for lack of a better term that are required to have the plugin’s published.

      That’s a really good though. Thanks for offering that up.

  9. Here’s an IFTTT recipe to get an email when a new RSS item appears in a feed: https://ifttt.com/recipes/85672

    :)

  10. The repo is flawed in some ways, sure, but as a hosting platform it’s pretty good.

    However, my biggest issue is with the Support forum. If you have a popular plugin, you could get hundreds of threads. A lot of it is easily answered if the user reads the FAQ, as you’ve pointed out.

    In my opinion, the Support forums place an undue burden on the developers. The fact that it’s called “Support” sets an expectation that is unrealistic — direct one-on-one access to the developer in a timely manner. And that’s just not scalable. I think it’d be more helpful if it was called “Help” or “Community.”

    If WordPress wants to make it easier to help users, they should revamp the plugin-specific forums to work more like a bug tracker instead of a message board.

    • The repo is flawed in some ways, sure, but as a hosting platform it’s pretty good.

      Agreed – I love that it generates such a nice homepage based solely on a README file and an image asset.

      However, my biggest issue is with the Support forum. If you have a popular plugin, you could get hundreds of threads. A lot of it is easily answered if the user reads the FAQ, as you’ve pointed out.

      My biggest issue with this is that people do not read. I get a number of emails for things that are already covered elsewhere which raises the question: are the FAQs and changelog that needed?

      Personally, I think yes. The squeaky wheel gets the noise.

      But the problem still exists.

      And that’s just not scalable. I think it’d be more helpful if it was called “Help” or “Community.”

      Bingo.

  11. I have often wondered why there’s no option to send notification emails when a support ticket has been opened. And the RSS doesn’t work either, not sure how it is now but it was broke when I tried it.
    I used to just manually check the support pages, but now I have 26 plugins, and manually checking every one is a huge waste of time. I’d love to provide faster and better support for my plugins, but sometimes I feel like the .org repository is deliberately making it hard for me to do that. :(

    • I don’t know if it’s deliberately making it hard for you, but it’s doing so by design and that’s why I think the repository was designed for users first, developers second.

      And this is why I’m looking to begin making the shift to an alternative platform within the near future.

      I don’t have near as many plugins as you but it quickly becomes near unmanageable.

      I feel your pain, man.

  12. First, don’t get me wrong — I love wp.org and I totally acknowledge that the repositories are a constant work in progress and it’s discussions like this that help make them better.

    The biggest issue I have these days is in workflow. I do almost everything in Git now. I love how much more flexibility I have creating a nice-looking readme.md on GitHub as compared to what I can do with a readme.txt on WP.org. The “pseudo-markdown” — while at one point I thought was pretty cool — is now feeling greatly inferior to actual markdown. I love how, in GitHub, not only do I receive an instant notification (whether I asked for it or not) on not only repositories I created, but repositories I’m following, but that they are live updating — I can go away and come back with the page open and see someone’s reply or commit.

    But more than that, I never open a Subversion client. In fact, the only thing I use Subversion for these days is WordPress.org, specifically. Typically, when I start building a plugin, I’ll create a GitHub repo for it, start committing my changes there, then, when it’s ready to go, I’ll open up my SVN client, copy everything over, and commit that to WP.org (after the plugin is approved, of course). I understand that the SVN part is tied directly to Trac and Trac is OSS, and it’s how .org handles everything and it’s not likely to ever change (unless there’s a GitTrac, which there may be) and if it does it will be a HUGE process, something that no one will want to take on, will (arguably) have very little benefit to the users and will likely result in broken repositories somewhere along the way, but that’s the thing that makes .org feel the most unfriendly to me. I find myself wishing I could just use GitHub for everything or that there was some way to integrate the two things.

    • unless there’s a GitTrac, which there may be

      Yes, Trac supports git as well.

      But there is a huge amount of work to be done to even support it with the plugins repository. I will certainly be one of the first people working on that whenever WP.org finally gets around to releasing the source code for the plugin repository so I can actually contribute to it.

      P.S. If you’re interested, I’m actually working on a service to provide git-svn mirrors of any plugin in the repository, which is at least a decent start to this: https://github.com/bluehost/pluginmirror

    • You may also be interested in Evan Solomon’s Scatter tool for Git to SVN deployments.

      I’m with you – I prefer Git as well.

  13. Interesting points Tom. I’m amazed most of my pain points with the repo and ideas for its improvement don’t overlap more.

    In response to your ideas I really dislike the idea of a paywall/resolved support request necessary for ratings. Reviews and ratings are far to infrequent already and putting a hurdle in front of doing so will make it worse IMHO. I think the solution here is 3 pronged. First I think all ratings should require a minimum one sentance review (forget if this already got implemented). Second there has to be a way to rate, review & report built into the WordPress dashboard (this would dramatically increase volume of reviews, rating & compatibility reports). Third the crowd needs to be sourced by empowering them to filter bad reviews out (ie. if enough people mark a review as unconstructive it’s hidden/removed). Anyway I think the answer is more reviews not fewer.

    My two bigges issues with the repo are this:
    #1 it’s too hard to contribute code to existing projects. GitHub works beautifully for this, .org fails miserably. I’m not sure how but ripping all of the developer facing functionality off of .org and into GitHub would be awesome. (Ie. kill Trac, move support to issues, allow forking/pull requests). This also addresses dead/abandoned plugins and hopefully would reduce plugin overlap which has gotten out of hand.

    #2 for users it’s way to hard to find existing answers to questions. You’re right that they don’t read, but I think a huge part of that is that they can’t effectively search. There is no obvious built in way to search a single plugins documentation or support forum. There needs to be a search box that searches all the plugins Readme tabs + it’s support forum in one click.

    Side note: I hate review systems that are oversimplified because as a reader of reviews I’m skeptical of its true meaning. Just like amazon needs to differentiate between reviewing the vendor and the product, plugin ratings need to differentiate between doing what a user wanted and the plugin doing what it said it does.

    • First, thanks for such a thoughtful response. I love back and forth when we don’t all agree but we’re not flat out calling each other trolls ;).

      But on to your points:

      I really dislike the idea of a paywall/resolved support request necessary for ratings.

      The more comments I’ve read and the more thought that I’ve given to this, the more I can get hind this. I can be viewed as a way to getting people to pay and that’s honestly not what I’m after.

      Straight up, my main issue is curtailing unconstructive, poor ratings. And I think you’ve provided some pretty good solutions for doing just that.

      Now, as far as contributions are concerned, you and I are 100% on the same page. Check out my comment to Pippin to see my two phase approach to this.

      Plugin ratings need to differentiate between doing what a user wanted and the plugin doing what it said it does.

      Yeah – I’d venture to say that at this point you’re also dancing around the idea of a developer’s reputation for delivering what s/he claims to be delivering and the quality thereof.

    • That comment about plugin overlap freaked me out. What does that mean, that you think that wordpress.org should have single plugins for single issues? It is not core, it is way for developers to put out their enhancements for free the way they see fit.

      The comments I have seen about dead plugins freak me out to. Where people want to take them over. You can just fork them and make your own. The only reason to take someone elses plugin is to steal the audience for their branch of the code.

      I can see expiring old plugins so someone else can take the name, but I still think that you have to not break the svn because sites rely on the existence of that external repo.

      If the repo becomes a thing where they start taking away developers hosting without a violation of the GPL no one should participate. That is break of the basic social contract. I have put a bunch of effort into a few plugins and I consider the downloads to be my audience. Of course you can fork the code and remove all reference to me, but somehow taking over my code base because I determined it was stable and hadn’t touch it in however long. That makes zero sense.

      • Trevor, you seem to freak out easily.

        Overlap – No, this has been well discussed. It doesn’t help users to have dozens of plugins to add a like button for example. That isn’t to say there should only be one, just that plugins ought to be novel enough to justify themselves, not get created because dev #2 wanted a tiny tweak to something and dev #1 either wouldn’t add it or couldn’t be reached, nor because Dev #2 just wanted to submit something to the repo.

        Dead plugins – The repo no longer shows plugins older than 2 years. There isn’t a good way for new devs to fork these plugins and maintain continuity with the old plugin. This applies In cases where the existing dev can’t be reached or doesn’t want relinquish control. In a dev focused universe forks would get presented inside the wp dashboard where users could switch to a new fork. Unfortunately that idea is probably totally confusing and unworkable for 99% of users.

        Taking away hosting – there are MANY reasons for .org to take away plugin hosting, see the same list of terms I referenced before:
        http://wordpress.org/extend/plugins/about/
        http://wordpress.org/extend/plugins/about/guidelines/

        Breaking social contracts – There is a big difference between GPL and copyright. People can not remove all reference to you when they fork/modify your code. Code you’ve written needs to continue to be attributed to you unless you’ve also released your copyright.

        • “Overlap – No, this has been well discussed. It doesn’t help users to have dozens of plugins to add a like button for example. That isn’t to say there should only be one, just that plugins ought to be novel enough to justify themselves, not get created because dev #2 wanted a tiny tweak to something and dev #1 either wouldn’t add it or couldn’t be reached, nor because Dev #2 just wanted to submit something to the repo.”

          Still freaks me out. I don’t understand what this means. If I code something that I think is of value, but may already have n versions on the repo. I’m still doing it in a way that I value and thing may be worth sharing. So any discussion about should or shouldn’t that enters in the equations devalues the basic desired impulse. Which is for people to share their code for free. The idea of Overlap is something akin to the ideal of canonical. That someone who is already on the repo solving a particular problem is somehow infringed on if someone else’s plugin is very close. While I can see that it might confuse users to have more than one solution, there is no linkable forking mechanism such as you mentioned. So there really is no community aspect where a dev can of his own accord participate in someone else’s code without an invite. Unless they just make their own fork, market it under a different name, and add to the Overlap. So since there is no technical reinforcement of the community concept, discussions of overlap are moot and plugins are effectively owned by the commiters with no right to comment outside of that.

          The idea that I should scour the repo to determine if someone else is already doing something before I contribute. No thanks. If I’m contributing it will be because I have made something stable that I want to share. If I’m competing with someone else so be it. I don’t have any less right to be providing my plugins as a service to the community just because they might not be novel. People don’t have to consume them if they don’t want to. So I disagree with your point about just because I want to. Until there is some rule that first movers can lock out the participation of others and wordpress.org starts just assign the like plugin to this guy and the seo plugin to that guy. I think everyone should contribute if they want and the primary reason should be their desire to join in.

        • “Breaking social contracts – There is a big difference between GPL and copyright. People can not remove all reference to you when they fork/modify your code. Code you’ve written needs to continue to be attributed to you unless you’ve also released your copyright.”

          I have never understood this as it appears completely unmanageable. I have never referred to another coder in any of my code. Not out of a desire to not attribute but because I typically read code on the internet and then implement.

          Even if I open up someone else’s code to see how they did something, or open up something in WordPress core and cut and paste a structure to work off of. Since I’m not loading the third party file and running their functions. What do I attribute? How much of someone else’s code do I have to use before I have violated copyright?

          Most code is just patterns that use php and you can find them in any number of places. Just because I happen to learn form on piece of open code does that meant that they have copyright and I’m infringing.

          Even if I did want to respect the copyright of others there is so much code that is just not novel and is really repeated over and over. Just because someone names their variables and functions a specific way. Does that arise to the level of copyright?

          It is exhausting to thing about how you would manage crediting people. Unless you are just a clear forker that is taking large code bases and clearly forking them. Again, I don’t understand how large and how novel those have to be before you are violating anything.

          Maybe someone has an example of the right way to deal with this.

  14. Why not give the developer the option to at least contest poor ratings?

    Or, tweak the rating algorithm so the stars are weighted? Instead of just a flat aggregate of all stars, have the weight of the star(s) count more or less based on the amount of times it’s been given. That way, a single one-star rating won’t bring down the whole aggregate score if the plugin also has 4 three-star ratings, 2 five-star ratings, etc.

    • Or, tweak the rating algorithm so the stars are weighted? Instead of just a flat aggregate of all stars, have the weight of the star(s) count more or less based on the amount of times it’s been given. That way, a single one-star rating won’t bring down the whole aggregate score if the plugin also has 4 three-star ratings, 2 five-star ratings, etc.

      I think this is an excellent idea. A great way to diffuse the “odd” single one-star rating given by an unjustified sour reviewer. I imagine this would be fairly trivial to implement as well – “low hanging fruit” if ever there was.

      • Weighting the stars sounds crazy to me. Users are more than capable of reading 1 star reviews and determining their relative value.

        The only two tweaks like that I could get behind are #1 convert to support ticket and #2 don’t show a cumulative rating until there are at least 5 seperate ratings.

        • But you’re assuming users are reading in the first place. As Tom has mentioned, it’s painfully obvious that a lot of people simply don’t read, or at best, glance at the information shown to them.

          I think a lot of people are going to judge a plugin’s overall value based on a glance at the number of stars shown, rather than dig into the actual ratings themselves. And if this overall “3.8 stars out of 5” is going to be one of the first things they see, then that “3.8” should be a legitimate score.

          As our community expands, we should have safeguards in place to protect the integrity of the code we release to the public. If the plugin repo is geared more toward the end-user rather than the developer (like it seems to be), then we owe it to those users to make sure the information presented–in the form of ratings and whatnot–is as realistic as possible.

          That being said, maybe we should also devise some way to encourage ratings. Maybe take one of the ideas mentioned earlier about donations; some sort of time-lapse message asking to rate/review? It may seem kind of spammy though. I bring it up because I just noticed one of my plugins has been downloaded over 11k times, yet it’s only been rated 4 times. That seems a bit skewed.

          • As a consumer of plugins, 3.8 stars doesn’t bother me. It does make me more inclined to look deeper into what the reviews might say than say a plugin with 4.5 stars. That has the follow on benefit of maybe discovering a 1 star review that is actually helpful to me. ie. 1 star — plugin doesn’t wash my car.

            I totally agree though that MORE ratings, reviews and compatibility reports is extremely important. I think the only thing that will achieve that is devising a way to rate, review and report FROM the dashboard.

            People are in their dashboard ALL the time, people only go to the repo when they want to find a new plugin, but a week, year month later to review it. Even if that plugin is causing them issues they’re probably just going to deactivate it, NOT deactivate and it and then fo to the repo to review it.

          • The time-lapse reminder to rate the plugin might not be bad in a lot of situations, however, you have to keep in mind that the plugin repo itself can’t really implement this since very few of those 11k downloaders actually have a WP.org user account (which is required to rate plugins). It wouldn’t even know where to send those reminders. Also, out of the ones that do have an account already, none are required to actually log in to download any plugins (and that’s not going to change).

            As for WP core, the most non-intrusive way to add this would require knowing the user has a WP.org account, and that the user has opted-in for reminders like this (it wouldn’t be configured to just spam people by default – doing so would actually be illegal in some countries)… so really, it’s not going to ever be any better than this last suggestion…

            The best option, and one you can actually do yourself right now is implement the reminder right in your own plugin. I’m pretty sure a bunch of plugins already do this. You know your users best, and you would know best how long to to give your users to become acquainted with your plugin, and whether they would actually mind such a reminder.

          • very few of those 11k downloaders actually have a WP.org user account (which is required to rate plugins)

            …forgot about that. Another barrier to entry for ratings…

    • That’s what I’m saying – I think I mentioned it in another comment, but I think that this would also carry even more merit if it were related to ratings being tied to support issues.

    • I agree that the solution to bad ratings is more ratings. However, it seems to me like the requirement to post a comment to leave a star rating has actually created a barrier to entry for rating a plugin, e.g. a user who likes (or dislikes) a plugin could previously just click a star value, now they actually have to justify that star value and that prevents them from doing it. I’d be fine with this if the end result was overall better ratings, but I don’t think that’s the case, especially when it comes to the 1-star “plugin doesn’t work” rating.

      I totally agree with the idea that ratings could be voted up or down by other visitors, I think that’s a decent way of dealing with the problem. Ultimately, though, ratings will be more scarce overall if people are required to post a comment to go along with it. Would both be a viable option? Less like Amazon, more like Netflix?

      • I think the requirement to leave a comment with a star rating has improved ratings overall even if it’s a barrier to some. It means when someone leaves a 1 star rating with a comment of “plugin doesn’t work”, that 1 star rating has exponentially more meaning than if it was just 1 star with no comment.

        While I suggested rating comments up/down, the more I think about it the more I think it adds to much complexity for too little gain.

        The ability for authors to convert ratings into support tickets would be WAY more powerful, IMHO.

  15. I think the only thing that will achieve that is devising a way to rate, review and report FROM the dashboard.

    I agree, rating from within the Dashboard, say, on the Plugin admin screen would be great.

  16. One problem with the plugin support forums is the aggressive anglo-centrism. Most users don’t speak English, or at least not very well. But you cannot select the main support language.

    And if there is a plugin made for users under one country’s law only, and your users ask in that country’s main language you are told to speak … English or stay away.

    This is just sad.

    • This is a really good point – in fact, I’d say it’s more overlooked than I’d like to admit.

      Case in point: I localize all of my plugins and I’ll do what I can to use Google Translate to handle issues as they come into my inbox (I’m also thankful that people who speak other languages do the same), but that’s not the same as speaking in someone’s native language.

      Shy of actually learning the language, the next best thing would be to contract someone to supply support for that question (or to translate it), I suppose.

  17. I’m thinking about added a meta box with my plugins (probably one for multiple) that shows each plugin and an (enable support) button. So when you click on that it would request permission for the plugin to notify me that it is in use. Getting around the no callback to your server without permission rule. I was thinking that I would also request usage data so I could get the setting sent back to every time they change. Also it would ask for a support payment to enable support. Then in the meta box and in the settings for each plugin there would be a question/answer box that would be enabled so that the user could send in support requests.

    I thought I would also have those support requests go automatically to admin and if I could swing it, automatically request confirmation from the blog admin via email that the support request is authorized. In that way, if a dev wants the support request to go through them first, I would get notified by not take action without confirmation. That to me might answer the idea of a plugin author hijacking client requests.

    So the disabled support box might be considered gated functionality but since its not really a feature being gated I don’t think it would be a problem.

    I’m not sure what the support would be, I suppose it would depend on the plugin. For just messages I think may between 1 and 5 dollars per request with no guarantees. Probably 1 if it’s just answering questions.

    Or maybe a simple monthly payment for unlimited support. With a separate price for each plugin.

    Comments? I don’t think that would violate the rules.

    That would be what I think the repo should implement is a paid support channel for developers where the developer can put a per request price on having support emails reach them. And then can just optionally visit the forums and support for free if they like. Then the user just is really just encouraged to support but is not required to.

    Another mechanism that we be nice would be a donation confirmation. Put together basic paypal integration when you could confirm a donation to the repo and the plugin page could reflect if you donated or not and how much. That wouldn’t change anything other than just having a single support nag screen method that is integrated. Red (no donation) and green (donated) readouts that guilt people into throw a bone. It would also be great to have an integrated donate all button that would just split an amount between the plugins.

    If they did that they could also post donations by permission on the repo so that companies could support wordpress and have their logo show up as a top donation. Almost every charity I have heard of promotes people who donate. Why doesn’t WordPress? I’m planning on doing this on my site for plugin donations. People who donate get a mention.

    They could also get in touch with the Humble Bundle people and setup a similar donation mechanism where the person donating could decide what went to the plugin dev, what went to support the repo and how much when to the developer.

    I think that they are just allergic to helping out developers because wordpress.com wants to keep devs poor and giving their stuff away for free rather than implement anything that would turn off users by asking for money. The strategy of building the WordPress.com business is based upon the free wordpress.org product getting the word out at no cost WordPress.com. So if there is any cost to WordPress.org for functionality than people might consider competing brands.

    Make no mistake, the WordPress.com people are business people first and members of the community second and only that primarily to keep the brand on top. The altruistic nature of the free software is a smoke screen. True free software advocates aren’t corporations that are using free software to dominate a market. They are projects where all the fruits of the labor belong to the community and the winners are the ones who service with the tools best. Not the owners of projects .com.

    • I’m thinking about added a meta box with my plugins (probably one for multiple) that shows each plugin and an (enable support) button. So when you click on that it would request permission for the plugin to notify me that it is in use.

      That’s not a bad idea – offering a support link within a meta box – but I think it’d have to be done in an elegant manner so not to muck up the experience of the dashboard too much, you know?

      For exmaple, what happens if the user installs multiple plugins that you’ve written. Ideally, there should only be one meta box which means your plugins would need to know which plugins are installed.

      Just food for thought.

      Also it would ask for a support payment to enable support. Then in the meta box and in the settings for each plugin there would be a question/answer box that would be enabled so that the user could send in support requests.

      This sounds more like it begins in an options pages, at this point. Plus, if you’re looking to collect usage reports then you’d need to consider something that asks for permission.

      Again, not saying this is a bad idea by any means – just covering the bases.

      That would be what I think the repo should implement is a paid support channel for developers where the developer can put a per request price on having support emails reach them. And then can just optionally visit the forums and support for free if they like. Then the user just is really just encouraged to support but is not required to.

      As much as I think developers – myself included – would like to see the repository change, I don’t think it will.

      I also don’t think the donation model works very well and I’ve got statistics – at least for me own work – to back that up. This is why I’m slowly working going back towards a premium model (I’ve discussed this in a number of different blog posts).

      At any rate, you make some good points and are obviously thinking a lot of about this – which is awesome – I dig seeing the conversation around all of this, so I appreciate the comments :).

      • “For example, what happens if the user installs multiple plugins that you’ve written. Ideally, there should only be one meta box which means your plugins would need to know which plugins are installed. ”

        Definitely one meta box, that simply lists all plugins with a status readout that is simple there to track the relationship with support from the developer. So no real functionality there. I think that the permission is then when click enable support I have to have something to allow communication. So it wouldn’t auto track.

        The meta box might also have other things. Plugin versions, usage numbers. Whatever a meta box might want for a set of plugins to make it useful.

        Really you can’t muck up the dashboard too bad because you can always turn off those boxes.

        It order to really make it good though, I think you have to promote a pro plugin that does things like enabling one click buying of plugins support. So this is still just a song and dance to be able to get as much of your marketing on the repo as possible.

        I saw where there was some plugin that was designed to broker support for third party plugins and it was removed. So every time I think about spending time on this I run up against the arbitrary nature of it and it kills my enthusiasm.

        Everyone agrees. The donation model is a lazy effort to appease developers by a team that wants their power to grow for free. The rules of the repo should be set democratically by the plugin devs who are contributing not by the few that run the repo. Sure they are providing free hosting, but free hosting without contributors is an empty harddrive. It is only the participation of people from outside that gives it its value.

  18. Hi Tom,

    Your article is really helpful, thanks for writing. I am looking forward to read more articles in future. Keep writing!!! cheers.

  19. try wpplugindirectory.org
    I’ve stumbled upon this website recently, I use this as a alternative of official repository. It’s great if you want sort plugins based on vote, rating,published,updated date. Besides that they have a list feature which I find very useful.

  20. Ah!! I completely agree with you :) I don’t get notifications for new requests either. !!
    And I have noticed another issue. Sometimes we get great reviews from users (Mostly after resolving their issues). But WordPress simply removes it from reviews list. Review count will be there but it will not be there in the review list. Does anyone know the reason?

  21. Hello

    For the reasons that you have exposed, I stopped to share my plugin developer amateur work.

    Indeed, I’m not a professional developer of WordPress but a simple user who found normal to share its own plugins with others. Having benefited from the sharing of WordPress, I shared the plugins I wrote for my own use. The attitude of the team of WordPress plugins has convinced me to no longer share my plugins because the latter think that the developer itself is also assessed through the rating, and I quote “A review is someone’s opinion having used your product. “When you interact with users, that becomes a valid part of an opinion, because your product is more than just the code, it’s the people behind it. ”

    I developed this in an article on my site (dedicated to the smoking cessation) here, in french: http://additifstabac.free.fr/index.php/wordpress-le-partage-est-mort-vive-le-commerce/

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.