 Hello, everyone, and welcome to the WordPress Briefing, the podcast where you can catch quick explanations of some of the ideas behind the WordPress open source project and the community around it, as well as get a small list of big things coming up in the next two weeks. I'm your host, Josepha Hayden-Champosi. Here we go. So I have with us today on the WordPress Briefing a couple of special guests. I have Brian Alexander as well as Ann McCarthy. I'm going to ask you both to tell us a little bit about yourselves if you can tell us what you do with the WordPress project, maybe how long you've been with WordPress. If there's any particular teams that you contribute to, that would be great. Brian, why don't you get us started? Hi, I'm Brian. I work on the WordPress project as a full-time contributor sponsored by Automatic. And I am one of the test team reps. So I help promote testing across the project, and that's not just in core, but it could be for themes, performance, feature plugins, what have you. So try to make that stuff move forward and wrangle as many people as we can to get on board and help. Excellent. All right. And Ann, what about you? I spearhead the full-citing outreach program. I am a sponsor contributor for Automatic as well. And so I contribute across a couple different teams depending upon what the outreach program needs as well as various release squads have been a part of. So for 6.1 coming up, I'm one of the core editor triage leads. Brian is also on the squad as the co-test lead, which is very exciting. So it's fun to work with him and be on the podcast. And I've been around WordPress projects since about 2011. But this is the last couple years is the first time I've really been able to be sponsored by Automatic and be a part of really giving back to the community that's given me so much. Amazing. All right. For folks who've been listening to the WP briefing for a while, you know that I've been saying for like a full year that I think that testing is one of the best onboarding opportunities we have. And then also I really like to bring in our co-creators of WordPress through that testing program because we don't know whether we're right or not unless people tell us that we're right or not. And we would like to hear so much from the users who, you know, use it and don't necessarily have an opportunity that privilege to kind of build on it or build the CMS itself. So I just have a few questions since I've got a couple of our strong testing wranglers here. The first thing I have is what are you doing or do you have any advice for getting people outside of our active contributor base and the community to participate in testing? Yeah, I can kick this off just thinking about the full setting outreach program model. So just for context, there's various calls for testing in different formats. So everything from really procedural where you're following exact steps to follow. It's a very open-ended calls for testing as well as related usability testing. And one of the things that comes to mind immediately just for getting different contributors is to have very specific, fun, engaging, relevant tests that can draw people in. So if you have a call for testing that really speaks to someone they might be more willing to participate as well as just different formats. So someone may not want to, you know, follow 30 steps, but they might want to follow something more open-ended. They might want to answer a survey rather than opening a GitHub link. And so I think a lot of facilitation with the outreach program has served us really well to bring in different folks as well as explicitly reaching out. So I've done a number of talks in different WordPress related spaces and non-wordpress spaces to try to tell people about what we're up to and really go meet them where they are. So I think that's ultimately especially with COVID and the pandemic. There was a really unique opportunity to do that and to, you know, join the random online meetup that was happening and talk about the program and talk about ways that people could get involved in feeling heard. And the last thing I'll mention is translations. The program that calls for testing that I write are written in English, but I'm very fortunate to have people who translate those. And so that's a huge way that I cannot contribute that other people have. And so I really want to highlight that call that out because it's been hugely impactful to have these calls for testing in a way that people can be more readily access. Yeah, absolutely. Yeah, I was going to add in, in addition to the calls for testing that are, as Ann said, structured such to isolate so that someone can just kind of go through a list of steps to do rather than just being exposed to track or get hub and have kind of snow blindness with with everything that's happening. We also have a week in test series of posts that goes out about every week. And what we try to do with that series is to curate a list of posts that might be a good starting point. So we try to find one that in each type of testing example, something that would a more novice contributor might be able to start with things for more intermediate and then also advanced ones that for testers who may need to have development environment and the ability to make some pretty deep or type of customizations to their WordPress project in order to test a patch or reproduce a particular issue that might be happening. So that's a good springboard for someone to come in where there's just a small thing that they can kind of look at and then dive into the larger process. Absolutely. And that's very smart. It's hard to figure out how to get started in WordPress at all, let alone like as a contributing by testing things sort of area like that's that feels new to WordPress even though the team has been around for a long time and so I think that's excellent. Brian, you mentioned in your note about who you are and what you're doing that you're helping with testing not only in the test section in the test team but then also across the project. So I have a follow up question for you. What can developers do to create better tests for their software? There are sections within the core handbook that kind of go into detail about the types of tests that should accompany individual contributions. A lot of those require kind of an extra step and some developers maybe don't have as much experience there so hopefully the core handbook can provide a little bit of that guidance. We also have a lot of contributors who are interested in things such as unit testing, e2e testing which is end to end testing, testing in JavaScript or in PHP. So there's a wide variety of the types of tests that you can actually contribute to and I would say maybe about 50% of the tickets that I've triaged personally. The contributor who brought in the patch was not able to or was not familiar with providing unit tests. So that is a very good opportunity for someone to come in who maybe is not as well versed in the depth of what the patch was involved with. But by contributing a user test, they get an opportunity to look very focused at a particular piece of code, what was modified and then create unit tests based on that. And then once that unit test has been submitted and starting to be reviewed, other reviewers, core contributors or core committers I would say they'll start looking at that. And if there are additional details that should be there expanding the tests or little modifications, then that also is feedback to that test contributor so that the next time they come in, they're more prepared for it. They're learning more about core and eventually maybe they'll also become a core contributor. We will include links to these handbook pages and documentation in the show notes. If you're listening to the podcast on your favorite podcasting platform pocket casts or it's somewhere else. I don't know where people listen to podcasts, but if you're listening to it somewhere that's not on the website, you can come get on wordpress.org slash news. Okay, the next question that I have and I think this is for both of you. Brian, it sounds like you partially answered it, but I bet there are more answers from Anne as well. What advice do you have for those submitting bug reports? I'll try men to start and then Brian I'd love to hear your unique take because I've also I think you do an excellent job whenever I've engaged with you in various places of providing really good replication steps. And so I love that and I want to offer things specific to WordPress itself and saying that notice that's more cultural rather than necessarily like steps to follow. And one of the things I've noticed that I think has started to come up partially with COVID is people, you know, you start talking at word camps or at a meetup and a bug comes up and you find someone who knows where to put it. And that kind of connection has been frayed in the last couple years. And so one of the things I feel like I've been saying to a lot of different people at this unique point in time is it doesn't need to be perfect. Don't let perfectly the enemy of good. And so if it means you just need to drop it in a Slack channel and you just are like, I don't know where to put this. That's huge. We need to hear from people across the project. And I just really encourage anyone if you don't have the complete information or you're not 100% sure you're afraid it's been reported 10 times before. Like please still report it because we need those reports. And also if 10 people reported it and it's still not fixed, that also means we need to iterate. And so that's one of the things, especially with the pool setting outreach program. I feel like people will message me saying, Hey, I'm sure you've heard this a bunch, but and sometimes I've never heard it at all. And I shudder to think all the people who have not reached out or have not posted in GitHub or track or wherever. So yeah, share, write blog posts. I think that's another great way that people can give feedback is if you don't know how to get to the depths of WordPress, writing a post and talking about it and sharing it on social media is also a great way to get attention. I read a lot of those. But as much as possible, getting to if you can, if you're comfortable getting to the source where we're able to see it in GitHub or track goes a really long way and share as much as you can. And don't worry if you can't spend hours writing the perfect bug report. I'm still wondering if you know. Yeah, building off of what Anne said, just the fact that you're speaking out that you're raising an issue, that's a huge step for many, many people. And once once you've actually done that, as Anne said, it doesn't need to be perfect. There are a lot of other people who are going to be looking at these bugs, trying to figure out what were the replication steps that were used. So even if you can't provide all this detail up front, someone will help on the back end. They'll help kind of fill in those gaps. If you do have the time to actually get deep into providing a very detailed bug report, then there are some key aspects of the bug report that make it very helpful for contributors, not only testers who should be able to reproduce the issue to validate and make sure that this isn't something that's unique, unique to a plugin to a custom theme or snippet that you dropped into your functions PHP, but also for the actual core contributors who then need to be able to understand what is happening so that they can fix the right thing. And some of those items are the information about your testing environment. So that could be your browser, your server, the type, whether it's Apache, Nginx, et cetera, the operating system you're running, what version of PHP you're running, the version of WordPress, very critical. And any themes and plugins that you're using. And that kind of information helps set the stage and then other people will be able to set up their environment similarly if they're going to try to test it. After you have provided the environmental information, then the steps required to reproduce the issue should be as detailed as you're capable of doing. You may not have realized that clicking this caused such and such to happen. So just try to remember or maybe even walk through if it's something you can repeat multiple times, walk through a couple times and write down everything that you're doing so that you're sure, okay, this is the way that I can reproduce this bug. And then those steps will be very helpful for other contributors when they're reviewing it. And then it's also very helpful if you have video screenshots, debug logs, any of those other kinds of resources that you could refer to, because not all bugs are easy to explain. We tend to track and get hub issues for the Gutenberg project. Everybody's writing in English and maybe your main language is not English and that it might be a little bit challenging to do that. So providing a video, it's worth a thousand words in any language. So if you can provide those types of assets, that's also very important. Yeah, and I'll share a little bit of you're not alone in it sort of anecdotes from my first few bugs that I ever filed for WordPress. I sort of had this feeling that if I were to file a bug, like everyone would know that I wasn't a developer and like everyone knows I'm not a developer, but a little bit I was like, they'll know now. And so if that's sort of where you are also and said it and Brian said it as well, like we can't fix things that we don't realize are broken. And just because you've run into it 15 times, which obviously should never happen, you should run into it once and then we know, but it happens. If you run into it 15 times, probably other people have as well. And if it's still not fixed, it might be because no one has thought to themselves, I should tell someone that's broken. And so if that's your primary hurdle folks out there in our listening space, I was once there too. And honestly, knowing that it's a problem is as valuable as knowing the solution to the problem most of the time. Yeah, and those are I wanted to add, there is a lot to that to remember. That's a lot to remember in terms of what you should be submitting. Or I should say what would be ideal and what you're submitting. But luckily, in the test handbook, there's a test report section. And it includes description, it goes everything from it starts with why we do bug reports to examples of the types of testing, whether it be for bugs or enhancements, which also need testing. And it has templates in there that you can copy and paste directly into track. And that's very helpful. Those we will have links to those in the show notes as well. And since we're kind of right there in that moment, what do you think that we could do as WordPress to make reporting problems easier? I know that this has been something that's come up during our weekly meetings discussions on the core tests channel, as well as in contributor day, test table discussions. And the test documentation that's on the website is a little bit fragmented. I believe that the current test handbook was originally written for a type of flow analysis and feedback testing that is not really the norm today. So it's a little bit confusing. The terminology is a little dated. And the most recent updates that have been provided on there relate solely to Gutenberg, which is very important that that also be represented. But in order to find information about testing and track or PHP unit tests, you have to go over to the core handbook. So we could definitely make things improved by consolidating, bringing everything into one area so that if you are interested in testing, you'll have everything in one place and not be split between that and not have outdated methodologies that are asking you to submit videos that nobody's going to really look at because we're not doing the flow tests anymore. So I think that that would be a benefit to future testers. And any thoughts? Yeah, I'll also add that I think there's like two things we can do. One is there's so much happening repressed project in such a cool way that I think the more we can write targeted tests and talk to people about like, hey, here's this new thing coming. This is a high impact area to test. It's under active iteration. You're going to get a lot of engagement. Like people are really thinking about this and pulling people into that where you kind of get the momentum of like getting the feedback in right when someone needs it. I think we could do that a bit more to make reporting problems easier because it's kind of like you're in the thick of it with a lot of people rather than maybe exploring an area where everyone hasn't looked at in a minute. So that's the thing that comes to mind is just the more we can take the time. I think this really cycle has been really good with that where there's been a call for testing for fluid typography. There's also been one for using block template parts and classic themes. And there's a ton of stuff that's been happening where we can kind of make these both developer and more end user testing experiences easier and better. And Brian has done a great job continuing the tradition of, you know, help test this latest release cycle. He's really taken this post and done an amazing job of helping having really specific testing as well. Tidus, I think just this has always been a thing, but just better easier testing environments, both for developers and for quickly setting up more precise to test things for end users. Another thing that we have been discussing in Slack in the core and core test channels is the possibility of pre-populating the track tickets with a template based on what it is that you're reporting. So similar to copying a template for a test report out of the handbook, instead you would hit a button to say the type of bug that you are submitting and then it would pre-populate that and then you could kind of fill in the gaps for that. This already happens over in Gutenberg. There are templates and I find that that is very helpful and so being able to do that in track would be useful. And then for reporting problems on the user side, I thought that it would be interesting to have, like you have for any other modern app, a button that says report bug in WordPress that could capture some intelligence data for your installation, the page that you're on, and have a simple text box where you could provide a little description and then submit that. Now these wouldn't be the types of things that would just go straight into track, most likely. However, it would be an opportunity to allow end users to just send something in, start having it looked at rather than looking and saying, okay, I found a bug in WordPress. Now what do I do? And then not reporting it. So that would be the worst case is that the bug just doesn't get reported. So that would be information that is already harvested if you go to your site health screen in your WordPress installation. A lot of that information that would be useful is there. In this type of bug report, we would want to anonymize and strip a lot of that information out. There's a lot of private stuff you don't want to share. But there is that data there that's available that could potentially help in doing a bug report. Brilliant. All right. Question for everyone in the room. What opportunities are there currently to help with testing? I know, Ann, you already mentioned a few. We can just bombard everybody with links to the tests if we want. But yeah, what opportunities are currently out there? Yeah, I'll mention the full-citing outreach program. I'm very biased, but we're always looking for new bugs. We just crossed, I think, 600 people, which is unbelievable. So even if you're not necessarily always able to help join the calls for testing, you can always pop into the FSE Outreach Experiment Channel, which we'll also add a link to. And that's just a great way when you have time to join, because I flag stuff all the time, whether it's about the outreach program or just in general across the project. Brian does really good weekly roundup testing posts as well, so make the WordPress org slash test is also a great place to get started. And then right now, I think when this comes out will be a great time to be helping test WordPress 6.1. So check out that post. I kind of want to just shove everyone in that direction currently, because I think that's the most high-impacting to get involved with. And one of the great ways to give back to the next version of WordPress to make it really delightful and easy to use. So yeah, I'm just going to leave it there even though there's so many ways you can help. WordPress 6.1 coming out November 1st if you hadn't yet heard about it. Brian, what else you got out there? In terms of the online stuff and covered that pretty well, I would say if you have a local word camp, signing up for their contributor day, or if there are any local WordPress meetups. When COVID ended up hitting and lockdowns were rolled out, a lot of this stuff started to really slow down. So I think now is a good time to maybe introduce the idea for, hey, let's have a local meetup. And for a couple of hours, we'll just do some testing, look at some stuff in WordPress. So it might be a good way of getting people reengaged. It's a little bit lighter weight if you're doing testing versus trying to actually provide a patch to fix an issue. So it might be a good way of bringing in some new faces and reengaging people who we lost over the lockdown period. Yeah. And if you all have never done a testing party for WordPress before, and it sounds like it's maybe a really boring thing, it's actually not. She said with strong authority and opinions. But also, I have never had a more successful learning experience with the WordPress CMS than when I was trying to figure it out with other people. Like, they see things that you don't see, they know things you don't know. And it really covers a lot of the bases for unknown unknowns when you're trying to learn something. And then also you have all these people that like, we're really in it with you and everyone's really pulling for each other. And it's actually a bit more fun than it sounds like when you're just like, a testing party. It turns into just like jointly solving a puzzle together, which I think sounds like a lot of fun. It's like a party, but for technology, I would feel this way. I am a mad extrovert and we all know it, but now you two know it as well. I have a final just like fun question for you both. And if you have an answer, great. And if you don't have an answer, I would be surprised. So here we go. Last question of the day. If five more volunteers suddenly appeared to help on the test team. What would they do? Just I waved a magic wand. I guess that's what made it fun. I don't know. I was like fun question and then I'm like assigned tasks. Yeah, I waved a magic wand. That's what made it fun. I would say I would probably point them to FSC outreach program posts. Because the outreach program does a great job of outlining steps. You're isolating testing in one particular area. It's got a lot of tests. There's examples of the types of feedback that you're looking for, et cetera. It's a really good introduction to it. And most FSC testing does not require a local dev environment, which is probably the biggest hurdle for a new tester coming in. If you do have developers with more experience, then they could start and they wanted to look into track tickets or GitHub issues. Then it does take a little bit of setup and you may spend the next few hours figuring your development environment. So instead I would recommend that you start with something like FSC outreach program posts. I did not pay Brian to say that. We're just all possible to it. I love this question and I actually find it really fun because I think about a lot and I do just stuff we've talked about some of this stuff too. And it's something that when I think about five more people, suddenly appearing like makes me giddy because we have folks who have helped with like I think I've mentioned like translations and group testing and even responding to questions that come from the channel. I'm like, I just wish if we had five folks full time dedicated to that, I could see way more hallway hangout. So we casually talk about stuff and actually get on a call and talk live. I could see folks, someone dedicated to helping translations and translate even more places. We have an Italian contributor who does it regularly, like a full Japanese contributors. Everyone else will get Spanish translation, but I'd love to see more translations to bring more people in, more facilitating group testing, more types of testing, maybe more creative because sometimes I had a creative wall. But more than anything, if I really think long-term, like the project and thinking about this outreach program model, which I don't think I fully appreciated how new it was. Just like when you introduced the idea, I think it would be so neat to bring in more folks to actually create new outreach programs. So maybe there's an outreach program for theme authors or block theme authors or maybe there's an outreach program around collaborative editing. Like, what does this look like and how can we expand this to bring people in? And I think a lot of that will prove the resiliency and the lessons that we've learned from COVID in the WordPress community, and we can't necessarily always rely on the meetup group. So how can we meet people where they are? And I think there's something really interesting and almost serendipitous that the outreach program started literally, I think it was like May 2020, like a couple of months into the pandemic. And I want to see in the position of strength where we both have the in-person community alongside this outreach program model that can like work intertwined. So we can see the model expand to different types. And right now, maybe part of that is we use the outreach program model, the full study outreach program group itself to experiment more and to keep that level of experimentation. That's something I feel really strongly about is continuing to find what works and what doesn't. And so if we had five more people, I could just probably go wild and have all sorts of cool, cool things and spin-offs. But I'm more introverted than Josepha, so there's limitations to this. Well, you heard it first, here first. If you're one of my 6,000 listeners, I only need five of the ones of use to come and make Anne's whole life an exciting joy for the next 12 months. So I only need five of you. And I know that you're out there. There are 2,000 or something, 6,000. I have no idea. I've got more than 1,000 of you listening. And I know that you want to come and help Anne because she's a delight. I know you want to come help Brian because he's a delight. Both of you, this was such a fun conversation. Thank you for joining me today. Thank you, Josepha. Thank you, Anne. Yeah, thank you. And there it is. A bit of a deep dive on the test team and how to get started on it. Like I mentioned, we'll have a ton of links in the show notes over on WordPress.org slash news. And I want to remind folks that if you have questions or thoughts that you'd like to hear from me about, you can always email us at wpbriefing at WordPress.org. That brings us now to our small list of big things. First and foremost, we are counting down the days of the WordPress 6.1 release. We are within a month of the target release date. So if you have not tested the latest version with your plugins or themes, now is the time. Secondly, we are seeing translated tutorials being submitted on learn.wordpress.org. I'm delighted to see that happening. And I encourage any polyglots out there who feel called to consider translating one into your language and help other people feel empowered to use WordPress. And then the third thing is that the WordPress speaker workshop for women voices in India just concluded. So to celebrate, we've opened registrations for the WordPress speaker workshop for women voices in Latin America. Unlike the last one, this event takes place in person on October 29th. And so I'll include a link to registrations for that in the show notes as well. And that, my friends, is your small list of big things. Thanks for tuning in today for the WordPress briefing. I'm your host, Josefa Hayden-Champosi. And I'll see you again in a couple of weeks.