Ian Dunn 10:34 pm on February 26, 2021

Would Stats Dashboards Help Your Team?

I’m curious what you all think about the idea of having a stats dashboard for each Make team. If that’d make a big impact, MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. could build an automated system to facilitate it.

Some questions (don’t feel like you have to answer each one, though):

Would a dashboard help your team make data-informed decisions, or help you focus on your top priorities?
What type of dashboard would work best for your team? Would you need aspects of multiple types?
How do we help ourselves (and future contributors) determine the right metrics?
What metrics would your team want to track? Some rough ideas:
- Documentation: Page views for HelpHub and DevHub.
- Support: Reply volume on forums.
- Theme/PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party Review: Number of theme/plugin submissions, publications, and rejections (with reasons?).
- TV: Most popular videos, categories.
- Training: Number of lesson plans published/edited.
How can we help ourselves (and future contributors) interpret the data correctly?
Would any team have a need for private stats, or could it all be open and transparent?
Where would the dashboards live? A separate page like make.w.org/{team}/stats? Or a centralized place like make.w.org/stats? Maybe in the sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. of every make.w.org/{team} page, so it can’t be missed?

Ipstenu (Mika Epstein) 7:02 pm on March 1, 2021
We have a dashboard for plugins, but it’s not very ‘pretty’ and since it doesn’t integrate with HelpScout, it’s only half functional.

In the case of plugins, due to the nature of why plugins are closed I would prefer it private for now (if public, we should omit the details on WHY a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party is closed, just to protect users from 0-day while plugins are being fixed).

For sure we would want:
- Plugins Approved
- Plugins Closed
- Plugins Rejected
- Plugins in ‘Pending’ (i.e. waiting on replies)
And extras would be hooking into HelpScout to get an idea of how many emails are being sent.

NB: We don’t track why plugins are rejected. We probably could, but generally it’s either ‘Developer broke guidelines OR developer took too long (6 months) to finish review.’
- Ian Dunn 8:41 pm on March 1, 2021
  
  Thanks! We could reuse the existing code as a jumping-off point.
  
  if public, we should omit the details on WHY a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party is closed
  
  I’m guessing the dashboard would only have high-level, aggregated stats.
  hooking into HelpScout to get an idea of how many emails are being sent.
  
  That shouldn’t be too hard. I’m guessing the Community Team would also want that.
  - Ipstenu (Mika Epstein) 12:36 am on March 2, 2021
    
    And Themes and anyone else who uses HelpScout 🙂 I have not had enough brain to parse their APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways..
Steven Stern (sterndata) 10:38 pm on March 2, 2021

I don’t see this really being useful in Support, as we don’t have metrics. Maybe that’s a discussion to have, but as we’re not really tracking anything…
- Ian Dunn 11:33 pm on March 2, 2021
  
  I’d guess that most teams aren’t currently tracking anything, so I was seeing the dashboard as a tool that would encourage folks to start. Part of the planning process would be participating teams establishing metrics that are meaningful to them.
- Andrea Middleton 4:43 pm on March 3, 2021
  
  I agree with Ian here; I’m very interested to know what Support folx might find meaningful to track! Some totally un-validated ideas that come to my mind = monthly activity in different sections of the forum, time to first response (might indicate availability of currently active volunteers), number of non-post-author replies per day/week/month/etc, number of threads closed & opened in a certain period…
  
  I don’t know if Support mods or team members might be able to use that information for anything that helps their work or the project at large, but I personally (as someone who likes knowing things) would find them interesting to know. 🙂
- Rocio Valdivia 12:38 pm on March 4, 2021
  
  I’d love to see Support Stats as well!
  One important one that we should track would be the stats of the support forums in our different rosseta sites, for example, the Support Stats in the Spanish forums, the Japanese ones, etc.
  
  For reference:
  
  Spanish support forums:
  https://es.wordpress.org/support/
  https://es.wordpress.org/support/forum/manuales-y-resolucion-de-problemas/
  …
  
  Portuguese support forums:
  https://pt.wordpress.org/support/
  https://pt.wordpress.org/support/forum/problemas-no-funcionamento/
  …
Michal Janata 8:44 am on March 3, 2021

I would definitely welcome better statistics. Who translates as much, how often.
How many plugins/templates have been translated recently.
The most active translators.

