Discussion on Replacing Plugin Active Install Growth Data Continues Behind Closed Doors – WP Tavern

[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

Continue reading

A Discussion With Gutenberg Project Lead Matías Ventura on the Barrier to Entry – WP Tavern

[ad_1] Last week, I published an opinion piece on the barrier to entry in the modern WordPress era. The article followed a tweet and post by Chris Wiegman that stated the current learning curve was extremely high, regardless of past experience. Members of the community responded with a flurry of articles, podcasts, and videos. Because modern WordPress is primarily centered on Gutenberg, I reached out to the project’s lead, Matías Ventura. The goal was to bring some balance to the discussion. Unfortunately, he could not get back to me until a few days after the story was published. However, given his unique insight and perspective on the project, his views should be shared. In our discussion, we covered the topic of the barrier to entry from multiple viewpoints. Depending on where a specific developer, designer, or user steps onto the ramp, each will have a different experience. Why Are We Having the Same Discussions? The block editor shipped with WordPress 5.0 in December 2018. We are closing in on three years, but it often feels like we are having the same discussions. One has to wonder why we have not yet moved beyond that point. “I think this is a case of the size of the WordPress community, its diversity of perspectives, and the fact that we do still have a lot of work to do to continue to make things accessible,” said Ventura. “I’ve seen people that start with no prior WP knowledge get flying super quickly.” He recounted one story of a popular block library that launched last year. The creators were designers but did not recognize themselves as developers. However, the APIs allowed them to build an entire plugin that would not have been possible with their previous skillset. “To me, this was a triumph of the block APIs that are available for builders,” said Ventura. “But this is just one person’s perspective. It doesn’t invalidate PHP developers expressing frustration at the complexities of modern front-end tools.” Theme Creation and New Onramps On the theme creation front, we were in agreement. There are new ways (and more on the way) for non-developers to ease into visually building various parts of a website without needing the entire weight of theme development knowledge. Ventura began his WordPress journey with theme development after first being exposed to Flash in the early 2000s. He recalled downloading a bunch of PHP files and thought he could execute by opening them. It is safe to say that he has learned a lot since then. “Being able to edit pieces of a theme is a crucial aspect of democratizing access to code,” he said. “I think we are going to be seeing a lot of people get started by diving into how templates work. Or by playing with the Query block, which used to be a hidden piece unless you knew a bit of PHP already.” He mentioned that, in some ways, this aspect of the block editor allowed solo creators or small teams to build unique projects, pointing to Aino as an example. “I’m seeing a ton of designers for whom contributing to WordPress was difficult or a gated experience,” he said. “There’s a lot of developer entitlement when we say things used to be easy. They were not easy for a large chunk of the population that might have been excellent contributors if there were more avenues to contribute.” Patterns may be the first official stepping stone, one avenue among many that WordPress could facilitate in the future. Ventura envisions a possible .ORG-hosted visual theme builder that would allow users to create and publish without ever touching code. We are likely years from seeing such a project come to fruition, but lofty goals can lead to innovative ideas that we have yet to think of. Building Block Plugins Block plugins are a different beast than themes. The barrier is undoubtedly higher, but how big is this hurdle for traditional WordPress developers? “Going from contributing a pattern to building a block is a big leap right now,” said Ventura. “While there are folks that can learn it quickly, it’s still a big barrier for people. I think there are several layers to this: documentation could be an order of magnitude better in both organization and presentation. I hope we can do a lot more there.” He is also curious about tools for building blocks, such as a blend of BlockBook and CodePen. He mulled over the possibility of blocks used for creating other blocks, a scenario in which developers might only need to write HTML with the tool interpreting features like Rich Text fields. At the very least, he believes we are barely scratching the surface of what the block-building experience could be. “The biggest challenge is that there’s a tendency in PHP trained folks to neglect a bit the implications on the UX if it means the developer experience is simpler,” he said. “I think this is most visible in the shortcode/forms approach to UX as opposed to direct manipulation, which is hard to codify from a PHP set of APIs.” WordPress/Gutenberg Contribution and the Bus Factor Outside of building themes or plugins, the third and arguably the highest level of participating in the WordPress development ecosystem is direct contributions to the block system. Is contributing to core harder today than it was just a few years ago? “I think this is a good point, but I think it partially misses that contributing to WP internals like WP_Query was also very difficult,” he said. “We just got used to it. We have received more contributions to Gutenberg from people than what I have seen in Trac in my years there.” Ventura did admit that GitHub could be a factor in the amount of contribution, which many developers tend to favor over Trac. While building an editor is a difficult task and requires certain levels of expertise, other parts of the system, such as the component library or smaller packages, might offer

Continue reading