[00:00:00] Nathan Wrigley: Welcome to the Jukebox podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case, how you can assist the WordPress project by contributing.

If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice. Or by going to WPTavern.com forward slash feed forward slash podcast. And you can copy that URL into most podcast players.

If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you, and hopefully get you all your idea featured on the show. Head to WPTavern.com forward slash contact forward slash jukebox, and use the form there.

So on the podcast today we have Olga Gleckler. Olga is a self-taught developer with many years of experience. After initially pursuing a career in marketing, she turned back to her passion for programming and became a full-time developer. She has been contributing to WordPress for four years, and is currently serving as the Core triaged lead for version 6.4.

In addition, Olga is a maintainer for two components in Core, and actively participates in various teams within the WordPress community.

Outside of work, she’s also writing a fantasy book, which has a significant personal project for her.

Olga has tried her hand in various teams within the WordPress community, ranging from Polyglots to Training, Support and more. She challenges the commonly held misconception that only coders can contribute to the WordPress project, highlighting the many different ways individuals can contribute without coding skills.

During our conversation, Olga shares some examples of non-coding contributions that can be made to the WordPress project. We talk about the process of submitting patches and contributions to WordPress, discussing the schedule for releases, and the importance of understanding the processes and deadlines.

Olga also emphasizes the essential steps of testing, reviewing for coding standards and ensuring correct documentation in order to make impactful contributions.

Olga’s journey and the WordPress community has been very varied. She discusses how being part of this ecosystem has improved her career prospects, and gained her trust from others. However she acknowledges that not everyone finds their place immediately and may struggle to get started.

She explores how to contribute without becoming discouraged, and shares her experiences in the mentorship program that paired mentors with mentees in navigating the WordPress community.

Throughout the conversation Olga shows a deep passion for the WordPress project and the collaborative nature of the community. She reminds us that contributing to open source projects requires patience and persistence and shares her insights on learning methods, seeking guidance and asking questions in order to make progress.

If you’ve thought about contributing to WordPress, but are not sure where to begin, this episode is for you. If you’re interested

in finding out more, you can find all of the links in the show notes by heading over to WPTavern.com forward slash podcast, where you’ll find all the other episodes as well.

And so without further delay, I bring you Olga Gleckler.

I am joined on the podcast today by Olga Gleckler. Hello, Olga!

[00:04:08] Olga Gleckler: Hi.

[00:04:09] Nathan Wrigley: Very nice to have you with us. Olga is going to be chatting to us today about contributing to WordPress, probably specifically around WordPress Core, but we will no doubt in the introduction discover that Olga’s done a lot more in the WordPress space.

Olga, just before we begin, let’s orientate our listeners a little bit about you. This is a chance to give us your biography. Tell us who you are, how long you’ve been working with code and computers and in the WordPress space more specifically. You can go as far back as you like.

[00:04:43] Olga Gleckler: Sounds great. I wanted to be a programmer at school, but I messed up with my education and turned out to be a marketer. Then I was a bit disappointed in marketing because you cannot promise to deliver something and actually deliver it. And I switched back to my previous passion to development, and become a developer like a self taught.

And already nine years I’m working full time as a developer. And four years I’m contributing to WordPress. To find the WordPress community, it was a big discovery for me, and actually turning point for the whole experience, because WordPress is good, is great, and I liked it.

When I discovered the community, I started to love it. And since Berlin in 2019, I joined marketing team and several other teams. I contributed to polyglots team, to training team, to support, I love support. And some other teams. And right now I am Core triage lead for 6.4. I was Core triage co-lead for 6.3 as well.

I’m a maintainer for two components in Core, so I think I know a bit about how you can actually contribute to Core, and I still enjoying all the process.

Apart from full time job and contribution, I also want to mention that I’m writing a fantasy book. It’s like a big deal for me. It’s a draft, but it’s another passion I carry on with myself all around the world.

[00:06:25] Nathan Wrigley: That’s really interesting. So you’ve been involved in all sorts of different sides of WordPress. You mentioned there specifically that you joined the marketing team, obviously based upon your past history with studying marketing and things like that. But you found that that maybe wasn’t the best fit for you. And I guess that’s going to be part of the conversation today, is that there’s a lot of different places that you can contribute. And if you join a team and it doesn’t seem to be the right fit first time, that’s not a reason to give up, because there are just multiple different ways that you can contribute to WordPress, right?