Just proper statistics. So that you can write articles about how we translate and so on.
Pingback: Community Team Meeting agenda for 2021-03-04 – Make WordPress Communities
Yui 12:14 pm on March 3, 2021

Polyglots teamPolyglots Team Polyglots Team is a group of multilingual translators who work on translating plugins, themes, documentation, and front-facing marketing copy. https://make.wordpress.org/polyglots/teams/.

We usually take those stats to consideration:

Releases: 205 (±0) locale, 76 (±0) up to date, 0 (±0) behind by minor versions, 0 (±0) behind by one major version, 49 (±0) behind more than one major version, 77 (±0) have site but never released, 3 (±0) have no site.
Translations: 205 (±0) total, 10 (-10) at 100%, 62 (+10) over 95%, 7 (±0) over 90%, 50 (±0) over 50%, 75 (±0) below 50%, 126 (±0) have a language pack generated, 1 (±0) have no project.Requests: There are 50 unresolved editor requests out of 4 063 (+6) total and 20 unresolved locale requests out of 152 (±0) total.Translators: There are 697 (+1) GTEGeneral Translation Editor General Translation Editor – One of the polyglots team leads in a geographic region https://make.wordpress.org/polyglots/teams/. Further information at https://make.wordpress.org/polyglots/handbook/glossary/#general-translation-editor., 5 113 (±0) PTE and 50 093 (+97) translation contributors.
(A wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ account could have multiple roles over different locale)Site language: 55,432% (+0,004%) of WordPress sites are running a translated WordPress site.

It will be nice to have them on dashboard,
- Ian Dunn 4:52 pm on March 3, 2021
  
  Thanks! It looks like `Releases` and `Translations` are from make/Polyglots/Teams, and `Requests` is from make/Polyglots/?resolved=unresolved.
  
  I don’t see where `Translators` and `Site Language` are coming from, though; could you share links?
- Naoko Takano 8:39 am on March 4, 2021
  
  The above summary is from one of pages from @casiepa‘s personal site, copied by a meeting host every week.
  
  I’m not 100% sure his data collection methods, but pages such as https://make.wordpress.org/polyglots/teams/?locale=af (linked from the Teams page for each locale) has the data.
  
  Site language is the data on this page (under “Locales”):
  https://wordpress.org/about/stats/
  - Pascal Casier 10:56 am on March 4, 2021
    
    @iandunn @nao Those are indeed all the links I use. The (-10) and (+97) is because I store it locally and then check the difference with last week.
    It would be great if I no longer have to run this locally and that it would go centrally!
    - Ian Dunn 3:38 pm on March 4, 2021
      
      Ah, thanks!
      
      xref https://wp-info.org/polyglots-stats/
- Yui 12:14 pm on March 17, 2021
  
  Since 100% translation is not a requirement for release now (since WordPress 5.7)
  it is now worth to track “Releases” and “Releases which have 100% translation” , just for fullness of statistics and to track the impact of the latest translation threshold changes.
Ari Stathopoulos 12:42 pm on March 3, 2021

Theme/PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party Review: Number of theme/plugin submissions, publications, and rejections (with reasons?).

IMO the “reasons” part is a must-have. Having a simple number of submissions vs success/rejection is just so we can tap ourselves on the back when numbers are high, and do a call for reviewers when things are not great. It’s OK, but nothing we can’t already do just by looking at the weekly stats.
Having the “why” would make a difference and would mean we can actually improve things for the future. Knowing that most themes/plugins fail the review for one of 3 main reasons would mean that we can address and fix these underlying issues. Knowing that this week 30% of submitted themes were accepted while last week it was 35% tells me absolutely nothing.
- Andrea Middleton 4:45 pm on March 3, 2021
  
  What weekly stats is your team already looking at, out of curiosity? Are they in TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/.?
  - Ari Stathopoulos 3:01 pm on March 8, 2021
    
    Yeah, the stats we currently look at are opened tickets on tracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/., closed tickets and approved themes. From these we get an idea of what goes on.
    What’s missing is the “why”. We get feedback & questions from theme-authors in the SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel and that helps us to mentally fill-in the gaps, but there is no way to properly have those “why” discussions documented somewhere, or a form where authors can say what went wrong.
