 Hello everyone. Welcome to Contributor Mentorship How to Start Contributing to WordPress Core. I hope you will enjoy this, so let's start. Firstly, a bit about me. I'm a WordPress developer and with background in marketing. Quotriage-Cole for 6.3 and 6.4 releases a maintainer of two components and font editor. I didn't publish anything yet, but I have like a lot of content and draft and this has become a bit part of my life. So I think that I am already a font editor. And you can find me in WordPress News in 2021, I think. And you can find a lot of more interesting people there, so check it. What we will discuss today. Firstly, release schedule. I will talk about why it's important a bit later. It will be very clear. Different ways to contribute to WordPress Core, how to use track and search for suitable tickets, how to collaborate with other contributors and what to expect. But firstly, what is here for you? Why it's actually worth doing? Firstly, ability to make a difference. You can imagine WordPress is used by millions and millions sites. It's also a learning opportunity because when you are working on such large scale, you make things which are supposed to be compatible according to coding standards and a lot of other things you need to know and keep in mind and you will learn them in a process. No one knows everything at once and you can collaborate with people, share ideas, look what other people are doing and this is the beauty of open source because what people are doing is actually open and accessible and you can watch and learn and make some of your own ideas from what you learn from other people. And also you can try new things. If you are, for example, working with front end on your main job, you can try back end or otherwise, or you try to make unit tests if you didn't do it before. So there's always some possibilities to try something new or to watch from some other perspective, the same things. This is safe environment. All people who are working with WordPress, who are in our community, are passionate about WordPress and because people are working from all over the world, we are embracing all this differentiation between people and it's become common knowledge that we all are different, but in general we all people and it's what matters and we all contribute. It means that you don't have to do something. It's your own free will and it's your own choice and everyone is respecting everyone else's time and impact and efforts, etc. So here is lovely people and this is why a lot of people are staying in this community and contributing the first place because we all are friends and we are staying for each other and support each other and this is much more than just contribution to some product itself. And of course, you can have a very, very big plus to your resume, because if you didn't do something before and you've done it for WordPress, you can prove it, you can share it, you can show it to everyone else. And I think there's a much more abilities. If you are working in some company, you will be only sticking to your own job description and will not be able to participate in other activities. Here, we have a lot of possibilities for you to poke around and to share your opinion, to make suggestions. So this is the beauty of open source project. We can do, for example, marketing, no matter if we are marketers or not. If you have an idea, you can share it, promote it, collect opinions from other people, and actually it makes work. So it does not matter what is your background. Do you have a degree or not. If you have an idea, it can work and be practically applicable. So, let's start with release schedule. Why it's matter? Because we are staying with release schedule and it's planned ahead for a year, and there are some milestones inside milestone, and we need to stick with them. For example, right now we have only dry run planned. Possibly there will be one more release, I think, if we will have some tickets committed before dry run. But right now it's almost done. Version is almost complete. And if you expected some ticket of yours to be merged, to be committed into trunk, there's no go into this current version. And right now, if you are working on something, it's quite achievable to make it work and be live for the next 6.4 version. Because right now we can work on enhancements, futures, strings with translations, descriptions, everything is right now possible. Before better one. When better one will be released, we will not be working on enhancements and futures anymore. We can work on them, but only for the next release. And from better one, we only be able to commit bug fixes. So if you are working on some bug fix, you can continue to work and expect it to be in the next version until release candidate one. There is a release candidate one. We are stopped working on bugs almost if and there is also hard string freeze what this means, it means that all content, all the strings which needs to be translated are free. We are not accepting anything else anymore. These small exceptions, but strings for translations are done at this to this moment. And you need to keep it in mind because polyglots need time to translate these strings before the release. And I think 45 around 45 like locals are doing this before the release. So, this time needs for them to translate these strings because it's really annoying for polyglots when they translated some strings and they become fuzzy because something changed. They need like double their work and it's not fair for them. So this is why we have hard string freeze. And if your ticket has some strings change, there's no go for this ticket. And from release candidate one, we only working on some regressions and some things which should be in release like very urgent. So some exceptions, some regressions, we are fixing bugs which appears in this new version. So if a bug appears in new version, it needs to be tackled as soon as possible. This is the key point. And this is why we have like release candidate one, release candidate two, etc. And dry run means that everything is already done and we are just preparing to make big appearance, big release. But if some things changed before dry run, we will have like another dry run. So sometimes we have like a bit shift in schedule because some additional changes. And we have a release party and the next release party will be next Tuesday, I think. And it will be 6.3 lunch. Everyone is welcome to join. And it's really amazing thing. We all love emojis. And we have like a lot of steps to proceed. But people are like keeping excited. And we also need something to do. We have something to be done. It's checks because I think once I saw that package went wrong and it needs to be repacked. But most times it's fine. Still, it's worse to check because of impact what we are making and having. Like you see, in each release, we are like collecting numbers for previous release. This data is publicly acceptable. There is a page with this counter. So 91 million downloads. You can imagine this impact. This is why it's worth checking even if everything should work fine. And also, each time we have some additional information like musician name and content about this release. It has like a lot of work behind this content to assemble everything. And also about release. If you want to see your name on the release page and have a batch of core contributor, it will only happen when it's updated. So it's happening after official launch. So if you are like wanting to see batch in your profile, you need to wait until the release party. If you contributed to this release or if you will contribute to the next release, you will have this batch but after release party. It's almost like an hour, I think, matter, possibly two, but it still needs to be done. And it's not a piece by magic. It's a piece by commit as well. Let's talk about different ways to contribute. You don't have to be a developer to contribute to core. Of course, if you are a developer, you can contribute in much more ways than if you don't, but still there's options for everyone to be involved and get started. And if you are not a developer, but you think you can try it, you can make it slow and start with a contribute with something which don't need to have development skills in the first place. And all contributions matter and can't. Sometimes you can change one letter in a word, for example, something for make a mistake, someone made the mistake, you spotted it and fix it. It's also a contribution because if we are working on such large scale, everything should be fine. But sometimes it's tricky and it can be easily overlooked. And also, if you try something, for example, you made a patch, but it didn't work for some reason, it's also counts because you found some way which can be left behind and everyone can go further to explore other possibilities. We have a lot of tickets, but we have them because it's not easy a lot of times to find a right solution, even if the problem or issue can look simple from the beginning, and it's often like a misleading simplicity. Because we are working on such large scale, and this is not should not only work for yourself for your environment, but for all other environments, and it makes things quite complicated, even if they look like piece of cake. So different ways to contribute. Everyone can test current development version, alpha beta or release candidate, and you don't need to have development installation for this, you can install these versions with beta tester plugin, and after you install this beta tester plugin on your WordPress version, you don't do it on production, on your live sites, do it on local environment. Still, if you install this plugin you can choose what version do you want, night builds, betas, release candidates, etc. And you can poke around and test, because we have a lot of changes, especially with Gutenberg and editor. There are a lot of bugs to be fixed. So, there are exploring opportunities for everyone. And you don't need to be a developer to do this to check if buttons are working correctly if you have right behavior from elements, etc. It's even better in this because developers are used to complications, so they can overlook them easily. So, and if you stumble across this, something you think it's a bug, you can create a ticket to fix it. It's also a contribution. You find something, and you are providing ability for someone else to fix it, but of course if you are a developer you can fix this bug yourself and make it like weaker. And when I was started to work with drug, I noted that a lot of people are doing this, this, the same thing, they are reporting the bug and they are proposing patch at the same time. Because it's, of course they just want it, but it makes sense because people spend some time to instigate what is happening, why it's happening. They had like a half of the solution already, and it's easier and quicker for them to make a patch then for someone else who will be browsing and looking through the content of ticket and description and trying to figure out what had happened. And you also can propose an idea, some improvement enhancement, future request, if you think that something should be done, you can browse tickets and see if there is the same idea already, and contribute to it on, and if there is none, you can create your own ticket. But the description, of course, should be good. And from this, it's like meta, because if description is good, it's more likely that someone will understand what it's all about and starting to work on this. This is also what you can do. This is called triage. In triage sessions, we are looking through tickets and check if there is a correct component, correct keywords, correct contributor focus applied, if description is good, if this ticket needs screenshots or this ticket needs involvement from designer, design team, etc. So this also a way to contribute for people who are not developers. For example, if someone is reporting that some elements are going outside of some other elements and they don't should not to do it, and there is no screenshots. Sometimes it's very difficult to understand what had happened, and you can make screenshots and attach them to tickets or actually make a small video. Sometimes people are attaching screenshots from there, some other external source, and later they are removing these screenshots, and it isn't clear anymore what had happened. So someone needs to go and restore and check if this issue is still happening, and if it's happening, and if this actually happening how it's described. Sometimes people are describing things very weak, so clarifying checking triage and things is also a big part of this job of moving tickets forward. So this is what I'm doing for 6.3 and 6.4 releases, but I'm not alone, and I hope to assemble some team to work on this because it's like a big job, and you need sometimes to push things forward to ping people to ask people to make some additional investigations to ask an original reporter for additional information, etc. So this is like managing stuff, and someone should do it. And of course you can test patches. We had a session about testing before this project, so I will not go deeper in testing. So this is a code, because of course all developers love their code, and we think that it's perfect, but it's not actually true, because most of the times there can be improvement even if code is working correctly. And because we are working on such large scale, we should be very careful what we are writing, how we are writing, how we are checking and make like a doctor, not to work something which is already working. We need to be very careful, and if even some simple changes for some simple things, they can be very tricky. So you can review other people's code and validate how it's working and what can be done further. It's also worth to have like second, third pair of eyes and additional brains to work on the ticket. You can also of course write patches yourself and update someone else's patches, because if ticket has a patch, you don't need to drop it immediately, because most of the times ticket need additional work, patch need additional work and sometimes people who made the patch, they don't have capacity to work further, and someone need to pick up this work. It's good opportunity, also learning opportunity for developers not to create patch from scratch, but improve something which already exists. You can also write unit tests and end-to-end tests. I think we have like huge demand on this too, because unit tests, if you are not writing them like on daily basis, it can be like a bit tricky. You need to use to write them, but it's also a big learning opportunity, because after you're starting to write unit tests, you will have some shift in your thinking about how to structure code. And you will be better structure your code, your own code when you have your main job or some other projects, and it will benefit your abilities to make code which is good structured, which is simple in understanding etc. So it's worth doing. And you can actually recover your own projects with unit tests and stop manually checking things. And end-to-end tests is also like a big deal because it's quite tricky. It's simple and tricky at the same time, because we don't have like a lot of people who can do them, and we need to move these things forward. And you can take part in a new default team development, because the next version 6.4 will have a new default team theme, and this is also a great opportunity to learn how these things should be done in the first place, to take part, to test, to debug, to improve things, because it's like a huge amount of work and when such things are happening, you cannot do this alone and there can be a lot of complications, bugs, etc. So a lot of work is there. If you have no idea what to do, you can join team development. And of course you can review and write docs. There are docs inside code. This is function descriptions, etc. But most of what we are considering docs is actually documentation on WordPress.org and because things are changing continuously with core, someone should go and check them and make updates in users documentation. It's also a big job and sometimes you don't need to be a developer, sometimes you need to be a developer to understand things deeply. So let's talk right now about Cortac. Cortac is our control center for working with tickets and we have a lot of pre-built reports like latest tickets, active tickets. If you are looked in, you can have tickets you are watching, etc. Pay attention that if you are watching tickets, you are not receiving notifications. You can subscribe to notifications here, but somehow you don't have notifications about tickets you are watching. So you need to pay attention for this, but if you are participating in ticket you will have notifications, but you can unsubscribe to them if you don't want to participate in some tickets anymore. So you have these like abilities. What I like most is design your own query. Because you have like a lot of options to choose from. Most useful is keywords. Of course, these keywords are useful because we are triaging tickets and putting these right keywords in this first place. You can also choose component. And we have like, I don't know, 20 more components. For example, I'm a maintainer for about and help component and bulk editing. So bulk quick editing. So if I will like be looking for tickets in these components, I will choose this component and look through these tickets. You also can choose milestone or why it's important if you want to work on something which is like most likely to be in the next release, you can choose milestone 6.4 and have a look at these tickets because a lot of tickets need work. If these tickets are in the milestone, it doesn't mean that they like, no, if they are not closed, they are not done. And there's some work needs to be done still. So if you want your name in credits page, your page in your profile, you definitely need to pick a look in the 6.4 milestone and work on these tickets. Because they are already someone else decided already that these tickets should be in this version. Of course, if you think that some other ticket should be in this milestone too, you can raise this question. For example, you can ping component maintainer, or you can go to regular WordPress meetings and raise this question like, if you think that something should be done, you can go and do it. You can push things forward, and you don't need to be developer to this either. Let's talk a bit about local environment. I believe we will have another session purely about actually developing patch, but right now I want just like to have a quick peek. First of all, you need to fork WordPress development repository into your own account. So you have WordPress developer, and you can fork it. Like you see, there's like two thousand forks already, and you can make your own. Yeah, it's a bit of disadvantage if you like have your Git repository already full with stuff, you need to clear space for this one, but it's worth doing. And then you need to install some things. It can like take time, but it's not difficult. It just needs to be done. So Git NVM, this is not version management. I think something sensical. The key point is that you need to switch between node versions because WordPress needs 14th version of node and for other, for example, products you have, you can possibly need another version. So to be able to switch between versions, you need this NVM. And then you need Docker, and then you can follow the instruction clone this fork to your local machine and install. Everything should be fine. You need to update this fork and pull updates to your local machine. There are some things I think Git actions which can automate this, but I didn't bother to investigate this. Possibly some people have an answer how to make it automatically. But I'm just like pushing buttons a bit. And if you have questions or difficulties, please join the next new core contributor chat, which will take place next Wednesday at 7pm UTC. The full schedule of regular meetings are present by this link. So I want to discuss a bit how we are actually working together. Firstly, you can contribute to any ticket you like. There is an owner of the ticket, but it doesn't mean that this person is on this ticket. It means that this person should look for this ticket to move forward. But sometimes it's working. Sometimes these people already have a lot of tickets on them, and they cannot look through all of them. So if you, for example, done something like a patch and it looks like no one is bothered about it, you can ping owner of this ticket if this ticket has an owner. If this ticket has no owner, you can ping this maintainer of this component. So of course, if some components don't have maintainers and if ticket has no maintainer, no owner, you can go to regular meeting and ask questions about this ticket as well. So if you want something to be done, you need to ask about this because we have a lot of tickets more than 8000 and something can be easily overlooked. And this is why we need to trash them continuously. This is also a sign that we are evolving continuously and we can achieve great things if we can push some things forward. And if your court is not working, it's also a step forward because you investigate something, it has some kind of complications or side effects and this is already getting clear what needs to be done. It's also worth doing. If your idea didn't work out, you can also write about this on the ticket that I tried this, it's not working because keep in mind possible side effects. Don't change double equal to triple equal. It can be like really disaster because it can have a lot of regression side effects and you will be going around fixing other things. So even if it looks very simple, it's a very tough job to do. And if you have doubts, ask question. If for example you think that you should, you want to work on some ticket but something isn't clear or this ticket needs to have a lot of work to be done, you can go to regular meeting or just pop up in court chat and ask about this ticket. Before you put up so much work on this, you can actually check if it's worth doing, if this ticket is clear and something like this. Don't pour your heart in one ticket. Don't attach yourself to one big nice piece of work you've done because sometimes things are getting complicated and you can be very frustrated. So don't attach yourself to your court. It's not your baby. You need to like learn and move forward and be okay that there is no things which are perfect. We have 8,000 tickets. It's clear sign that it's not perfect but we are going to right direction. It's a skip point. And what I've told you already that if you think that things should be done but it's not going anywhere, pin people. Yeah, sometimes when you are the person who is pinned, but I'm a companion maintenance. I took this voluntarily so I know what I'm doing, what I signed for. So if someone wants to work on some ticket and will ping me, I will be glad to help because I'm there for this reason to push things forward. Thank you for your attention. And if you are watching this video, you can join our Contributor mentorship channel. And if you are not in WordPress Slack, you can join Slack first and there is an instruction how to do this.