[00:07:02] Olga Gleckler: I love marketing. I cannot kick it out of me, and I still deeply involved in marketing team activities and most of my efforts I am making are between teams. For example, between marketing and mobile team, between marketing and Core team. It’s something inside me and I cannot kick it out, and I’m looking at Core tickets from the marketing point of view, and trying to find something significant, something to change, something to improve user experience, to deliver improvement and make a difference and impact.

So, yes. I joined marketing team first and I’m still there, part of the marketing team, but I tried different things like in support, in polyglots. They are all very different and very important as well. So I poke around a lot, and finally I pluck up the courage, with help, and starting to contribute to Core team.

[00:08:06] Nathan Wrigley: It sounds like on your journey you have dabbled in, you said, poking around, you’ve had a go at various different teams and you’ve obviously enjoyed that. In some of the show notes that you shared with me, you list out some of the different things. So you’ve been involved in several different teams, for example, polyglots, training, and you mentioned support and TV actually, which is kind of an interesting one.

That gives us an idea of the different things that you can be involved in. There’s a whole range there, but I want to drive this message home. The idea that if you’re in the WordPress community, I think there is a perception that if you don’t code, you’re probably not going to be able to contribute. And I think it’s fair to say that you really don’t believe that. That’s just not true. You don’t have to have any coding skills at all.

Now, clearly, if you’re tackling contributions where code is required, that’s probably different, but there’s loads of different ways that you can contribute. And I wonder if you wouldn’t mind just telling us about some of those different things. Some of the things that teach us that you don’t need to be a coder to contribute to the project.

[00:09:17] Olga Gleckler: For example, Community team. Community team is handling all the organization processes for meetups, WordCamps, other events and supporting people. It’s a great and a big job for managers. People who are taking care about things. You don’t need to be a developer at all. You just need to manage things.

And this is only one team, and we have more than 22 teams. We have security team. It’s a bit obscure because obvious reasons, but you can contribute to all other teams. For example, if you are teacher, you can contribute to training team. If you are purely WordPress user, you can contribute to a lot of teams.

For example documentation and checking if things are clear, and documentation is actually following the actual result or not, or something needs to be changed.

And users, just users without any experience in development can bring a huge value because developers are, we have such flaw because everything is working for us. We know how it should go, and it’s going in the right direction. And if you don’t know how it’s supposed to work, you can poke around a bit and discover some flaws, some doubts, some things which are unclear, and bring a huge value for the code itself.

And apart from it translation. Polyglot team is your goal if you like to translate. And this is the way to improve your own understanding of English and your own language. Because if you are starting to translate, it’s become apparent, obvious that it isn’t easy to do. And you need to put your brain, your heart to this task at hand.

And support also a good point for people who want to learn. Because if you, for example, can answer like one question from ten, you can make someone else’s day better.

And in the process, you can learn more and more, and answer more questions, and improve your own skills this way. Just helping other people. And. This is only few teams you can contribute.

And also TV. You can edit videos for other people. You can translate and make subtitles for these videos. You can of course review them.

And the team everyone is just love right now is photo team. You can contribute your photos to photo directory and contribute this way. If you are a photographer you can contribute to WordPress your ideas in pictures. And of course, if you like looking at pictures, you can go and review these contributions. Because there are some rules, for example, people not, should not be present on these images, et cetera. So there are some rules about quality, et cetera.

So we have a lot more abilities. It’s just top of things and we have a lot more.

[00:12:37] Nathan Wrigley: There are, from everything you’ve just said, so many different avenues that you could go down. And I know, even though you gave us quite a list there, you’ve still probably only scratched the surface, and if you were to get into the weeds of those teams, I’m sure there’d be something for everybody.

I have a question. It’s a bit of a personal question. And I’m really wondering why you do this. And the reason I’m asking that is because a couple of times in what you just said, you mentioned how it was good for your, your heart. If you like, it made you feel better. But also you said that it was helping other people.

And so let’s, for example, say that you answer a support ticket, you’ve helped somebody out. You’ve taken them from a place of not knowing, to a place of knowing. So, why do you give up your time? What is it that you get out of it? That may be simply that it makes you feel good, you want the project to be better, so that you can be employed from working with WordPress.

It may be that you just enjoy it, that you get to meet new people, attend events, go in any direction you like. I’m really curious.

