 So, can you all hear me when I speak like this, or do I need to be closer to the mic? Closer? Closer? Closer? Is that better? Okay. All right, so our talk is Drupal.org changes to support new contributors and mentors. And if you want to follow along on your own devices you can view the same presentation that we're giving here, bit.ly slash do dash changes. And I'm Kathy, I'm the SCT, I work for Blackmesh. Black Mesh, Black Mesh is a hosting company and they do about 65% of their business is Drupal. I am not a cis admin for them, instead they pay me to mentor other people, work on core and travel to events and they do this as their way of giving back to the Drupal project. I'm also Yestiti on Twitter. Hi, I'm Alina. I work at the University of Illinois at Chicago where I am a developer and a system administrator and I'm also a contributor to Drupal 8. My Twitter handle is Chatteljaca in case you want to know how to pronounce it. I have a helpful pronunciation guide for it. So the people that we wrote the talk for, this might match with the people that are in the room, but we are thinking that the target audience here is people who can work on Drupal.org and maybe you want to know what would be, have a big impact if you work on an issue. So we are going to suggest some issues that we think will have a big impact. The other kind of people that we think might be here is people who are just curious about what's going on with Drupal.org and how is it getting better? So what we are going to do is we are going to run down some of the top Drupal.org issues that we think will remove some barriers to contribution especially for people who are new to contributing. We are also going to talk about some ways that Drupal.org has recently gotten better already. All right, so let me give you a little content overview. We are going to start with talking about what already works and what has recently gotten better. We are going to address a little bit the pain points that people have. And finally, we are going to focus on a few important issues that we think are important that we want people to start working on or focus on and pay more attention to. So why are we here? We want to increase communication about what is happening with Drupal.org. We want to get people involved with issues where the community can help. And we also want to concentrate efforts of people that work on Drupal.org on issues that will have big effect on improving contributor experience or CS. So who is behind Drupal.org? That mess of servers and cables. We have... Josh says they are neater than the cables look in the picture. Great. So we have the Drupal Association. We have TVN, Drum, Basic and OP Davies. We also have volunteers, people from the community. We are going to just name a few but there is a lot more. MLS, Sileffen, Newton, Coltrane and Dany Group. We also have a Drupal Software Working Group. And also some of you are here. TVN, WebChic, Drum, David Hernandez and the SCT. And if you are wondering what the Drupal.org Software Working Group does, it helps define the overall technical strategy for Drupal.org properties. And it also communicates the community needs to the DA staff. So how do you keep up to date with what is happening with Drupal.org? There are two important pages that you can visit to find out what has changed. They are basically change records for Drupal.org and infrastructure. And there is also, of course, we all have issues. So there is also Drupal.org issue issues. If you are wondering what those are, well, there are 41 projects for Drupal.org which I encourage you to look through and find. Okay, so let's talk about things that work. We have the issue metadata which is on the issue no page with collapsible field set. It was broken during the D7 upgrade but it's back working again really nicely. So as you can see up there, there is our issue metadata and also issue summary and relationships, files and cut it and committing. We have related and parent fields which help us connect issues together to each other and also to meta issues. So we have a better organization. So as you can see here, in the screenshot, you can find your issues by title and you can also add related issues. And what happens is that they are shown on the side bar with the parent issue, child issues, and if you add related issues, they will be shown as referenced by. We have a responsive blue cheese theme. Hooray. You can now view your issues on your phone or another mobile device, which is great. So let's talk about a little bit on the recent improvements. Profiles. Profiles are important because they give the kind of a face to all the contributors. And since last Drupal con we all got our own custom URLs which is great. We're no longer just numbers. We have user names. So let me show you what my profile looks like. So you can see my organization logo. You can see the Drupal events I've been to. There are some fields that I can add for my contributions and I can also select how I'm contributing, how I'm involved in the community. Account creation has improved as well. Here's a screenshot of the new user account creation. It has been redesigned and the help desk, the help text is more helpful. Once you create a new user account, you are automatically logged in. So you can just start browsing the site right away. The account is going to have a little bit of a limited functionality until you confirm your email address. And all new users have a little blue bar that says new, which is great because it kind of makes it useful for other contributors to note to be extra patient with the person or extra helpful. We also have, in addition to being a new user, we also have a community role for our longer time users, which allows them to automatically to confirm new users. So if you're working with someone and mentoring them and they just created a Drupal.org account, you can right away confirm them that they're not a spammer. Previously, this was something that very few people could do and now it's something that a lot of people can do, like thousands of people can do it. I bet most of the people in the room can do it. Issue comment attribution, something that Drew spoke about at the keynote, which is great. I tested it out just a couple of days ago. So I can attribute comments to an organization. The important thing to note, the organization must have an organization page. So, yeah. I created mine. In addition to attributing comments, project maintainers can also list supporting organizations on their projects. So you can select an organization, and I bet they have an organization page, and include how they helped. And automatically this will appear on the organizations page in the marketplace. And next, we have tag autocomplete sorting, which is a CTE favorite so in this improvement, our tags, both in the advanced search and in issue metadata, are now sortable by usage. So the high usage tags are at the top. So this makes it easier to use the right tags. Yeah, this is like the most awesome thing. All the typos float down to the bottom. You won't pick the wrong ones anymore. This is like so nice. And again, this is both on the issue metadata and also advanced search. The issue metadata location. So this is a pretty important piece of a page because it tells you the status, the version, the component, the priority. It gives you a lot of information about an issue. Now in a wider screen view, this information is located to the side. But in the narrow screen view, previously it was floated all the way down to the bottom. Well, now it's all the way at the top, which is great. Makes it easier to look up that information and hit that update this issue button. And finally we come to project governance. So having undefined structures and processes can be confusing to new contributors. And so we've made an effort to make explicit the things that happen with the Drupal.org issues and who to talk to about all the things. So there's an issue, number 245-7875, which is, I have a quote from it, a document that builds on the ideas that have been blogged about or presented at Drupal events by many people and attempts to clearly document how things are done and also proposes some incremental improvement. So what that document has is it answers questions such as, what is core contributor? What is a maintainer? What are the different types of maintainers? How are decisions made? Who are the Drupal core maintainers and what do they do? And it also answers a lot of questions that were asked on the issue in one nice page. Okay. So those are some things that worked, some recent changes, things that have gotten better. And now we're going to provide a little motivation for the issues that we're going to talk about that we're recommending would have an effect on improving things. So there's different types of people that try and contribute. One is Drupal users. They're already using Drupal. They're familiar with the site already and they're here about this contribution thing and they finally want to take that step. They're like, I want to do it. Some of the pain for those people is if they find the getting involved guide, that documentation about how to start contributing is confusing and not concise. The other kind of way that people think to themselves, oh, I want to help with something is different. They might be looking at a particular problem, Google finds an issue and on that issue, there's no help for them. You look at the issue and you don't know what to do next and sometimes the issue summary is vague. There's no background information on the issue and there may not be a clear explanation of what the problem is. It could just be one line on the issue and then there's a patch on the issue and you're like, okay, I have the same problem but I have no idea how to help this issue go forward. These people who are Drupal users, they don't know who to ask their questions to, so they may have some questions about the issue or how to work on it and they don't know who they can talk to. There's no cross-link to other documentation maybe about the general problem. Maybe this is a usability problem. There's no cross-link to documentation about, hey, these are the current thoughts about how we should address these things. Here's all the people that are also working on usability. It's all isolated and all by itself. Right now, in order to work on an issue, you need to know the secret tags that are involved. You need to know how to search for those tags. You need to know that there is another group about that topic, so you need to know it on groups.drupal.org. There is a usability group where people talk about things and you don't know that if you're only looking at the issue. You need to know that there could be an initiative, like a group of people working together on an issue and how to get involved with that, but that's not obvious. There are other kinds of people though that want to contribute to Drupal. There are people who are contributors already to other open source projects and they want to get involved with Drupal for whatever reasons. They want to see how it works. They start a new project with this new technology. They want to branch out. They came to an event with a friend and they want to just see what's going on. For those people, their pain is that they end up having to learn an older technology while they're trying to do something new. They end up having to learn how we work in issue queue with patches while they're trying to figure out how to contribute to this whole new technical thing that they've not worked with before. That's frustrating. They would rather use a Git style pull requests or they'd just rather use GitHub. They're also frustrated because they can't just edit in place to fix really simple things on the issue. They're like, I want to fix this really simple thing. There's a patch already. I have a really simple improvement. You know, you're on your phone. You just want to help, but you can't. You have to wait until you get to your computer so you can get cloned and do the whole thing. The way that we work on issues in our Drupal issue queues, we expose all of our faults. We upload a lot of patches and they stay on the issue forever. If you look at an issue that's existed a while, you might see 20 solutions that were not good enough to get in and one solution that is good enough to get in. People from other open source projects, I think in particular, are terrified at this. They don't want other people to see their intermediate work. They're not in their Drupal community. Our best people upload broken patches all the time. Then five minutes later, they're like, oh man, I can't believe I did that. Then they upload a little fix to it. Two days later, they're like, that was a terrible idea. I'm taking this in a whole new direction. When we see our best people do that, we've seen this over and over again. We start to believe in this culture of bravery and that we learn from each other. Other people from other projects, they are scared of that. Okay, so are some Drupal people. The other thing that they want to do is if a contributor from another that already has experience with other open source projects comes to our issues and they see a solution or they see that there's a suggested solution, like a patch on an issue, what they want to do is they want to do a nice code review. They want to help and give feedback, but they don't know how to do that on Drupal.org. They don't know about the secret Dread Editor and if they do find Dread Editor, they're like, I would rather have GitHub style code review tools. There's a whole bunch of things. Another group of people that have pain are mentors and these mentors are involved with new contributors and that's why they're in our talk because helping them will also help new contributors. Mentors pain revolves a lot around keeping a list of issues that they want to return to to help people they have already started a mentoring relationship with. Typically mentors are very experienced contributors and they have long list of issues that they're following. They have long list of issues that they are working on. They have issues like all kinds of issues, but they want to keep a separate list of issues that they don't need to work on themselves, but they want to come back to and that would really help because it would strengthen the relationship between people. They wouldn't just mentor somebody one time, but they could return and grow and really expand that relationship. Instead, what mentors do right now is they use browser bookmarks. They subscribe to all issues and use tags in Gmail to tag things and they would really like to have lists of favorites or just different lists of different kinds of issues on triple.org. Part of the problem with Gmail is the issue comments are difficult to read in the email format and if you list all your issues with a Gmail tag, you're essentially looking at subject lines in Gmail where what you really want is you really want to see like the results that you get on advanced search on triple.org, which is fantastic and really super useful. So they would like that. Some of the same things as new contributors bother mentors since they invest a lot of time in helping new contributors get around these quirks or they invest a lot of time explaining some secret information that really bothers mentors. Not because they are like, oh, man, I really wish I knew about Dreadator, but because they feel like they're wasting their time explaining these things to new contributors when they could be, if that stuff all just worked, they could actually be mentoring. All right. So the other group of people that some of these suggestions will help are just all contributors. They'll all benefit from it and some of these things are that everybody kind of experiences the pain of no matter what they are is they don't see any recognition of work that they do. So we have a lot of profile improvements, but one of the things that you don't see is when you work on issues, you don't see that show up on your profile and that makes people send. All contributors are affected by the fact that reviewers are not always credited for their work and reviews take a lot of work to do and a good review is worth so much. Because anybody who wants to work on issues needs to do things like find the issue that they once worked on or find the issue that they want to work on, searching for issues is really hard. So if we can help that, that will also help everybody. Okay. So some candidate issues to solve some of these pain points. One of them is issue 2332789 and it is reduce novice contribution differences and consolidate novice contribution landing pages, content, and blocks. And so this is our novice contribution guide. So if you come to Drupal.org and you're like I want to contribute and you're like oh look a getting involved guide and then you start to read the guide. It has a lot of landing pages and you end up having to go to a page to a page to a page to a page before you can find any like any action that you can take. There's also some sidebar blocks that are like getting involved sidebar blocks and those show up in multiple places and there's like two of them that are similar but they're different so like you can't find the thing that you're looking for. The content there is not very well curated. Some of it's old and we also have like dashboard information which is like getting involved. So we have like all these different ways like current content that we have and we just need to go through it consolidate it, make it simple, simpler, and more actionable. I used the word just. I didn't mean that. What I meant was this is a huge job and it's gonna take a lot of thought to do it but we really need to do it. Okay so you want to be you reach that get involved guide and you read it and you're like yeah I want to get involved so you want to start working on issues. Now before we can work on issues we have to find one that is suitable and that applies to our interests and our expertise and also we want to find an issue that other people care about because that's the way to move it forward. So here we have an issue the number is 1290740 and it is the title is how to label aggregate and expose issues, docs, forum posts, and groups to topic pages. This issue is important because it helps us find issues to work on by topic and it might indicate what is a priority right now for this topic and it could also be a mix of curated and automated content. You're probably wondering what does that look like. So here is a mockup that is posted on this issue and what it shows is there's recent activity from issues and from groups on the right hand side and the sidebar. There's a list of people and their expertise so that you know who to talk to. There is also a curated summary field and a list of links. We also have on the right top hand side topic metadata so really when you look at it what does it remind you of? For me it reminds me of meetup but for issues. Alright so let's say we found an issue what next? What we want to do is for a contributor that comes to an issue we want to show them all the relevant tasks for an issue that could be customizable per project. We want to indicate what tasks still need to be done and we want to expose instructions for tasks that need to be done. Well how are we doing this right now? Well you must know about Dredditor. You must know about this insert tasks template and then once you click that button you must determine which of this HTML that you have to read through is applicable to the issues. You have to uncomment it or comment it. Now when done you can delete it or comment it back we don't know that's not clear. So we have an issue 2013222 and the title of this issue is add issue tasks to project issues and correlate tasks with handle documentation. So instead of a manual process it should be easy to expose tasks and automatically link to handbook pages and this is something that will be helpful both for new contributors and also returning contributors occasional contributors and someone who just needs to have that information refreshed as they look on an issue. It will also help people who land directly on an issue from a Google search. So from this issue we have a mock-up here in which issue tasks are listed as a selectable multi-select field and once you select which tasks are applicable it would show up in the issue metadata similar to the way that we show issue tasks right now. There is another issue that has a slightly different approach to this. To resolving this it is 2193871 and the title is create an action block for short messages for users and visitors. This solution or this the work in this issue focuses on the next step in the process the general direction of how to address the pain point of not knowing how to move an issue forward. Finally we have issue 1393226 which is to encourage the use of the issue summary template and this issue falls under the integrate dreaded features into the O so that we wouldn't have to go and find out about dreaded and install the extension in order to use its features. The explicit issue summary can make it very clear for contributors what to do next with what steps to take. So what are the steps in this issue where it's moving forward? The last suggestion made was to use BU editor for templating. So if you're interested in this go ahead and follow this issue. Okay so you got involved you found an issue maybe worked on it reviewing is hugely important we can't fix anything without it and we should make it easier we can make it easier. One of the things that we can do that will improve experience for everybody is we can automate our coding style feedback this exposes it to people because they'll submit a proposed solution to issue that make a patch and then if the bots responded back with suggestions like coding style things that this patch added that was bad that comes back immediately so you don't have to go like oh I wonder if triple has coding standards and then go try find them in our docs page and then read through them all this would give you feedback like telling you like oh you violated these ones well that's the okay so the comment was the if we have automated feedback the language should not be too harsh and the cool thing about making it automated is yes we should make sure of that but also it won't matter as much because people take automated feedback from a machine much less personally than they do like so some contributor might like post up a proposal on an issue and then like three days later a human looks at it and they give them like oh you violated these coding standards maybe they do it even nicely and they it makes them feel bad also they had to wait a long time to get that feedback the feedback that the reviewer gives them may or may not include links to the actual coding standards so they can't tell whether or not this is this person's opinion about how the code should look or whether or not it's actual policy and if it comes from a machine the machine can be like oh you you know this is not the standard here's a link to the standard right so it solves it can make it just more consistent faster and easier to take because it's coming from a machine yeah right yeah so we have this habit sometimes and I think we all do it we do these things these drive-by driter reviews where we open up the patch we look at the code and like we can't help but notice these things we're just like oh this spacing is wrong and you're like you want to say something but you don't want to say anything and it's like really super distracting from actually looking at the solution and trying to decide if the solution there is good or bad or how to improve it or what kind of useful questions a reviewer could ask about the solution so it's good it's a better experience for the person who's submitting a patch and it's a much better experience for a reviewer because by the time they actually look at the code the person who submitted the patch has probably submitted like six of them already and totally fixed their style stuff because they got such quick automated feedback with links to actually how to fix it so it'll make reviewing a much better experience for people who do reviews and they could focus on giving better reviews we even have a we even have an irc factoid about like this kind of experience and it's called spinach so if you ask the irc bot spinach it'll give you a little think about the fact that it's hard when you're doing a review to ignore those coding standards things okay so another issue 2480515 this one is style code blocks so that 80 characters did not awkwardly wrap in comments on triple dot org issues so on triple dot org we do our discussion about the code in the same place that we discuss like the general problem so they're on comments and what we do is we'll take a hunk of code from the patch and put it in code tags inside our comment and then we'll discuss it there and when we do this the width of the field that comments hold is not wide enough to hold 80 characters and fixed with font and it makes it really super hard to read and I don't think this is a difficult issue to solve I don't know so this might be like a accessible thing like really if you've never helped with your product before and it doesn't like require any like massive I don't think changes to things so this this was just which would just be nice to um okay another thing about code reviews is our code review tools so there's a very long interesting well documented discussion this is not an issue so this is node 3 1 3 2 1 8 and its title is implement select oh that's a weird title it's implement fabricator components oh select fabricator components on triple dot org so some of it so um we had this history a long time ago we wanted to migrate to dot org from triple six to seven and that took a while and during that time we were feature frozen we're like we're not improving people that work we just need to migrate and then once we migrate we can add new features and improve things and so we did so somebody migrated it and we've been improving things and the rate of improvement is getting faster and faster and so what we can do now is go back to our three-year-old discussions and ideas that we had three years ago we had so many really good ideas and now we can be like oh we can finally implement that and there's so there's really old conversation about should we move to github and um and there's a lot of different reasons to do it but one of them is because people want a nice code review tool so an option and um instead of moving to github we could actually get a nice code review tool and there was some semblance of consensus that this might be a good way to go okay then we have the general problem of not knowing who to talk to who to ask questions um when you want to figure out how to help or how to help on a particular issue so we can improve that with issue 1854480 which is remove inactive maintainers from maintainers.txt now this is really update maintainers.txt title um we sometimes will keep main uh people listed in maintainers because we have a long release cycle right so we're four years so we might keep somebody in there who worked who was active two years ago as kind of like a recognition of all the hard work that they did um but we also need to identify who we can talk to right now about this thing and so if we update this doc which is in the code base um that will help because you can say like oh I wonder who's you know who I could ask a question to about the general um direction that uh accessibility is going in you can be like oh that you'd look it up in maintainers.txt and then there's a place and those lists of names that are there are accurate so this issue is about making that list more accurate um there's also two four five eight three three uh design discuss how to help people understand the formal structure of Drupal core so one of the things that um we mentioned earlier that is an improvement that we've already done is we have got this handbook page on uh Drupal core uh maintenance uh maintainers committers uh the different roles that we have how decisions are made so that handbook page is really good but it's still on a handbook page uh so what we can do is we can expose that information on issues so if you're on an issue that's tagged with accessibility maybe we could display there who are the people that you might talk to about accessibility then you don't have to know about maintainers.txt and you don't have to know about this handbook page and we put that information where people need to see it um there's yeah so we can expose some of that information that we put in the handbook page in a more actionable place all right we also have two two three two three nine three add an option to the issue search form to return the list of commenters instead of issues so we have an advanced search for all of our projects and you can be like i want to see 8.0.x issues in core that have the tag usability um and you get a list of ish a table with rows and each row is an issue and you can sort by like date so you can be like i want the oldest ones or the ones that have recent comments what would be really great is if we can have a similar page where you want to say 8.0.x issues in core uh that are tagged usability but instead of seeing the issues that result what you see are a list of people who are active on those issues and you could sort maybe you could restrict your search by date so i would like to see people who have commented on issues that deal with usability in the last six months and then you could sort that list by the number of comments that they have this will expose this organic information um not necessarily like who's in maintainers dot text because maintainers dot text is not always up to date and you don't always need to talk to a maintainer to know about the current direction of the project or to get your question answered but what you would like is to know like who the heck is active in usability right now and if you don't read all the issues in core and you don't know these people you know it's really hard and that's why sometimes working on an issue is easier for like insiders because they're like oh you know my issue got tagged with needs usability review uh or accessibility review i'm going to go ask so-and-so to do it but if you don't already know those people then you're at a disadvantage if you're trying to solve that and we shouldn't have this like secret information we should be exposing these things and we can expose them there's also the multilingual initiative does this a little bit they use the project rocket ship and they do screen scraping on drupal.org issues and they look for issues that are tagged multilingual and then they screen scrape to get the commenters user names and then they display all of the user names as a way both to thank all of those people and also people who have commented recently are a different font and people who have commented a lot are bigger font so you can look at that and you can be like oh these people are the recent people who are doing a lot of work in this area and it's really nice both as a thank you and a recognition and also as a resource for people who are new to know who to talk to and that type of information go really well on the topic pages that I mentioned before okay so we got involved we worked on issues we got them reviewed now it's time to get some credit giving credit is crucial in collaborative open source projects we give credit for patches and uploaded files but those are not the only types of contributions that are being made so in this issue two two three zero five seven nine um the title is policy no patch allow crediting reviewers and other non coders as first-class contributors we want to make it easier to credit reviewers in order to encourage more reviews and reviewers and to move issues forward so what could that look like well here's a a mock-up from that's posted on the issue and in it you see a drop down that in which you can identify the type of contribution that is being made so we can there are several proposals on what type of information should be in the drop down you can identify it by comment type whether it's a proposal a patch a review or issue management and then there are different contribution types or different topic topic areas such as accessibility testing documentation um in in both cases we want to the goal is to highlight the variety and importance of contribution types um on issues on the data all right uh so once you work on issues eventually what happens is you collect a bunch of issues that you worked on or that you're in the middle of working on or that you think you might want to work on when they get to a certain state uh so we need a way to track our issues and uh there are a lot of them so I work on core so not only do I have a lot of issues that I work on but there are just so many that I don't and um uh some of the things that um that would be relevant are personal tags improving search um adding a way to create a follow-up of an issue so that it knows that it's a follow-up there is there's two um issues that deal with possibilities for making lists of different issues right now you just you follow an issue or you don't um it would be nice if you could also favorite certain issues um that would create two lists though you have the ones you follow and the ones that are famous uh another option is to have a more generic way where you just you could just create lists and just have multiple of them and uh you maintain your own lists uh so there's two two seven one eight seven seven two two seven one eight seven seven which is allow per user tagging and issues that one's about like making your own lists uh there's also uh one that like has I think um better possibility of uh has more consensus and it's simpler this one is one six two one seven one four allow a bookmark and favoriting of issues without abusing the assigned field or issue tags uh and this is just the idea that you could have a favorites at least you would have two lists then oh and the other one that I talked about before two two seven one eight seven seven is um more complicated would also be pretty cool there's some things though to discuss about the direction of this like are your lists public or not so like if you go to somebody's profile page or if you know the secret url for the view that generates this thing um can you see what lists people are keeping uh and then the issues that are on them so right now like it's we can see who's following which issues so I don't necessarily know that we have a privacy concern with releasing this information because we're already exposing it in the advanced search thing you can put sct in the following field and you can see the issues that I'm following this would be elaborating that because you could see the issues not just that I'm following but how I'm categorizing the issues and which issues are in different categories so I think there's a lot of advantage here and uh at least not a privacy problem but it's definitely more complicated because you don't know how to present the information or how to update it this is this is complicated okay so we talked about all these different issues um how do we work on drupal.org well there's a handbook page that explains how to do it uh basically you get a uh development environment with a copy a sanitized copy of drupal.org now what would be really great is if the d.do projects um issue views or on issues uh would have a link to that handbook page to make it even simpler to find or faster to find um we should also join IRC channels uh drupal-infrastructure and drupal-contribute and finally drupal.com has just started so we want to give uh a few session highlights um that are coming up for sessions that you might be interested in related to drupal.org tomorrow we have at one o'clock the pinpoints of learning and contributing in the drupal community with uh kgo and fgm at 215 we actually have two sessions that we want you to go to I don't know how you're gonna do that but the first one is issue workspaces a better way to collaborate in uh drupal.org issue views with tvn and mixologic and uh the second one is how do we encourage repeat contributors contributions to drupal core with uh hussein abbas and david hernandez right so the one about issue workspaces that's about making a get workflow for drupal.org and on thursday there is the drupal.org infrastructure team meeting at 1 p.m. and also there are ongoing conversations um in the drupal that in the mentoring group on groups uh that drupal.org uh so uh if you're inspired to work on some of these things some of them are complicated some of them are more simple uh but you might also want to just try your hand at making any change in drupal.org but that's kind of scary to do by yourself and not always obvious luckily we have sprints we have sprints during the week and on friday and also on saturday and sunday but if you're new to contributing or to contributing to drupal.org friday is your day uh you can get an orientation early in the morning with a workshop to get you set up with tools and explain how issue queues uh work and there are mentors there and there will be uh groups sprinting on many different topics and one of the topics is improving drupal.org and tatiana will be leading that sprint and she has uh probably some issues in mind of things that are relevant to drupal.org right now it probably doesn't align with my list um but not i mean it's not one to one is what i mean um but there are still things that are relevant to drupal.org that she thinks uh have an actionable thing to do on them and uh there and you can work with other people who know about how to work on drupal.org and and work together um it's going to be a much better experience doing that on um like fixing one small thing on an issue that there is already some work on the tatiana thinks is worth working on right now like that's going to be a really good contribution experience for you like pulling up one of the issues that we've mentioned here and going home next week and being like i'm going to solve this that is not going to be a good contribution experience for you but like you might want to follow the issues that we mentioned read like the background on them uh keep up to date on them maybe try some other issues uh that are about fixing drupal.org and gain some experience with that and then maybe come back to some of these or you you you don't even necessarily need to work on them you might just want to know that they exist and be like if i have a you know if i want to give some feedback on something maybe something somebody else will work on it at least you know the place to give feedback on these times but friday nine o'clock in the morning it goes to six uh there will be helped to get you involved everybody if you know what your blue is and you've used it before we have things for you to do and it doesn't have to be about drupal.org so i'll be doing the core mentoring bit uh there'll be uh contrib things happening and it'll just be a super experience really like really it'll be great uh all right so um we started a little late um because of the picture taking and the keynoting um and stuff so i think we still have some time for some questions and there's a mic right in the middle of the room um also uh if you could please rate our session um i think you uh you go to the event website for that um and here's a short link to our session page there it's bit.ly slash node 439 because that's the node that is our session um so please write comments questions microphone um we can also answer questions afterwards so if that's it then thank you all for uh coming um that's the end you've been the nicest audience we can put a link to the slides on the session page but it's also bit.ly slash do dash changes um and it's uh it's a it's a get repo in reveal in the drupal mentoring github project um so if you want to like update the talk uh and give it somewhere else you can do that or use parts of it um there's also some other talks in that repo that are like mentoring related and we're trying to like collect them there so people can reuse them or make suggestions to them so that's uh on github that's drupal mentoring pre-select any musical tracks thank you for coming i'm really like impressed at the number of people that are in the room i think there's like 20 or so which is like really super awesome thank you so much thank you all the space ones during our mentoring day isn't it what that get workspace ones during our mentoring day no no no those are tomorrow no tomorrow is oh wait tomorrow is Wednesday yeah oh yeah it might be it's not going to be boring it's not going to be boring it's going to be amazing thank you for coming my track my track chair i'm here to support the worker of of things thanks well you know works really hard no i did not make right now what thank you what's your name kelly kelly thank you for coming i will come on friday oh is this your first next uh make sure you book your plane for like monday monday yeah because like friday is awesome and like it's just it's very low stress and it's really it's really great i got that from jam yeah hey thanks for coming thank you for coming we're in we're in decent shape and actually alina said that she would help out like there's that thing about moving the the um photo credits like right now when i move the box it goes down and i don't suggest it moving it to the tops of the state like if you could fix that that would be super awesome yeah i'm like um i think a real question is do we want like there's a bunch of text on these slides we want to do anything with those yeah we should go through it and look at it again you're coming we have lunch now oh you know what i think i might have to do and then okay so my next so i know i have to write i don't know okay so i have this right now and then i wanted to go to oh there's also latin american lunch together uh and then second one and then i don't think i have any obligations but then later today at five jeremy's giving us the i talk which i might get supposedly that greg is giving us quite a lot of i go to i saw him feel they're tapping and i don't know what else he was talking about he's also good to me yeah and her candy box is he here yeah uh after that he said he was on israeli time and didn't see it oh after that is the oh yeah have you ever seen the recording of this person i haven't heard it's like on my to-do list to do all right i will find you this is like the most amazing talk ever given to group of yeah yeah that was this study oh so tonight it was like there's the woman in drupal thing uh which i'm most interested yes i might just i want to make my talks a little bit interesting uh and then it's back in that party tonight so i'm so no it's well it's in the it's in the west so maybe maybe maybe we can do it right after you're sending me all of the pictures in which kathy's um yeah i don't know i put yours too i put right i can skip it and we could meet it's western