[ad_1]
Earlier this month WordPress.org meta contributors removed the active install growth chart from plugins, sending plugin developers who relied on this data into a state of dismay and outrage. The commit cited “insufficient data obfuscation” but there was no clear communication about when and where this decision had been made. Developers demanded more transparency around the charts’ removal but received no clear answers.
Multiple opportunities to communicate the details behind the decision were deliberately forgone, as speculation mounted. Several contributors not directly involved in the conversations prematurely insisted it was removed due to a security or privacy concern, but Samuel Otto Wood has unequivocally confirmed that it was neither of these things.
In a recent appearance on the WPwatercooler podcast, Wood elaborated on the decision, which he says was made in May through private channels via Slack DMs in a discussion initiated by Matt Mullenweg.
“The reason is really quite simple,” Wood said. “It was removed because by and large, nobody was using them. Nobody was using the chart itself. By and large, the chart was not useful to the majority, and it didn’t really fit the purpose we had for it, that we had in mind when we implemented it.”
Wood said the active growth chart was intended to just show growth or decline of a plugin on a weekly basis, but the data wasn’t working as intended:
People wanted that feedback on whether plugin’s growing, whether it’s shrinking, et cetera. And that’s valuable information for developers to have, it’s valuable information users to know. But it really wasn’t working as that.
The data that it provided was a percentage based data, and it was a very weak percentage based data. So by and large, the majority of use of that data was people scraping the data and using it to work backwards to the exact quote, exact numbers
That was entirely the problem was that people were largely using it to get those numbers. Now, that’s not itself bad, but a, the reverse math didn’t work. It was wrong for a number of reasons, mainly because we were doing such a way obfuscating the data in such a way that it made that number wrong.
Second, Actually, it’s kind of funny. It actually always gave numbers a bit too high, so it was giving people the wrong impression. Third, it really, people trusted it as an active number, as a number of active cells to the point where, to the point where they, they relied on it to make decisions and things like that. It was not a good idea.
Although Otto was not involved in working on the project at the time, he was privy to the discussion and relayed some of the details:
I read through all that discussion and we worked, they worked on it for a long, Scott and several people tried various things before removing it. They adjusted the values, they adjusted numbers. They, they went through a ridiculous amount of iteration and in the end, none of it worked. People were still using it even though it was giving them basically garbage. So finally removing it was the only thing to do. We did have a plan for replacing it. We just didn’t have a plan for replacing it immediately. Nevertheless, giving them active install count numbers that are wrong is more harmful, we felt, to both users and developers interests than simply not giving them at all. So that’s why it was removed.
The concern podcast host Sé Reed and guest Matt Cromwell highlighted was that the decision was communicated in such a way that it suggested it was security related. Since it was not a sensitive security or privacy issue, Reed asked why was it handled in a private chat instead of the meta channel when the decision had such a profound impact on developers being able to track the trajectory of their plugins.
Since the inaccuracy of the charts was well-known to those more intimately acquainted with the problem, Wood said its removal was “not quite the big deal” that everyone else ended up perceiving it to be. They did not anticipate the firestorm the charts’ removal would create in the trac ticket where developers were pleading to have them restored.
“The physical visual chart itself is not so instrumental to the way I operate things,” GiveWP founder Matt Cromwell said. “But it’s the act of removing it without any conversation whatsoever.
“And what does that mean for the long run of data about plugins on.org and the viability of their, of us, continuing to have them? That’s the real question. It’s an indicator of an underlying problem that isn’t getting better.”
This incident has sparked discussions about what kind of partnership plugin developers should expect from WordPress.org, and whether it’s time they looked for support from one another instead of the platform, as Eric Karkovack suggested on The WP Minute. In light of plugin developers losing more valuable data that hasn’t been replaced, Alex Denning, managing director of Ellipsis, a digital marketing agency, makes the case that WordPress.org is ineffective for plugin distribution in 2022. He contends that new WordPress plugins are not passing the 100k, 500k , or 1m+ install thresholds and the directory isn’t giving plugins organic reach.
The focus of the ticket has changed from calling on WordPress.org to bring back the active growth charts to be more about brainstorming helpful plugin stats and insights that plugin developers would like to see. It is still receiving angry and frustrated comments from developers who believe the data should belong to the community.
“I cannot emphasize enough that conversations about what to replace the active growth chart with should be happening in a public Slack channel or on a Trac ticket,” Equalize Digital CEO Amber Hinds said. “This data should belong to the community and the community should be able to participate in deciding how (or not) to display it.”
The reasons that purportedly necessitate obfuscation have not been clearly explained, but many participants in the discussion have urged WordPress.org to simply publish the raw data so it can be accessed and processed independently of the platform. @Starbuck suggests the community would then be able to create sites that render the data in meaningful and interesting ways.
WordPress developers want far more data than was previously available. Hinds requested an assortment of data points that may or may not be possible:
Things that tell us if our readme and other ranking factors are on track:
- Number of searches (or impressions) for target keywords
- Average ranking for target keywords for timeframe (month)
- Conversion rates from impression to install for target keywords
Things that tell us if we may have a problem with our plugin:
- Number of deactivations per timeframe (month, preferably week)
- Number of deletions per timeframe (month, preferably week)
- Average time from activation to deactivation or deletion
Things for better testing of releases:
- Top 20 plugins also active
- Top 20 themes also active
- PHP versions (percentage)
- WordPress versions (percentage)
Atarim CEO Vito Peleg suggested some other tools for monitoring growth/decline, to which Matt Mullenweg responded that some of the ideas were “very doable:”
- Time to churn (to deactivate) signals good/bad onboarding, UI/UX
- Repeat installs – how many users (anonymized) install on multiple sites for community opp & advocacy
- Time to result: dev can choose 1 single hook to trigger as “result” and the calculation checks how long from install to get there. By changing the placement of the hook devs can optimize entire flows.
- Inner page tracker: which/how many inner plugin pages users visit
- PHP ver distribution, general country-based installs, active install to review ratio
Wood confirmed that the active install growth charts are not coming back in their previous form and that the endpoint people were scraping before will remain disabled. He said those involved in the private discussion are monitoring the Trac ticket for feedback.
“What’s going to happen is, that the active install count instead of being rounded to the nearest digit is going to be changed,” Wood said. “I don’t know the exact break points cutoffs, but as an example show individual up to 50, then round to nearest 10 until thousand and nearest hundred until 10,000, for example. So that we are making the active install count much more fine grained than it has been. So in that sense, yes, we’re giving you the data. It’s not going to be exact numbers, but it’s going be much better than it was before. We’re still working on doing that.”
[ad_2]
Source link