- Ipstenu (Mika Epstein) 8:02 pm on March 8, 2021
  Most plugins fail the review due to it being 6 months without a reply.
  
  The rest are either:
  - Submitted someone else’s pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party
  - Known bad actor trying to sneak in
  - Submitting plugins we just don’t host here
  That really wouldn’t change anything for plugins, I’m afraid, and in our case would need a bit of elbow grease to be able to properly track (we don’t today) and to close en masse (right now I bulk-reject plugins at the end of every month if they’ve been 6+). Having that automated would be bril mind you 🙂
Francesca Marano 8:16 pm on March 3, 2021

+make.wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org//coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.
Erica Varlese 8:45 pm on March 3, 2021
Moving some thoughts over from a quick brainstorm in the Training channel.

For Training and the Learn WordPress Working Group, most of the stats that would be helpful fall under the learn.wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ site. With that in mind, I’m not sure if these quite fit into the proposal/idea here. Nevertheless, some ideas that would help to make decisions for Learn WordPress and track the overall health/progress towards goals:
- View stats on workshop/course videos
- Top workshops and lesson plans viewed (though we can essentially grab this from Jetpack stats now)
- Traffic flow/referrers
- For courses, the number of people enrolled and tracking completion rates
- Tracking MeetupMeetup All local/regional gatherings that are officially a part of the WordPress world but are not WordCamps are organized through https://www.meetup.com/. A meetup is typically a chance for local WordPress users to get together and share new ideas and seek help from one another. Searching for ‘WordPress’ on meetup.com will help you find options in your area./discussion group attendees
- For quizzes, tracking overall grading metrics (or whatever form of evaluation may be most applicable)
- Courtney Engle Robertson 8:55 pm on March 3, 2021
  
  Also view stats on lesson plans (site visits, downloads)
  
  Possibly tracking pieces of content in production. Some of this is tracked in TrelloTrello Project management system using the concepts of boards and cards to organize tasks in a sane way. This is what the make.wordpress.com/marketing team uses for example: https://trello.com/b/8UGHVBu8/wp-marketing. and requires human touch to assess the progress.
- Ian Dunn 4:06 pm on March 4, 2021
  
  I’m not sure if these quite fit into the proposal/idea here
  
  I think Learn stats could definitely fit! Tracking success metrics for a high-priority project is one of the main things I was envisioning.
  
  Whatever helps your team reach it’s goals seems worth discussing.
Naoko Takano 8:49 am on March 4, 2021

How do we help ourselves (and future contributors) determine the right metrics?

For polyglots, I’d like us to be able to access the stats that 1) determine the health of each locale team and 2) help find active contributors who are good candidates for GTEs of inactive locales.

From my past research, active members in translation, forums, or even events seem to become strong advocates in the community, increasing the adoption of WordPress in the locale so I’d definitely like to see the same stats as English forums collected for international forums.

