Tag Archives: Process

[ad_1] WordPress is a massive open source tool that relies on thousands of volunteer contributors to create and test updates before they go live. Q: What are the biggest issues you face in testing WordPress releases? Anne: The biggest issues probably come down to… I always want people to test earlier than they do. We have a beta period and then a release candidate period before the final release. The beta period is usually three or four weeks before release. People don’t start paying attention until the beta period hits, which makes sense because they can get their hands on a test version, like 6.6 beta one, and there’s a process to it that makes it easier. But I am all about trying to get people to test earlier. Whenever I’m involved in releases, particularly as a test lead, you’ll see me trying to share posts ahead of time with early opportunities to test the next version of WordPress. I just want that feedback as soon as possible because there’s a rush once we get to the beta period, and there’s stuff that we need to find earlier. So, I would definitely like to get people to test as soon as possible. There’s a new GitHub group you can join called the outreach group. Anyone can join, and it’s basically for people who are interested in giving feedback on the progress, like pull requests and issues. That’s one of the things that we’re trying to get more of: your feedback. But that’s definitely a huge challenge. Also, WordPress runs 43% of the internet. How the heck do you figure out how to cover every use case, every configuration, every environment? That’s where things like getting involved with hosts is really helpful, getting them to test things, and getting agencies to test early, getting people to manually test different configurations. We really are trying to cover the widest spread possible. And that doesn’t even begin to cover plugins and themes and all that stuff. So it’s a huge task, figuring out how to get the right spread of testing. Because if you have 1,000 people test the same kind of environment, that’s actually not as helpful as getting 1,000 people that test 1,000 different environments. So that’s something I’m always thinking about. I’m always afraid we’re only getting a certain kind of testing done. So that keeps me up at night. Q: How can developers get involved in the testing process and what are the benefits of getting involved? Anne: Testing is a great way to get familiar with what’s coming in the next release. I think it’s the best way, honestly. You see where things break, you see limitations, you see what’s new. You can advocate for stuff by opening issues and saying, “I don’t like how this works,” or “this doesn’t work.” We had a case of that with this release [6.6], where some theme authors had feedback about a feature. They didn’t want something to be done automatically, and the feature was changed. Now we’re going back and forth about whether to do an extra beta cycle or not because of this fix, which is awesome. So, I would say: know that your feedback is valuable. However, when you’re in the release cycle, we can’t fix everything, we can’t change everything. If you open a request and you’re really passionate about it and want to see something enhanced, it’s not going to happen during the beta period. There’s a rhythm and a cycle. Things get stricter and stricter as the cycle goes on because we need the releases to be as reliable as possible. In terms of what folks can do, there’s a whole spread. You can use the Gutenberg plugin, which feeds a lot of enhancements into a release, on a development site and test it against your plugins or themes. There’s also a beta tester plugin, which I find a bit more manageable and a bit safer, as you can choose how risky you want to be with what you’re testing. I also want to shout out WordPress Playground as a really easy way to spin up test sites, test your plugins against stuff, and throw them away later. That is a huge tool for developers to try things out. There’s an outreach channel in the Make WordPress Slack if you want to passively consume information and not risk testing on your sites. That is a great spot to hang out in, and it also connects to that outreach handle and GitHub that I mentioned. Dianna: So get involved early in the testing process if you want to see something specific done. Q: How does the WordPress team decide what fixes and updates to work on for each new version of WordPress? Anne: It’s a combination of things. There are leadership priorities. For instance, Matt Mullenweg might come up with something that we want to do. The data liberation project, for example, doesn’t necessarily come into WordPress, but some of the stuff around portability within WordPress might come up in future releases. There’s community feedback. For example, when the last release went out, a feature was included, and there were a lot of requests for an enhancement to be included in the next release. That tends to be prioritized. The same goes for bug fixes. If there’s something hugely breaking, we’ll loop back and fix it. Oftentimes, that might happen in a minor release rather than a major release. So rather than a 6.6, maybe a 6.6.1. Then there are planned projects from contributor teams. For example, the performance team always has stuff related to the release that they’re looking at and trying to ship, as well as just monitoring the different features that are coming. There’s a core team that includes different focuses. For example, 6.6 has a feature called “robot rollback” for auto-updates, which is great for plugins. So if plugins auto-update and something doesn’t work, it will now roll back and not