 Okay, hello. This is documentation team onboarding for two GitHub roles. These roles are issues coordinator and issues reviewer. So, you can find here in Docs Handbook. Can you see this? Should I zoom in or is this visible enough? I'd say you can zoom in a bit. Okay, that's good. Good. So, this is Docs Team Handbook. We have Get Involved, Team Roles, and Non-Project Roles. So, we are going to talk about issues coordinating and we have issues reviewer. So, here you can find what our responsibility is, how to do the work, and some onboarding sessions you can watch to get familiar with documentation team and everything they do. However, this can be outdated very soon or completely wrong because I just wrote this by things that I've been doing. Maybe we will find better workflows, so don't be afraid to propose changes or, you know, maybe propose another role, whatever. This is not set in stone. This is just something to start with. So, the things are happening here, GitHub.com, WordPress, documentation issue tracker, and issues. This is where everything is happening. What you should be familiar with is, first of all, labels. So, we have different sets of labels. Here we have a WordPress version. Then we have project-based labels like Advanced Administration, APIs, Blocked Editors, Advanced Administration. Let me show you. We go to documentation for developers. This is Advanced Administration Handbook. So, the label applies to that. Then we have, we saw here APIs. That's for Common APIs Handbook. So, that's what we mean by project, by Handbook. Blocked Editor is usually referring to this, even though Blocked Editor has their own GitHub repository and issues there and documentation, but sometimes people report issues in our repo as well. Code reference is for this one, which is shared with the core team. Then we have bug, like something wrong with displaying docs or images not showing. So, it's not really a problem. It's not information in docs. It's just something that is structurally wrong. Content review is something that started with reviewing end-user docs and removing two technical information that is not for end-users, removing from the docs. So, it started there, but it can be applied to any content review. Contributor Day, we create issues for every contributor day with some onboarding documentation and list of tasks that we are going to work on. So, this is the label for those issues. Contributor Documentation applies to these contributor day, but also applies to other things, like when we have to update this handbook that we have, or anything that is concerning documentation for contributors. Like this we are making right now is a contributor documentation. That's what we apply. Dev Notes is when the WordPress release happens, so Dev Notes should be written and published. Some of members of the documentation team are reviewing those, so that's happening as well. Developer documentation is umbrella for all of these that we have, even though we don't maintain all of these handbooks. We don't maintain WPCLI, REST API, coding standards. As I said, Block Editor has their own repository, so that's kind of shared. Teams is shared with the Teams team. Code Reference is a hybrid handbook, so parts are maintained by the recommendation team. Parts are generated from the code and WordPress playground is the new one coming from another team, so we are not maintaining that one either. But most of it is maintained by the recommendation team, hence the developer documentation. Duplicate, if we get a duplicate, but it's really difficult to know with a lot of issues when something is duplicate, but when you know it is, just mark it. Enhancement suggestion for improving the existing docs or improving the whole handbook, if there is a discussion about it. External links, we have a policy that we are trying to complete and apply for reviewing external links in documentations because we want all links to be actually beneficial for end-user of the documentation and not to be marketing or commercial, non-existing or pay gateway or something like that, so we want to review all the external links. Field Guide goes together with Dev Notes. Field Guide is post-published during the WordPress release. It's a collection of all Dev Notes and some more documentation, what's new in the release. Good First Issue should be an issue that is easy enough or simple enough for new contributors to contribute. We had a lot of Good First Issues that are too complicated, have too many tasks, so right now I'm working on restructuring Good First Issue. It should be only one task. It should be possible to complete without anyone's help within 30 minutes, so that means that it should have clear directions about how to do the task and only about the task, not explaining all the handbooks and all the documentation and how theme is structured because that's just overwhelming. So I'm working right now on restructuring all that to have a real good first issues so people can be not scared when they try to contribute to the documentation. His screenshot is when issue needs screenshot, but it has already and we will see on the second page there's a labeled needs screenshot. Help Wanted was not really successful. We probably didn't define it very well and like you just with Help Wanted on every issue, we need help with every issue, so I'm not sure about that one, but we have it. Help Hub feedback. Help Hub is a end user documentation. So if you go here, here is end user. This is our end user, but I just click on category and here, for example, this is the article for end user and I'm not logged in. So what we get is comments on this end user. Here are comments and these comments are not publicly displayed. So this is actually the feedback for this article. How can it be improved if something is missing, if information is not good, if layout is broken, whatever. Any feedback with this article, anybody can post here and those comments will appear here as they are in WordPress install. It will never appear here and this is the feedback that occasionally I'm collecting. I also need someone for that but that's another role. So from time to time I go through all of this. Sometimes we have spam like this one, this is spam. So we did that but the actual feedback, I take it and create issue for each of them so you can see how it looks like. It has the URL of the article. It has the username of reporter and quoted the content of the comment. Then we have high priority. Internal tasks are usually used for something that we need to fix in our repo, something to create some new workflow or when we have a triage then we label those issues with internal tasks, invalid when it's not invalid. It's not for us. Medium priority meta is when something is wrong like layout is broken. So something that we or colors are wrong or something like that that is actually built by meta. So that's how we label that. Migration from codecs, we still have some documentation at codecs that is not migrated to other places. Maybe we don't have the right place for that. Maybe it's outdated. Maybe it's a lot and we still don't know how outdated it is. So some parts are waiting when we are migrating that to WordPress. We label migration from codecs. Then again, mix.davnode comes with field guide and davnodes for WordPress release. Mobile app is the newest one. It's a end user documentation but for mobile app. Needs discussion. This one is as well unsuccessful as Needs help. We have these 19 for centuries now and this is probably something we should discuss about and maybe change it somehow. Needs screenshot, you saw the one that has screenshots. So this screenshot. New document is when we have a completely new document that should be written so it's not updating the existing documentation. This is mostly happening with end user documentation when there's new block or some new feature that doesn't have its own article yet. Performance. I created this one for performance documentation that is mostly now moved to advanced administration but some places are still in end user documentation. Plugins is for this plug-in handbook. Question. When you don't really want something to be created or maybe you want, you just don't know, you want to start discussions. So this is like Needs discussion question kind of similar. Recategorization project. This was created by Estela when she was doing the recategorization of end user documentation. Self-assigned is when you use our automated workflow and you actually assign yourself to the issue. That's when this is applied. I will show you all the workflows and all the organization that we have but we will get there. Then we have these status labels. So we have to do in progress, review, ready to publish and done. And this is actually the kind of most important for someone who is going to be performing the role of issue coordinator and reviewer because this is what you're going to search. Then we have themes which is for this handbook but these are mostly maintained by the teams team. Tracking issue was created at the beginning of the repo. In my mind, it is the issue that contains a lot of other small issues. This is the place where you follow the progress of a bigger feature. However, it's not used everywhere like that so I'm not really sure anymore. I don't really use it unless there is one big issue that contains a lot of other issues. Triage is when we create issues summary and tutorial review. I have no idea what it is. This could be, I don't know, something to find out. A typo when the issue is really, really small and you can fix it right away like in a couple of minutes but you actually need access to the documentation to be able to fix it. User documentation is for the whole end user documentation so it was here for all of that. And one fix when something is really not for the documentation team or it doesn't apply or it shouldn't be like when people come and give us a completely new structure of the documentation and say you should do it like this, like we are not. And workflow user story, this is something that I added because I'm working on better workflows and trying to understand each role coming to the repository and using like someone who is completely new and someone who is a season contributor but also someone who is maintaining the repo and someone who is just reviewing something or working on building the workflows behind. So we need to find all the workflows that work for all which is difficult but because many different user roles are using this repo and we want to make it as simple as possible for all of them and to enable them to just do the work not to do manual stuff that shouldn't be done or are just time consuming. So that's what these user stories are. So these are the labels that you should be familiar with and there was supposed to be a documentation about that in our there should be documentation about it in our handbook but I didn't have time to write maybe someone will after this video. So now when you know the labels and you know this is like these status labels are the most important because when I want to work on something and maybe I want to work on something that you know if I want to start working on something I don't want to step on someone else's toes so I want to know that these issues are not even started they're not in progress they're not I just want to start working so when I open this label these really need to be the issues that nobody is working on. Also you would need to be it would be very helpful for you to get familiar with this search with advanced search features. So if you want to label to search label status to do but you also want to search like 6.4 you would add label 6.4 and then you get this but maybe you don't want to work on good first issue because you want to leave that to new people so you say minus label and then you get you know that then maybe you want just high priority then you'll again add or maybe you want to find the label you to find issues that are created only by you maybe you just want to work on your you can find them here and maybe you know hold on maybe you want from specific date maybe you created a bunch of issues at the contributor day and that contributor day was perhaps today or you know the 6th November and you want to say created and then you start with year 2023 minus 11 it's year month and day so today there were no created or maybe you updated a bunch of issues so we want updated and there should be a different date let me try to find something where updates were actually made maybe here so these are open issues created by myself and updated on 25th October so use this this is very helpful tool and you can see here advanced search syntax so you can see the documentation for all of it you can search by username by many different things I found the date and labels like filtering labels very very useful so those are the labels now I want to show you the workflows so here we have github and we have issues template and workflows first let me show you issues template this is something that appears when you want to create a new issue so these are all the templates that are created here and you can change them there or you can create new ones I created these for for good first issue so when you open with first issue for alt attributes you have everything ready all you need to do is change the label here the WordPress version here add the title add label for the WordPress version and put the URL to article here and everything is ready so you have all the documentation how to create how to check these alt attributes also for headings for screenshots for videos so this is something to help you when you create new issues and to help other people you know to have everything there it's consistent if you want to change something on this first issue change it here so this is how it looks like there's a table but this is the template and if you go to edit you will see this please be careful with formatting this because it can become if it's not formatted properly it will not be visible there and it won't be used but everything that is showing in the issue itself is here so you can change that when you are done changing but just make space so you can commit change create new branch new full request and it will create new branch so uh why doesn't give me option let me refresh yes so here you create full request and once it's merged I have ability to skip the review just because it's easier and the template is updated it has as you see here another space so that's how you would edit template I suggest you go there and read all of these you will find it's very easy to create one and very easy to edit one what is very helpful for example here we have screenshots so we already have labels that apply to this issue once it's created so you don't need to you know think about that and it's the the title is almost ready everything here is ready for people so it's very it's simplified for you when you create issue you just put what is different and that's it it is just a couple of things and then we have workflows these workflows are automatizations and for example here are all actions that happen when someone comments on the issue so here we have issues so when let me just see here's one so what happens when you type review like this slash review in the comment then what will happen the label status review will be applied at the same time if there is status in progress on the issue it will be removed here remove label here add label if there is status to do if there is status done it will be removed so only status review will be applied so what we need to add here there is a new label status ready for publish that needs to be added here as well then we have when someone comments slash assign so at this moment it needs to be to have a label to do and also to not be assigned to anyone else so I need to change this and I'm not sure yet how I will change if the other person is assigned but this should definitely be removed like this status to do this was just a starting point test and I think it's successful I think we should have this because github doesn't allow everyone to assign them it allows only people who are contributing to uh who are members of documentation team and who are contributors to this repository so they can assign people and they can change labels so I think this is very helpful for people that they can self assign that and you see here this label is applied so what happens when issue is not assigned to anyone else and it has status to do and someone comments slash assign what will happen uh this status to do will be removed and it will be a status in progress and uh this issue will be assigned to the author of the comment so this is very helpful I want to work more on this and do more work close with that and also we have just these two keywords for now assign and review if found in comments things will happen then add to project this is also very helpful so when you create issue from this repository and you apply for example 6.4 label it will automatically be added to 6.4 project now if you go the other way around if you create issue in the project it will not have these labels so this is why it's better to create issues from here now some of you don't care about this because this is important only for people who are working on WordPress release or in the squad and they are populating these projects but we have other projects as well so we have our handbook project where we apply contributor documentation label so when this label is applied there is a project where this issue will be added automatically also we have issues added to advanced administration once you add advanced administration label then for general and user documentation when help have feedback you saw that one from when I create from comments issues and user documentation is applied then these issues go to general and user documentation it doesn't matter which version then we have add to 6.1 6.3 and 6.4 so you can also add here you know more automatizations for this what is important this needs to have a unique name so you see it doesn't matter it will not have appear anywhere actually it will in actions but it doesn't really matter how you call it it should be something that you understand and it has to be unique then you give the name to this job and you just copy paste all of this and then you change here you check which label it needs it needs label 6.4 so you check you don't run all these tasks to all issues only if 6.4 label is found then you need URL to the project and this is URL to so it's not like hidden anywhere it's the actual URL to the project here it is so you just take that one without these views so when you click on different tab you get the views you need just a URL to the project and I okay this one copy paste this is the talking that I added to the repository and it's just copy paste and then here again you have to say this label now when you have multiple labels like here no it's here help have feedback and user documentation if I want both of these labels to be applied as a condition to be added to the project then I say label operator and but if I want either of these then I would say or and that's it um now we are taking more time than I expected but never mind the label when assigned so here when you assign someone automatically status in progress will be added and status to do will be removed I had other workflows here but it was just messing up I need to think through the logic here label when closed so when issue is closed all the other status labels will be removed and status to do will be applied status done will be applied label when labeled this is interesting right so when we have APIs or code reference or plugins or themes so any any label from the developer documentation project then we will have applied developer documentation label so because people usually forget to add that one but then we don't have the right number of all of that when new issue is created this is what we do we create comment that says heads up WordPress docs issues coordinators that are you folks you will be pinned when new issue is created so that you can check the issue and label them properly so this is already in work but nobody is getting notifications or someone might be getting and this is a notifying team based on issue labels so when block editor is labeled fami gets notification when has screenshots it's fami and akira user documentation again both of them when plugins then there is mike because mike is a rep for plugins handbook and fami and akira are reps for and user documentation then we have themes and reps for themes documentation so you see the the logic here when things are labeled we ping the people who are in charge for this advanced administration have yet status review docs reviewers again you folks will get notified when status review is applied so those are workflows again i suggest you go there read it's fairly simple if you're a developer it's fairly simple to create new workflows you just have to know the syntax and there is documentation about that at github it's really detailed it's up to date it's good documentation so you can learn stuff and how to automate things if you have any ideas how to improve things that's how that's where you can do that so now when you are familiar with the repository how it works what's there what's the work for issue coordinator well you know things are happening here people add more issues people add comments but nobody knows that nobody goes there unless they're pinned and sometimes even when i'm pinned i get a lot of pins i don't have time to go there so what you can do here you can find you know sort by recently update perhaps and do this once a week so go through or you can set the dates here and you know go through issues from last week go and see open each of them see if it's in it has right labels maybe it's it says it's in progress but person commented like i'm done ready for a view you know and they don't know there is the workflow there so you have to change the label basically you want to make sure every issue is properly labeled and in proper column in project if you have permission now i don't know how that works from here because permissions at github are rather complicated and it gets even more complicated when you involve projects but if this is if this said review and here it says to do then this should be changed you know basically github issues coordinator make sure that all the issues are properly labeled and in state where the actual status is so when i go through them like this i don't think i don't open this like to do and it's actually ready for review or something else i when i want to work on this or on any issue if i say that if i search for status to do i want them all to be status to do because it's very i saw it on many kudrums their days it's frustrating for people they're like oh good first issue and they open and it's miles of tasks or status to do and then you know a lot of things already done and this is wrong like we have self assigned and status to do so my workflow failed and that should be changed so we found another bug for issue reviewer what you want to find is uh go to labels and find the review label and preferably they are all labeled properly so these are really ready for review we can change the label to make it like ready for review or something like that if in review is not clear or is confusing maybe i don't know and then so some issues need two reviews so you can be if you don't know about this like okay maybe you don't know about this topic but you want to review just to make sure like everything is here it has screenshots what was the task there should be a list of tasks and you check that all the tasks are done so there are screenshots this is the content change there are no typos uh this is the also this is wrong all the titles should be in a sentence case so you should be familiar with uh with style guide as well a good thing is we have highlights so you can go fast through things that should be um applied uh basically we have the most uh errors with the titles titles should be sentence case not title case uh so when you see something like that you know you can comment like can you please uh do this task as well or just comment like hey this is ready for publishing our first review is done and then you label it properly when there is ready for publish or you know still in review we can add another label for first review second review something like that so those are the tasks let's just to move things forward and to make sure that no uh issues are stailed you can also search here and sort them by the least comment the least recently updated so these are updated like the the further ago and you can go and go through them and see what's happening there what should be done how to move things forward so that's basically it uh do you have any questions so do we need to have some additional access of the GitHub repository uh yeah yeah probably um I I can add you like collaborators and teams let me just see so I can add you here or I can add you to a documentation team there's also docs reviewers team that I created there there was a time when I couldn't add people here that it had to be approved but there is now a place where I can add people by myself so we don't have to ping anyone else and I can add you to the documentation team or docs reviewer or both uh or here like I don't know exactly what is the difference um but if I add you to the team then it is zero so you just have to ping the team you don't have to ping the specific person uh and you will have access to uh actually change labels and you know move things forward and and assign people if they don't know how to assign themselves uh or the label doesn't allow them so you you will get that and you will have uh you know all the access that you need with that okay is there anything unclear or I mean I know there's a lot a lot of a lot of points will come when we start when I start working on it yeah there's a lot and I even didn't know how much is there I thought we will have enough for you know 30 minutes but this is something that was built over a couple of years so and when you don't know all those things it seems complicated but uh now we have this recorded it will be uploaded to uh WordPress.tv and uh it will be available so I think once you get the hang of it it's just a matter of habit of coming once a week spending a couple of hours you know going through the issues and and uh if more people do that then it's less time and we have updated issues and uh over time it will be less work but maintain consistently yeah okay well if there are no questions then we can wrap this up I will upload this when once it's converted and feel free to watch it again and if you have any questions uh or anything maybe you don't want to do this after this session maybe you thought it was something different maybe it's too much I don't know uh so uh the next steps is you think about this and let me know if you're still interested and uh if you have any questions if you have any suggestions please uh send them to me in in Slack or you know in Docs channel wherever you find them find me wherever it's easier for you um just add them and we can continue from there if you're not interested in this no hard feelings you know it this is something that I I've been doing and you know other people partly have been doing from time to time uh but we don't really have a person who is dedicated to this and it would be very helpful for everyone if we had a few people dedicated to this and it will move things faster so that's it take your time think about it and you know just let me know if you're not interested just let me know I'm not interested in that yeah I'm ready for the I'm ready for the issue coordinator okay good good thank you uh well we will then talk um I I feel it's a bit I have to watch it uh two three times because I have no idea about the programming site yeah so we can let you know that's fine that's perfectly fine thank you so much for your time uh and yeah we will move things forward from here thank you thank you thank you bye bye