We have a translation stats overview page here: https://translate.wordpress.org/stats/ but I personally would like to see make.w.org/{team}/stats for the above.
- Naoko Takano 8:25 am on April 22, 2021
  @iandunn I asked Polyglots TeamPolyglots Team Polyglots Team is a group of multilingual translators who work on translating plugins, themes, documentation, and front-facing marketing copy. https://make.wordpress.org/polyglots/teams/. for feedback on this and this is what we want as the team:
  - Number of currently active contributors (we have this data on e.g. https://make.wordpress.org/polyglots/teams/?locale=ja under “Current Translation Contributors” but still would be good to be more visible in the dashboard) and editors (maybe who is active within 6 months, instead of 1 year)
  - Showing changes over larger periods of time for active contributors/rejected & approved strings
  - Ian Dunn 3:14 pm on April 26, 2021
    
    Thanks!
Rhoslyn Prys 11:44 am on March 4, 2021

Number of downloads or sites running in locale
I used to find the number of downloads in our locale – cy – to be useful for getting people enthusiastic about contributing or using WordPress.
Could it be added to the dashboard?
At the moment we are somewhere within the 4% -> https://wordpress.org/about/stats/
🙂
Rocio Valdivia 12:45 pm on March 4, 2021

a centralized place like make.w.org/stats

+1 to a centralized place like make.w.org/stats for discoverability of the activity of other teams. If someone goes to check the Community stats, can end up checking the stats of other teams and getting familiar with what they do.

Besides that, I’d definitely add the Stats page to the sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. of every make.wp.org team 🙂
Carike 4:48 pm on March 5, 2021

@iandunn Have you considered including stats that would help with the contributor funnel for each team?
New pledges, people that made their first contribution, people that reached particular milestones, etc?
- Ian Dunn 5:50 pm on March 8, 2021
  
  I like that idea!
Marius L. J. 1:32 pm on March 8, 2021
From a support related point of view, what would hold value, and help drive future decisions (as a first step, I envision this needing lots of iterations to find the perfect fit and improve on it over time). I also second what @_dorsvenabili mentioned that we should definitely account for rosetta sites (could we do a combined view of _all_ support, and be able to filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. by individual rosetta sites or international forums, or maybe even a grouped view if we wanted?)
- Topics created
- Average amount of replies to a topic (I intentionally will not say “until `resolved`”, as many users never return to mark topics as such when a solution is reached, so this is a misleading metric, but how much back and forth is needed is valuable)
- Average time from topic creation until it received its first reply (this might be a bit harder to track?)
- Posts created
- Reviews created
  - Also what ratings are created
These would help give a feel for how support requests, and replies, flow, especially useful when planning for releases, it can then be put into systems for what kind of changes hit coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. in that period of time.

The reviews created overview may be a bit controversial, as some may misinterpret them if there’s sudden spikes, but I think it would be valuable to see how the general movement of support also represents on overall review impacts. Much like the previous mention of core changes affecting the support load, it may also impact plugins, being able to see what kind of impact this has, and make calls based on this to not unintentionally negatively impact the ecosystem if it can be avoided would be very valuable.

I’m also wondering… although it may be a bit of a longshot… for topic and post creation, could we also capture the length of the text? Being able to judge how improvements over time impact the information users provide when looking for, or providing, help would be nice. It would play a bit with the `average replies to a topic` metric to see if it could help reduce the back and forth needed?

Average time until a reply is posted will help identify areas that may need a hand covering questions, or for rosetta help identify languages where we could make a push to engage new volunteers?

Just some initial thoughts from the post, I definitely think that some data, regardless of what is possible, will be valuable here to help drive decisions going forward.
- Ian Dunn 4:20 pm on March 8, 2021
  
  Thanks! Those are good thoughts.
  
  could we do a combined view of _all_ support, and be able to filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. by individual rosetta sites or international forums, or maybe even a grouped view if we wanted?)
  
  I’m guessing it’d be best to keep it simple for v1, but we could track those individually, and make UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. improvements in v2. If we use an existing stats framework, though, it might already provide some of that functionality.
  
  I’ve also been thinking it might be good for some of the top-level stats to link to a “detail” page that shows more granular data. That might fit here.
- Ian Dunn 4:43 pm on March 8, 2021
  
  (I intentionally will not say “until `resolved`”, as many users never return to mark topics as such when a solution is reached, so this is a misleading metric
  
  It seems like that, and the % of resolved posts, would be very valuable if we can do it reliably.
  
  I wonder if we could come up with an average rate for “resolved posts marked as resolved”? If we pick 100 topics at random, and manually check if they’re marked as resolved, and if they’re actually resolved, then we might find that users mark a resolved topic as resolved around 50% of the time (or whatever).
  
  Then we could factor that into the interpretation. e.g., we could consider 45% resolved to be “excellent”, 40% “healthy”, 35% “need more contributors”, etc.
  
  We could even display 45% as 90% in the UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing., with a footnote to mention that the actual % resolved is 45, but 50 was added to factor in unmarked tickets.
Pingback: Notes: Global Marketing Meeting 3 March 2021 – Make WordPress.org Marketing
Carolina Nymark 12:00 pm on March 22, 2021

The themes team continued the discussing during a meeting.
https://make.wordpress.org/themes/2021/03/12/themes-team-meeting-notes-march-09-2021/

The team agreed that for theme reviews, it would be beneficial to have statistics about why tickets are closed as not approved. This would help the team learn where to focus their efforts and improve documentation.

-There is no benefit to the team if the statistics are only the numbers of opened or closed theme tickets, since this information is already available on TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/..

-As long as any information about suspensions or delisting is anonymized, the dashboard can be public.

There are many things that could be tracked for the theme directory, that could help highlight room for improvements:

Number of theme previews
Keywords used in theme search
Usage of Tags in the theme filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output.

WordPress.org

Share this: