[wp-meta] [Making WordPress.org] #6511: Provide helpful plugin stats and insights

[Making WordPress.org]

#6511: Provide helpful plugin stats and insights
------------------------------+---------------------
 Reporter:  markzahra         |       Owner:  (none)
     Type:  enhancement       |      Status:  new
 Priority:  high              |   Milestone:
Component:  Plugin Directory  |  Resolution:
 Keywords:                    |
------------------------------+---------------------

Comment (by Starbuck):

 The concepts of data gathering and data reporting should be separated.
 wp.org provided an "evaluation" of the data it gathers in the form of
 **statistics**, and has since been faced with challenges related to how
 those specific statistics are used, how the statistics were removed, and
 how the statistics might be / should be replaced. I suggest a more open
 approach - just publish the data, not an evaluation of the data, and let
 the industry render it in whatever ways we find to be most helpful.

 I think all of the problems discussed here stem from wp.org taking a
 "cathedral" approach to presenting data in a "one size fits all" manner.
 In hindsight, that fundamentally doesn't make a lot of sense given the
 diversity of this "bazaar" of people with so many different wants and
 needs. We have plugin providers and consumers. Automattic needs to
 understand the ecosystem. Third-party reviewers might want their own
 unfettered interpretation of the raw data for critique of the industry.

 I suggest that "raw" data should be post to an external server/repo where
 it can be downloaded and processed completely independently of wp.org.
 Data can be pushed daily, or on a similarly tight schedule. Different
 kinds of data can be published on different schedules to distribute the
 load. The community can create mirror sites to reduce the burden on
 wp.org. Authenticity of data sources can be established as it is elsewhere
 with hashes. The schema for the data can be versioned. Other details about
 compression and file types need to be worked out.

 The community will create sites that render the data in meaningful and
 alluring ways. These sites will gain and lose their own reputation for
 accuracy, credibility, utility, UX, and other factors. This is how plugins
 and themes rise and fall - the model can be applied to the metadata about
 plugins and themes as well.

 About "raw":
 - There will be concerns about confidentiality of IP addresses. Initially
 just the class C "/24" address should avoid most legitimate controversy.
 - Data volume and frequency of downloads will be a concern. Servers that
 offers downloads can use a login system that throttles based on number of
 complete downloads per day and other factors.
 - Data might be summarized by ip+site+plugin+hour, where hour=0-24 and
 multiple plugin downloads within a window of 1 hour are only represented
 with a single record. This detail can be better designed by those familiar
 with the data, and can be refined with more experience in upcoming
 versions.

 In summary, for many reasons I think this renamed ticket "Provide helpful
 plugin stats and insights" is asking for the wrong solution. Just give us
 the facts and let us derive our own insight from that data. I'm sure we'll
 see more and better charts and tooling that allow us to understand and act
 on the facts more effectively. This is exactly the reason why WordPress
 itself is extensible, allowing people to use their own creativity to add
 value to the platform outside of the Core.

-- 
Ticket URL: <https://meta.trac.wordpress.org/ticket/6511#comment:108>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org