[00:13:37] Olga Gleckler: I think I love everything. I put my trust in WordPress. This is best choice there is. I believe in it, and of course I’m going to improve, to put back this Five For The Future of myself. To be able to work and use WordPress continuously, and improve it like it’s obvious choice for people who are working on it. And this is only one way.

The second, I love all this gathering, all these people with passion. Open minded people and everyone is curious and want to learn and want to do something. And everyone is open and this is a safe environment. We’re all following code of conduct. So, it’s completely different space. Open source project. It’s blow minded. I think how it can change your mind and your perspective.

And of course I got job proposal, previous one, because people know me in the community. And this one is also partly because what I’m doing, because I’m well known, a developer. So I was wondering, where is the technical interview? And I was told that there is no need for you, because we know that you are up to scratch already. So it was a good point.

So people are amazing. You are improving your skills. You are getting understanding of your level in comparison to other people’s level. You can learn on their efforts and, for example, patches, examples, documentation, etc. So you are continuously improving yourself. A lot of reasons.

[00:15:26] Nathan Wrigley: Yeah, there are a lot of reasons. Really interesting though. There’s obviously a lot of desire from you. You obviously enjoy the whole ecosystem and all of the different tendrils and spokes on the wheel. But also interesting to note that you’ve also done your career prospects no harm by contributing, because you get to the point where you’ve contributed enough that people are going to start looking for you as somebody that they can trust and rely on. So you kind of jumped over the hurdle of job interviews a little bit there as well. So that’s really interesting.

Okay. Let’s move on to the, another part of the conversation, which is beginning contributing, how you might do that. Because I’m guessing that for some people, it may be that you hit the ground running and you decide, okay, I’d like to be part of the contribution community and you find the right project and you find the right thing to do immediately. But I’m also fairly sure that other people will get discouraged. They’ll perhaps jump in to the wrong part of the project, or maybe tackle something which is a little bit difficult. They can’t find the people to help them and so on. So I wonder if you’ve got any advice about that? Trying to contribute without getting discouraged.

[00:16:40] Olga Gleckler: Firstly, you need to know what is your learning curve, what is best for you. Sometimes it takes some time to figure it out. For example, some people are purely reading documentation and they are fine with it. But some people need video recording, or they need like a leg up from mentor or just little help for like facilitators.

And we are trying to provide all this to make it really easy. Right now, there is a barrier, yeah. But if you want to start to contribute to Core, for example, you need to go to new contributor chat. This is like bi-weekly meeting before the main dev chat. And it’s better to ask questions. For example, we are like going through the usual script, we are highlighting several documents and links you’re supposed to browse, but you can be stuck at any moment and actually these meetings are for providing help and we are there.

I’m mostly present there to help if people are stuck. And you need to understand that asking questions, it’s normal state for everyone. We all are continuously asking questions, and there is no stupid questions, because everyone knows that sometimes it’s hard to begin. Or even you can miss something obvious, even if you are the smartest person in the world, you can miss something obvious, because it’s obvious for someone else.

So, this is how you can start. But in addition to this, we started a contribute mentorship channel in the Slack. This is dedicated channel for contributor mentorship program. We just finished first pilot program when we took 13 people and they got their own mentors. But everyone else was hanging around, and facilitators like me was providing help for people and answering questions. Specific questions, like how to start, how to pick up ticket, what I should do etc. And if I am like with such background, what is better fit for me, etc.

But as well, apart from this, you can just poke around and be present in usual developers chats, but it can take time. So to make things quickly, you need some help from people. And we are actually ready for help. And in the documentation, there is a list of people whom you can ask if you have questions and difficulties. I’m listed there as well. So people are actually writing for me in DM if they don’t like comfortable enough to write openly, and asking such questions.

But if you want your question answered sooner, you can just go to Core channel in the Slack and ask this question openly for everyone to see. And this way you can contribute to other people’s success as well, because some people not ready to answer this, the same question, and they can see your question and pick up what was written to you. But you don’t need to jump in the middle of usual, regular chats. You need to wait until open floor if there is like a dev chat going on. So your question can be like, just be flooded with everything else which is happening. Or this is a release going on, no one will be able to answer your questions properly.

