 recording. All right, so today we are going to talk about github roles and workflows for WordPress documentation theme. I am at WordPress.org, so let's see, let's go through a geography first a little bit. So when you go to make WordPress, it should work, okay, make WordPress, and you find documentation. And here is a blog. The pinned post is where all onboarding sessions leaves and leave and you can go through them if you're just starting out. And we have agendas and summaries for meetings and everything else that is related to the team. And then we have handbook. And in handbook, some parts are out of date, some parts are up to date. We are trying to keep it up, but it's not always possible. And here in Get Involved, you can find team roles. This is the latest addition to the handbook. So we have roles per responsibility. Basically, there are three types of contributors. Everybody is contributor. Then we have project reps. These are people who are also members of the team. And they are in charge for different projects. So the documentation team has different projects that we are working on. And team reps. These are people, these are not team leads. These are people who basically know everything that was happening in the team. And today we are going to talk about non-project roles. So project-based roles, you can compare them. You can find them here. So each of these are projects. And non-project roles are facilitating meetings, issue triages, writing meeting notes, GitHub issues coordinator, issues reviewer, onboarding coordinator, and contributor day facilitators. So today we are going to talk about GitHub issues coordinator, issues reviewer, and issues triages. This is basically because we are talking about issues at GitHub. That's why we are going to talk about that today. But basically, this is just facilitating a meeting. So let's go first to issues triage facilitator. You can find here responsibilities, how to do this job, and what are recommended onboarding sessions. So for GitHub-related roles, recommended are all because GitHub is a place where we work on all documentation issues. So here we have a link. You can find it from here. But you can also go to, if you want to longer write, you go to GitHub, and then you search WordPress, and then you find organization, or you just go here. No, it's better to go to right. We can go there. And this is WordPress organization. And here you start typing documentation. And here it is, documentation issue tracker. Now, this repository has basically nothing here. This is not the place where documentation lives. This is a place where we work on documentation. So here we have some contributions, contributing documents, license, readme file. And here are some workflows that are connected to this repository and some projects. So the purpose of this repository are these issues. And any issue with documentation documentation at WordPress.org, which has many places. Here, if we go to this documentation, now everything can be found here. This is end user documentation. But then we have developer documentation, which can be found here, and also here. And here are handbooks for developers. So that's a two major parts of documentation and user and developer documentation. And also everything that you saw here, this is contributor documentation that everything has to take care of. So all of that, when you find the issue with that, you report it here with documentation issue tracker. We have a list of labels here. And from here, you can click on the number and you will get all the issues labeled. Now, if you want to do a multiple labels, like, let's say I want block editor, but also just for 6.1, then what you can do is label and 6.1. And then you will, oh, it's not, sorry. And then you will get, so that's a little tip that you can't really find anywhere except in GitHub documentation. So this is the geography. Also, here you can find projects. So some of these issues are placed in a project, so it's easier to work with them. For example, we have projects for documentation for WordPress releases. And this one was for the most recent release. So this is how it looks like. And you can add there any issue or any PR from any GitHub repository under WordPress organization. So that's geography. And now let's see what the roles are doing. So every two weeks, we have issues triage. And what does that mean? We just go through all of these issues and try to triage them and make things move, make people work on them. Because you often forget that there are new issues, that there are some high priorities. So the point of triage meetings is to go through priorities and see what can be done there to move things forward. For example, in WordPress 6.1 here for end user. Oh, we have here end user high. That means high priority. So you just open the ticket, see what's happening. Does it need to be reviewed? That is everything completed. But basically you just by leading, facilitating the meeting, you just copy link to it and post it in our Slack channel. Like here, where is docs? Here, you post it here and then see who is responsible for that, what to do with that issue. So you don't really have to know how to work on that. You just have to communicate with project reps to see what's the priority. So here are project reps and you can find them here in the theme. So you contact those people and see what's the priority for their projects and what they want to be mentioned in triaging issues meeting. The point, as I said, is to prevent stailing and to move things forward. If something, if an issue wasn't touched for a month, then it and it has been assigned to someone, you should just reassign it to no one or find someone who is going to work on that. But something needs to happen so that we just keep things moving. We will never have everything up to date because we don't have enough people. And it's just the nature of documentation. You can't really have everything always up to date. And that's okay. It's not pressure, but let's just keep things moving. So that's for how to do that job. Here is the list. And if anything is unclear about that, then just ping me in Slack or wherever you find me and or just open issue in our repository and say, this documentation is not complete. Let me go back. There is a team roles. There is this open issue where I have been working on documentation about the roles. So if there's something missing or isn't clear, feel free to post here or just open new issue. And that's the triage facilitator. Issues coordinator. Now we don't have this anyone doing this so far, but there is a need for that. And you can read it here. But the long story short, we need someone who is going to monitor all new issues here. And when there's a new issue, you open it, you read what's all about you find out which project it belongs to, and then you label it. So this plugins is for project for this one handbook about developing plugins. We also have themes and let me go back. Okay, two labels. So here you see, we have labels for WordPress versions, then advanced administration. This is new handbook that will live here here. But it's still in developing APIs. That is common API's handbook block editor can be both this block editor for developers, but also for end users, which was okay. So here we have end user documentation and there are block editor articles. So this label covers both of them. Bug, it's something we don't really have bugs, but something is not working. So it's not really error in documentation itself. It's something just doesn't work as expected code reference is this one, contributor documentation and contributor day, those are for contributor documentation for this handbook. And for contributor days, when we organize them, developer documentation covers all of this. So you get the point, there are labels for projects, labels for WordPress versions, labels for workflows like help wanted high priority, internal tasks, medium priority, migration from Codex. So that could be both end user documentation and developer documentation, but we are just migrating things from Codex. So there can be different labels, what what GitHub issues coordinators should do is apply those labels in on the issue. And we have a workflow where when you apply the label here, because the plugins label was applied, then GitHub action will mention the project reps for plugin handbook. And so they get notified to check out that issue. Also, this is not me commented. This this is another workflow. When any new issue is created, then docs issues coordinators would get notified. Now currently we have no people here. There's only me and I'm getting notification by or comment made by myself. But when we get people doing that, then you would get notification to check the issue and to label after that, when the label is applied, automatically, some other people will get notified by that. Also, this role should welcome and assign contributors. So the way we assign contributors to issues, I don't know why is that if someone tells you, I want to work on that issue. And this person is not here in participants, you can't really assign them. And also they're not in WordPress organization, so you can't assign them, you have to have them here, which means they have to make a comment, hey, I want to work on this. So when someone says, hey, I want to work on this, you as coordinator would assign them and maybe, you know, make a comment like something welcoming and who is the project reps, where to go, which videos to watch, or maybe we can, you know, make that automated. But that's the point for coordinators to really just coordinate issues, to give them labels, to make sure they go to correct people. And if someone wants to work on them, to welcome them, give them information where to go, to start, who to ask for help, and those things. So this is really, you know, going into depth and knowing every part of WordPress documentation. So this can be very complementing to the role of issues triage facilitator, so you get better idea of and better image of how the repo looks like. And at this moment, and you can, you know, see what our priorities, what project got ignored for a while, and what should be done and mentioned. So that's issues coordinator. Again, we have some responsibilities. Now this role, as I said, no one is doing this. This is a new role because we notice that we don't really go to GitHub and check unless someone tells us, oh, you know, I open issue there, or someone really mentioned you, and you get the email. So we need someone who is going to do that, which means this is what I wrote here is just, you know, an idea how this role should work. We don't know if that's reasonable. If that's, if that should be split to two persons or maybe is not enough for one person or something should be added, we don't know. So this is just the idea of a role, and we will fix this. So nothing is set in stone, not for this role, not for any role. So we can fix this, we can change this once people start doing it and, you know, seeing flaws in it and maybe getting new ideas or new workflows and things that can help everything go smoothly. But the point is someone to watch on new issues and to really make things flow, to label things and just from the beginning of the life of the issue that we can start working on it because we just keep forgetting, you know, before this GitHub repo was created, we had problems because people were reporting issues on different places in the different, there was no system for reporting issues for documentation, and it was overwhelming. And then we had to fix that problem. And we fixed this with creating this new repo and it was central as placed and people could just go there. So we didn't think of another problem. And that was that someone needs to go there and watch it. So we were just like, oh, okay, now nobody is, you know, poking us in Slack. So everything's fine. No, it's not fine because nobody's going there to watch it. So this role is for that. And the last role is issues reviewer. So you noticed maybe here in this board, we have columns like need first review, need second review. So this is mostly for end user documentation, because those are articles, developer documentation is not that frequently updated as end user documentation. And we have with new blogs, we always have new pages. So when when someone is writing that, we need first and second review. And what review should cover, like for some, okay, this is tracking issue, this is not really a good example, but let's say template part walk. So you will see here, these items that should be done. And because people who write documentation for this, they might not always have permissions to check these items that they have done. So we kind of agreed on that person who is reviewing the created content that should go to documentation, they should, you know, check out all of that and make sure that everything is covered. So this is someone who should be familiar with our style guide. So here we have covered everything about how to write documentation at WordPress.org. What does it mean, what it should have, what it shouldn't have, there are some examples. So someone who is familiar with that, and also who is familiar with documentation articles like other articles, these are categories, but here we can see how article looks like. And especially block articles have a specific structure. Let me find it here. There's toolbar and block settings, but I have a better example. For example, text blocks, okay, paragraph block. So there is a structure, there is always a video here how to use this block and then block toolbar explanation of everything in toolbar, then block settings, which is inside bar and there is change lock. So someone who is going to review all these issues should be familiar with all that structure with the style guide and also with workflow for GitHub issues. And when everything is reviewed, they would have enough access to move things to ready to publish and also publish changes and move it to done. So those are three roles that are tightly connected to GitHub. I don't know if I have missed anything here, but you can read it all at documentation. And as I said, this last one issues reviewer is mostly connected to end user documentation. So these are recommended on boarding sessions. And of course, this one will be added there as well. And that's about it. So if you have any questions now, please feel free to ask. Okay. I guess I was, is there anything in chat? I can't see chat. I can't see chat either. I'm trying to find it. I'll just ask here. For the GitHub reviewer role, are we reviewing things for the first review or the second review? Probably the second review, right? Well, either, because it's a good practice to have different set of eyes and as many as possible on article before it gets out. So it can be the first and the second review. It doesn't really matter. Maybe the starting point could be the second review. Maybe the first review could be done by someone who is more experienced. But still, you know, you can gain experience by some mentoring and getting mentored by more experienced members. Sure. So that's about it. I don't know if I covered everything. If things are overwhelming, they are. And that's okay. It always sounds much more scary than it is. And you don't really have to do everything. You can do just a little part and then, you know, share role with someone else until you're ready to do more. Or you can do several roles if you feel you're ready. You can always find help in Slack channel. You can always ping me or anyone else. And, you know, we can do another session if you have another set of questions for these roles. That I see now that you might have missed as well, Milana. Mm-hmm. Which is a good place to look and review what was actually done. Is this or is the result live to see on the site? Can you please repeat? I didn't hear the first like the label or the column, sorry, where we're looking now on the page. It's done a good place to look and review what was actually done. Is this or sorry, is the result live to see on the site? Yeah. Yeah. So when it's ready to publish, it's basically everything is covered. So here we have So as you see, the workflow is not followed. This was supposed to be done by a reviewer to check if all of this is inside the updates. So here we have screenshots, then we have a little bit of text, then another set of screenshots. So it's kind of a mess. But someone who is going to edit article knows what to do with that and where all of that goes. So when it is in ready to publish, someone with access to dashboard will do all the edits. And once it's published, it will be moved to done. So when it's done, you can see all the changes in the article. And every issue, especially for end user documentation will have link to article if it already exists. And all the info, like what needs to be updated for 6.1 version, what is left to be updated for 6.0, what is general. So what is that every article has to follow? Like all screenshots are relevant to latest version, images have all tags, videos are up to date, headings and so basically accessibility things and following the style guide. And all of that can be seen here so that all is updated. Does this answer the question? I'll put it in the chat. Great. Thanks. So thank you to be okay. Any more questions? Okay, so I guess we are done then. And for any additional question that you come up with or anything else, feel free to post them in Slack and we will work on that. Well, thank you everyone for your time. And see you soon in some other session or maybe just on meeting. Thank you. Bye.