[wp-meta] [Making WordPress.org] #1692: Plugin search quality improvements
Making WordPress.org
noreply at wordpress.org
Fri Dec 2 02:53:27 UTC 2016
#1692: Plugin search quality improvements
-------------------------------------------------+-------------------------
Reporter: tellyworth | Owner: tellyworth
Type: enhancement | Status: assigned
Priority: normal | Milestone: Plugin
Component: Plugin Directory | Directory v3.0
Keywords: dev-feedback needs-docs 2nd-opinion | Resolution:
needs-testing |
-------------------------------------------------+-------------------------
Comment (by gibrown):
@nerrad thanks for testing and giving feedback. That's really helpful.
> "event" search term
Ya, thanks for pointing this one out. Similar to "backup" this is tricky
because it is a common word. We've played with weights a lot in an ad hoc
manner already, so I get worried that more ad hoc tuning will just break
something else. I'm planning to work on testing some large samples of
search terms as mentioned a bit in this
[[https://make.wordpress.org/meta/2016/08/30/initial-analysis-of-plugin-
search-logs/|post]]. This may end up happening after the new search
launches because there seems to be good agreement that the new search is
still much better.
> high number of resolved support threads - Is this a good thing to use
Right now we are only using the count of resolved threads, and I agree
with some of your points. The new index we switched to earlier this week
also includes a percent resolved field which I'm going to experiment with
adding to the query. In general, I think we should include this signal in
search for two reasons:
1. It is a pretty good signal that the plugin author cares about
supporting users. If the plugin doesn't need much support it is likely
that the other plugins "competing" on a particular search term also don't
need much support.
2. To the extent plugin author's want to improve their search rankings,
let's use signals that encourage them to improve the user experience.
Other signals in the index along these lines (not yet deployed):
- total active installs for the contributors to a plugin: encourage more
plugins; for authors of popular plugins, rank them higher (under the
assumption they are probably also well written)
- number of months during which the plugin was updated : encourage
longevity, and regular updates
- percentage of one star ratings responded to: encourage taking feedback
seriously, addressing problems
- number of translations: wordpress is global, plugins should not just be
in English, encourage translations
Also, unlike active installs, these are things that are more under the
plugin authors control. I think this also tries to address @lukecavanagh's
concerns about new plugins and active installs. By adding more signals, we
should be able to provide other opportunities for new plugins to rank
better.
That said, I think active installs is a very very good signal. A 100,000
says that there are at least tens of thousands of individual users who
have both installed the plugin and for whom it is working. Given the 100k
search queries a day, a very small percentage are developers, and so IMO
we should not be suggesting brand new plugins that have no history to
them. In cases where we know something about the plugin author we could
try to do some boosting.
WP has a very large and successful ecosystem. It is one of our strengths.
We should help users take advantage of it. I'm reminded of the yearly
feedback in the WP user survey where "plugins" are highlighted as both the
good part of WP and also the most frustrating (see
https://ma.tt/2014/10/sotw-2014/ slide 22). I'd say the current state of
plugin search is a big part of why plugins are so frustrating to users.
They search for something, it's not clear what would be a good choice, and
then what they choose is not actually well supported and breaks six months
later.
Anyway... that's my reasoning for some of the ideas I'm pursuing... these
are important things to discuss, so thanks for bringing them up.
--
Ticket URL: <https://meta.trac.wordpress.org/ticket/1692#comment:91>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org
More information about the wp-meta
mailing list