[00:20:27] Nathan Wrigley: Yeah, that’s a good point. Timing is crucial. I’m just going to circle back to the mentorship program because I think that’s really interesting. So this is a new initiative, and it may be of interest to people who perhaps have thought about contributing, but have been a little bit unwilling or discouraged, or they had some bumps in the road and decided not to continue.

Can you just tell us what that is, how that process works? And I know it’s new and I know you’re trying to figure it all out, but what is it? How does it work? My understanding is that you will be partnered, in certain teams, at least anyway, with people who have done the role that you’re hoping to do and can therefore sort of shepherd you for a period of weeks. Set the expectations for you, give you some advice about where to go for help and all of that kind of stuff. Have I more or less got that right?

[00:21:17] Olga Gleckler: Yeah, it was a pilot, so we were just trying things. The plan for people was decided, how they can proceed. And we received 50 applications, but was able to take 13 people to partner them with mentors. Mentors were people with wide knowledge inside the community and contribution, but not exactly the match on person’s interests. This person was providing like general support. And actually it’s works great.

They make contribution plans and providing feedback, what’s working, what is not working. And first two weeks mentees was doing learn courses. And I think 11 of them finished all courses. And then we started sessions, introductory sessions, for many WordPress teams. I had one introduction session for Core. It was also training team, polyglot team, support team, community team, and several other teams.

So we put a lot of efforts and most of these sessions are recorded, so you can rewatch them. And this was only the first pilot try. So I think the next time we will do better. And we actually scheduled this to be finished next day after release. So our mentees was able to see the whole process of the release alongside with us, and take part in this.

And several people actually contribute to Core. They made patches, they tested things. From our point of view, it’s a real success and we provided people ability to start quickly, and when there are dedicated people, it’s much easier to ask questions and get answers, and be oriented in this huge area. And because this mentees got an overview of the whole project, like general.

They was easy to understand what will fit them better. If they like Core, or if they want to translate things, or if they are going to support. Actually, I think one guy answered 200 questions on the support, on the spot, yeah. I have much difference in answering questions. It’s actually takes time, but he went passionate about this, and it’s great.

[00:23:43] Nathan Wrigley: You mentioned in the shared show notes that we’ve got together for this podcast episode well, I just think this is a lovely phrase, so I’m going to read it out. You wanted to talk about setting the right expectations and understanding of processes, and the fact that these are the key points to, this is the bit that I really like, joyful contribution. So I wonder if you could outline some of those things, some of the wrinkles, some of the expectations that you need to, not only have set for you, but need to set yourself. Because it may be that there are going to be bumps in the road, things that don’t quite work out.

You may tackle something which ultimately never gets used, or you may think that you’ve created a solution, I’m thinking about coding in Core in this particular case, which then has an impact on something else. And so it needs to be iterated on over and over again. So I guess what we’re trying to say is, it’s not always going to be plain sailing. Not every contribution that you make might be used or suitable. But there are things that you think you can do to make sure that the process is more likely to work in your favour.

[00:24:46] Olga Gleckler: Yeah, because it’s open source. We have a huge community and we are working together. And if you did something like your part, it’s a bit naive to expect that someone else will pick immediately, like next day. And everything will be done until Friday. It’s not happening. So if you know that things are taking time and can be more complicated than they look like in the first place, you can adjust your expectations and don’t expect your shiny new Core Contributor badge next morning on your profile.

You will get this badge, but only when you’re patch, or testing involvement, or other contribution will be going to release. So you will get this batch after the release, right after. But still it takes time. So if you are like in a hurry, you need to adjust.

And of course, sometimes people are creating a patch, like I’ve done everything and it’s not going anywhere. And they are becoming disappointing and interest is going away for contribution. So, what you should do if you did something and no one is paying attention, at least it looks like it. You need to understand that we have more than 8,000 open tickets. So, it’s a huge thing and we are continuously triaging these tickets. This is why we need continuously triage and component maintainers in the first place.

So if you did something and no one is bothering about it, you should look if this ticket has an owner. Owner is not a person who is doing the patch. This is person who should care, who supposed to care, about this ticket and push it forward. If this ticket has an owner, ping this owner right in the ticket. I did this, please take a look and how we can proceed.

And this ticket has no owner, you can’t ping component maintainer. Some components don’t have maintainers because we have a lot of components and a bit short in maintainers. What should you do? You can turn up on regular dev chat, wait until open floor, and ask about your ticket and what you want to do about this. There will be a lot of seasoned Core contributors around at this point, and your ticket will be noticed. If it will be like good to go further or you need to rework, it will be seen. But at least you will be starting in the right direction forward. So, you need to be a bit pushy about things to make them happen.

[00:27:31] Nathan Wrigley: Yeah, I guess that’s a really interesting lesson, isn’t it? If you contribute something and it doesn’t either immediately get noticed, or you feel that it’s not being noticed, I think that’s interesting advice. There are different ways that you can make your voice heard, shall we say, and you’ve mentioned some of those there.

You also wanted to point out that there are roadblocks in the timeline of WordPress, where if you submit, let’s say a patch to something, there are periods in the calendar where things are frozen. And so there are periods, for example, just prior to a release, when we get to release candidate one or beta one, where really, you’re probably best doing something else because there are freezes. You say that the polyglots team needs to be able to translate strings and things like that. So don’t know if you want to talk about that.

[00:28:19] Olga Gleckler: Yes, sometimes people made something and turn it up, right before the release. And they are disappointed because their patch will not go to this release. Because we have schedule and schedule for the next release, you can easily look on the make wordpress dot org slash core slash 6 hyphen four, for example, right now for this release, and understand the process.

So if, for example, you are working on enhancement or a feature, they need to be in the trunk before better one. Because it’s like a significant changes, and they need good testing coverage, et cetera. Big things needs to be, go first. If ticket has a keyword early, it should be even before beta one, like right after the previous release. It should be done quickly, because these things can impact a lot.

And then there’s a release candidate one. If you are working on a bug or if you are anything have content change, it should be in the trunk for release candidate one. Because with release candidate one, we have strings freeze. This is time before release candidate one and actual release for Polyglot’s team to be able to translate this new, or changed strings, to their own languages and make WordPress great in their own language.

People need time for this, and we have a huge amount of strings. If you will be starting to contribute to Polyglot’s team, you will start to understand that it’s also a big deal and a big job. So if you’re working on something, you need to fit your patch in this right moment and not after.

And of course, your patch needs to be tested, your patch needs to be reviewed from coding standards, for possible regressions. Possibly you will need to rework some things, or make changes in supporting documentation. For example, each function has this description, yeah, documentation for this function.

This is why WordPress is so great. It’s clear, good written documentation inside code. So everything should be fine before it will go to trunk, even if the thing is working itself. Sometimes you need to cover this code with unit tests and you need to take into account these things as well. Sometimes, most of the time, people are surprised about unit tests.

And we have a huge coverage of the code and it’s actually great. It makes things robust. So if you fix some bug, you are covering this part of the code with unit test to be sure that this will not be happening again. And it’s actually great.

[00:31:09] Nathan Wrigley: There are some places, probably it’s fair to say, which are better places to start. And again, in the show notes that you’ve shared, you’ve alerted me to the fact that it may be that you think something is going to be relatively straightforward. So again, we’re talking about bug fixes here. So we are talking about the code.

But it may be that you submit something and it turns out to be more difficult. So what you suggest then is that there are some recommendations for where a new contributor might start. So perhaps not the best idea to find the most difficult and challenging thing first time around. And there is some guidance that you can give in terms of where to look and tickets that are marked in a certain way. So yeah, I wonder if you could get into that.

[00:31:53] Olga Gleckler: Yes, sometimes ticket can be, look very simple, but can turn into a rabbit hole. For example, my best example so far is changing double equal to triple equal. It can bring a lot of regressions, and you will be browsing, trying to fix other things. And most likely this change will not be worth it. And it will be very difficult to convince everyone else that it’s actually worth doing. And, we will not have ten more bugs because of this one.

So sometimes good new patch, like a feature or enhancement, works better. And robust piece of code, when you have like head or tail, it’s great. And we have tickets which are marked as good first bugs. So if you are browsing tickets in Core track, you can see these tickets by this keyword, by search, custom search. And you can even subscribe to this good first bug hashtag on Twitter and following these tickets.

For example, if some ticket is not good for you. If you don’t like it or you don’t want to work on UI, for example, or you prefer some other stuff, you can be subscribed to this hashtag, and following along and see what is actually working for you. And start when there will be like right ticket for you.

But this can be like a bit shock, because a lot of people are subscribed to this good first bugs, they can be taken and already someone else can make a patch. But another thing is that if there is a patch, it does not mean that you cannot contribute because you can review this patch, you can make improvement to this patch.

You can collaborate with other people on this ticket and make it work, and be great and quick. So, don’t abandon some ticket if there is a patch. Work is not done with the patch, it’s just the beginning.

[00:34:01] Nathan Wrigley: You also make a recommendation to look out for, I guess, if you’re beginning at least anyway, to look out for tickets where the scope is really clear. And you’ve also got channels for feedback.

[00:34:13] Olga Gleckler: Yes, definitely. Because sometimes scope isn’t clear and it also can turn rabbit hole. So if you have any doubts about tickets, just any, like a tickling feeling inside your head that something is not actually right, you can turn up into the Core channel on Slack, and ask about this ticket.

Seasoned contributors will look through and clarify things for you. It’s actually better than put up a lot of work and then turn out that something was wrong in the beginning with the ticket and approach is not working. So don’t waste your time, and be ready to collaborate on the ticket from the beginning with other people. And it’s what actually is working.

If you are like staying alone and doing something, you can feel lonely and a bit abandoned, and then disappointed. But if you are open to conversation to other people and can receive help, you can provide this help as well. And we are all working on the final result, on WordPress, and it’s great.

[00:35:23] Nathan Wrigley: I like the way that you’ve rounded off the show notes, because you make the point that whole process of improving WordPress is a continuous learning process. And you may feel that you’ve just provided lots of your time. Maybe your patch wasn’t used, or you ran up against something which you couldn’t work out for yourself, and you needed additional help.

But you make the point that it’s okay, you know. It wouldn’t be wise to view that as a waste of time because even negative experiences, when you view them from a distance can often be helpful. You may learn something along the way. So negative results, negative experiences may also turn out with time to be positive experiences. And so I guess that’s kind of a nice way to frame it.

[00:36:05] Olga Gleckler: Yeah, you can like cut out things that are not working and to make clear paths to things which are working. And then the result, everyone’s contributions count. No matter if you make patch and it wasn’t working, and someone else went and improved your patch and make some additional things. And another iteration, another approach discovered some other possibilities. Upon your negative result, they will be going forward.

[00:36:37] Nathan Wrigley: Just before we round it off, I do wonder what your thoughts are. It’s very clear from everything that you’ve said that you’re very committed, you’re very keen. You love all this stuff. I wonder what the state of contributions is? I’m particularly thinking about things like the pandemic, for example. And whether or not that had an impact in the amount of time that people were able to give.

My understanding is that contributions may have taken a little bit of a dip. I don’t know where we’re at right now. Obviously the program that you mentioned for mentoring earlier is a great way to encourage people, to get people back in. But I don’t know what the situation is. Are people contributing this year in the same way that they were, let’s say, five years ago? I don’t know if you have any data on that at all.

[00:37:24] Olga Gleckler: I don’t think any data, but yeah, we had a drop in contribution when pandemic started, because everyone was distressed and we need to take care about our family, our health. So we went through this and not once, but several times having this thing.

But right now I think we are on the right track. It comes down and we used to new things, and it’s actually turned to be better for everyone. Because, for example, employers understand that people are able to work remotely. And many people right now are working remotely. They got more time. They are saving time on this road to work and back at home.

So they are keeping this time and they can contribute more easily. I’m an example for this because I’m working remotely all these nine years. This is why I was able to contribute at the beginning, because otherwise I wouldn’t have time. So I think pandemic, it was horrible, yeah, but it’s turned for the better. And right now we can do more. We can contribute more and we can be more flexible in what we are doing.

[00:38:45] Nathan Wrigley: Olga, I think we’ll wrap it up there. But before we do, obviously, you’re very keen, and if your passion for contributing has rubbed off on somebody else, and perhaps they would like to talk to you before they jump in with both feet. I wonder if you wouldn’t mind telling us a little bit about where we can find you. That might be a website or a Twitter handle, whatever you like.

[00:39:07] Olga Gleckler: I think best place to find me is on Slack. Why my name? Because there are several channels, I can put people in the right direction straight away. And because I’m almost always there. I just want everyone to join. But, yes, if you have problems with Slack, and it can happen, then you can reach me on Twitter, and I will be able to help you join WordPress org, create an account, etc. But, probably you can try it yourself.

[00:39:42] Nathan Wrigley: Olga Gleckler, thank you very much for joining us on the podcast today. I really appreciate it.