Back in October, we told you about the new compatibility box that was added to the plugin pages within the repository. However, we’ve learned that this feature has one major drawback which is the crux behind this idea proposed by shinephp.
I propose to add the field e.g. ‘Problem description’ required for input if visitor click ‘Broken’ button in the Compatibility widget.
I’ve talked with a number of plugin developers and they have all said the same thing. The compatibility box is useless if feedback can not be tied to the rating. Sure, a support topic can be opened for the plugin but there is nothing tying that forum post to the broken rating. Mark Jaquith weighed in with an even better idea.
They should get a chance (or a mandate) to provide feedback, and that feedback should open a new support thread.
However, first, plugin authors need to be able to resolve support threads about their plugin. Otherwise, they’re going to have a pile of duplicate threads.
I’m no plugin author, but I’d like to know from those who are what tools or processes need to be in place in order for you to continue using the repository versus your own setup. Obviously with your own setup, you can do whatever is necessary surrounding your plugin. The repository has its limits, especially when it comes to supporting plugins through the WordPress.org support forum that I hope Mark’s idea can address in the future.
So as a plugin author, what is your wish list for the plugin repository to make things easier on you?
It would be nice to have statistics about the WordPress version the plugin users run a plugin with. Would be a nice indicator when it’s about time to drop plugin compatibility and support for a certain WordPress version.
I do have a number of plugins running in WP 2.(5|6|7) – 2.9, but obviously the code base cannot be all up-to-date in order to support WP 2.(5|6|7). If I had a few statistics that only about 2% of the plugin’s user base still uses WP 2.(5|6|7), I’d drop support for 2.(5|6|7) and update the code base which results in a more secure and clean plugin in the end.
The addon repository at addons.mozilla.org provides these kinds of information for addon authors and I find them pretty useful.
Needless to say that this would require some changes in the WP core to provide the data, but I can dream, can’t I? :p
I’m just begining as a plugin developer, in the next days I’ll publish my first public plugin.
I plan to use the repository just for hosting the files and search purposes, I see this compatibility feature as a user-to-user contact, in no way a user-to-dev.
Tutorials and complete explanation of my plugins will be done in my site, and support will also be done in comments. Visits and comments is the least I can receive from ppl that is freely using something I took my time to develop 😛
Complementing, sorry for submiting early.
I’ve already seen 2 developers complaining about the compatibility feature, that the “breaking” can be either user fault or another plugin, and a feeling that user doesn’t know enough to blame the plugin, that it can even be WordPress that is bugged.
I believe they are not liking to see their plugin marked as broken, even more when who marks it so says nothing about why it was marked.
Well, there are plugin developers that don’t even bother to offer a working plugin to plubic (GPL itself adds to the licence tha the software is distributed with no waranty!). When they do, users should at least say what’s wrong and try to help fix.
If they don’t contact the developer, there’s little he can do. Any feedback feature added to compatibility box could be left blank or just added “doesn’t work”, with no real explanation.
As long as authors offer a way to be contacted, it’s users responsibility to contact them in the way they feel more confortable. If users don’t and plugin keeps broken, well, for the developer it’s working fine… 😛
I think it would be nice to have a system where everyone who want to submit a bugfix or a feature could do that, by adding it somewhere and then the plugin author accepts or rejects the bugfix / feature.
It needs to be simple to add code, else people don’t put the effort to fix the problem.
Plugin authors might not be there to help out forever.
I agree on that. This is something like track.
But while plugins are maintained by only 1 person or a small group, they can and should be allowed to choose how their users contact them. If plugin is distributed without charge, their convenience is top priority, and if it’s commercial they must keep their business running.
IMHO, having a post with plugin info and comment that supports code to be submitted is enough even for mid-popular plugins, more than that call your users and create a small group to admin and moderate a forum, and if needed have his own trac.
Now, if we had community plugins, that people could contribute and have not owners and ppl responsible for them, then we could think of wordpress.org or some similar site having a maintaining system.
I wish there was the ability to rate a plugin for compatibility from within wordpress itself. On the plugins page, there could just be, “It works”, “Not quite working perfectly” and “Not working / broken” buttons for each plugin. A user could just click those buttons and wordpress would automatically send the wp-version, plugin working-state and maybe a comment or description of the problem (even a thank you or two) to the plugin repository so the plugin authors can get more feedback.
I admit I rarely ever go to the repository.
Statistics
* From mm/dd/yy to mm/dd/yy (time span between 1 or 2 month)
– x blogs using your plugin.
– WP versions/Plugin versions counters
– By Countries counters
* Bug report form and dedicated forum with email alert to the plugin dev.
What I’m missing most as a plugin developer at the moment is proper issue management like e.g. trac (as used by wordpress core: http://core.trac.wordpress.org/report/3) or something like drupal (example: http://drupal.org/project/issu.....gories=All).
Good bug and feature management, which is integrated which changesets (subversion) and the plugin database, would make my life as a developer much easier, as it would provide
– a clear, central organisation of issues related to the plugin
– an easy way for the developer to respond to tickets and tracking the state of issues
– a defined way for anyone to upload patches
Maybe the plugin trac could be changed so that plugins can use the issue-tracking part of trac… What might also work is if the support forum posts would have a few additional (optional) fields (like the issue type, state, version etc.) – which can be changed by the plugin developer.
What I miss the most is the ability to show how many users are actively using my plugin. There could be lots of users having my plugin installed but deactivated.
I have been happy with my (so far) complete “It works” rating for Calendar, but if and when I start getting votes that say it doesn’t work, it would be nice to have a way of finding out what the issue was for those users, helping them out and turning that “Doesn’t work” rating back into a “It works”.
I support my plugin through my own forums though so tying the issue raised in the repository back to a place I regularly check for posted problems might be a challenge. I do occasionally check the support forums feed but lack of e-mail notification means the intervals between my checks are somewhat arbitrary,
I like the compatibility box. It is reassuring to see that real users say that my plugin is 100% compatible, despite the “better compatibility plugin” results.
My only suggestion to improve it would be to receive a simple email alert containing optional text fields for “error message text” and “user email” when a user checks “broken”.
I would encourage plugins authors to install the wordpress advanced ticket system plugin on their blog. This would allow them to take advantage of a simple ticket system solution directly plugged on their blog.