 All right, good afternoon. Has everyone had lunch, hopefully? Good stuff. So my name is Chris Dark, and that's how I appear on drupal.org, Chris Dark, and on Slack. I'm one of the core mentoring team, and we try to help everybody get up to speed with doing contribution. So during these sessions, there's people wearing these green t-shirts at the back of the room there. You can see another mentor. And anybody that has any questions, you can put your hand up. He'll come along and help out. There's some microphones here. If you've got any questions, we'll sort that out. And yeah, so welcome. As I said, my name is Chris. I speak English and Spanish, so if you have questions in either language, feel free. If it's in French or Japanese, can't really help you there. But yeah, I'll do what I can. First point of the session, we use Slack for a lot of the communications in drupal. And so if you go to drupal.org slash Slack, you can join the drupal.org Slack group, the Slack workspace. And within that workspace, there's a lot of different channels for lots of different types of work. So there's a, for example, there's a Composer channel. There's Documentation channels. There's Initiatives channels. The one that we'll be using for people doing first-time contribution will be first-contribution. So if you join that Slack channel, that would be great because then you can talk to other people and get going with finding out about what you can do to contribute. That means that the general contribution channel, which is hash contribute, doesn't get too noisy with everybody talking at the same time right now, because there's a lot of people suddenly hitting the channel at the same time. So if you can get onto drupal.org slash Slack and sign up and get onto the first-contribution channel, that would be awesome. That's the first point of call. And now I'd like to talk about what we're going to do during this session. So we're going to cover why we contribute, the ways that we can contribute, and how you can actually start doing some of these contributions. We're going to cover the issue queue for some contributions. Not everything is in the issue queue. We're going to cover merge requests for code-based contributions, tooling and documentation, and Drupal part, which is a tool for code-based contributions. So who is this workshop aimed at? Who am I expecting to see here in front of me? People who are new to the world of Drupal maybe. So those of you who maybe have just been introduced in the last few months to Drupal or the last year or so, and you've never actually gotten deep in with it. I'm also looking to see people who've maybe been working on Drupal for 12, 13 years. And they know everything about it, but they've never actually had any chance to do some contribution. Or people who've been contributing already, a fair amount, but they've only been doing it in one form and they were looking to find other ways in which to contribute. So effectively anybody. Anybody is welcome here and can hopefully find some new ways to contribute. So that's what we are going to do. So why should we contribute? What's it about and why do we want to do it? If you depend on open source, open source depends on you. This is a big tenant of open source is that it only survives because people are helping out, people are contributing back to it. If you are just consuming these products and all you do is consume them and everybody else is thinking like you, oh somebody else is gonna do something, nothing ever gets done. There has to be enough people, enough of a critical mass of people helping out and fixing things and testing things for these projects to move forward. Your contributions are valued. People actually really appreciate people coming in and testing and updating and posting screenshots and creating bug fixes and things like that. It's something that is not gonna go unmasked. People will notice. And because of that you will get what you give and more. You will learn skillsets that maybe you didn't expect you would have, you will learn about intricacies of maybe some documentation area where you learn about something that you never read about before or you're doing some translation and you actually end up finding that it improves your language in that language that you're doing translation in. There's a lot to be gained by working in Drupal and learning about the systems. And also it does make you a more integral part of the Drupal community. Before I started doing Contrib and I was basically just a consumer. I installed Drupal and installed the modules and I worked for some agency that didn't want to do any Contrib and I was just there in the background using stuff. And I never even went to Drupal cons and then I started to go to Drupal cons and meeting people and as soon as you start contributing and you're talking to people about these things then you recognize them from their name tags and you get to talking and you make friends and you become part of the community rather than just a user. And that is really awesome. So yeah, benefits of contributing is it makes you feel good because of some of these things where you help out and somebody's like, oh, hey, thank you so much for doing that. Yeah, it's a good feeling. It moves the project, it moves it forward. So things that maybe are stuck in testing forever that you help out testing and suddenly next year that has moved into the latest release and you've got it on production. You get Drupal street cred. So there is issue credits that you get for working on issues, but also just in knowing people, getting to meet people you get again to become part of the community and through that it's kind of cool if you know half of the Aaron Winburne of World Winners. So the more you contribute, the more you learn, right? So again, if you are working on testing something that you've never looked at before, through the testing, you might learn all about how it works and then the next time you've got it coming up in a project, you might be like, oh yeah, I know this. So it's very valuable. And one of the things that we always want to make very clear, you do not need to be a developer to do contribution. This is not about development. This is about giving back in any way that you can. And there is a ton of ways. One of them is code. So you can be a huge asset to your project, to the project without ever writing any code. So how can we contribute? You do want to have a Drupal.org account. So if you go to Drupal.org and sign up, you can get a user there, and that will allow you to do a lot of contribution that is, for example, updating documentation on Drupal.org. Pardon me. Translations on localize.drupal.org. You can give back financially by getting a Drupal Association membership, for example. You can also help financially with module maintainers with Open Collective and Patreon. And also sharing your knowledge. So for example, going to Drupal camps and creating sessions about things or just sitting down with somebody at work and talking through something with them. So all of these are ways that you can contribute which only need your Drupal.org login. There is other tasks that can be found that don't require the issue queue and the mentors in the mentors contribution space can show you. But most of the things that we have as tasks attract in the issue queue. So with the Drupal.org login and the issue queue which I will go into in a moment, you can do things like issue triage which is where you go through the lists of issues and you check, oh, is this still a bug? Is this still relevant? Is this still a novice issue? Or maybe it's actually become a bit too complicated. Does this have the right description? So on. You can test existing merge requests on issues. So for example, as somebody's created a patch for something and you can go and check, is this actually doing what it says it does? Has it fixed the issue? Testing experimental features. So for example, field layout which is in alpha. Going and checking, does this experimental feature still work and is it gonna be great for core? And you can put some feedback in and at some point these experimental features move from experimental to core, hopefully. And that is all based on people actually testing and providing feedback. There's feedback on any sort of changes that are proposed that you can create screenshots and post them up. So all sorts of types of testing that can be done there. And then, for example, marketing materials. So there's a lot of information that needs to get out there about conferences, about camps that requires people with good language skills and the image skills to create graphics and text and stuff. So a lot of work in that area. Even things like for example, YouTube videos about these sorts of sessions that we create videos for them. Don't have time to work on these. Yeah, somebody with good video editing skills. Again, something that might be tracked in the issue queue and it's not code related, but it's very important. So as I said, you do want to have a Drupal.org login. If you don't have one, go to Drupal.org slash user slash register and sign up. If you only sign up today or you've only signed up in the last few days, you might get a message or you probably will get a message saying that the user's kind of blocked. It's not blocked, it's just waiting for verification that you're a real human. And it's just to stop people from creating random accounts and spamming things. So if you create a user and then you can't access certain things or it comes up with a pop-up at the top, you can reach one of the mentors and some of us have access to be able to verify you as a human being. You just have to prove to us you're a human being and then we can update your user. So if you sign up now rather than at the end of the day, then we can get that done while we're still here. So that's a good first step after getting your Slack account set up. And so yeah, one of the areas that I mentioned that we can contribute to is the documentation. There is a ton of documentation and there's a ton of it which is out of date. It's no surprise, it's just like at any workplace, documentation tends to take a back foot. So if you go to Drupal.org slash documentation, you'll find all sorts of different documentation types. There's curated guides which are quite purposefully written and have a lot of review process for Drupal users, for evaluator guides, for local development guides. Here's the Drupal Wiki which is a bit more free flowing and people can add to it a bit easier. Where you've got guides for all the versions of Drupal since seven basically, development guides and so on. And then there's API information which some of it is auto-generated from code and some of it is reference documents which are written. And some of this stuff can be just edited right there on the page. So for example, the Drupal.org documentation which is about the site and it contains information about user accounts, content guidelines, marketplace guidelines, so on. You can edit it right there on the page just like any Wiki entry. But yeah, curated guides which are the ones which are fairly formalized. They do have an issue queue where you can post in patches or changes to the guides. So if you're looking for curated guides because you're trying to follow some process and you see there's an error or something's wrong, you can create an issue about it and post up a change to this and it will get reviewed and it'll get updated. And as I said, if you're going through community documentation, you can edit it right there on the page. So obviously, don't go and edit something and just strip out everything and put ha ha ha, you know, like you will get blocked if you do something silly like that. But it does mean that you can go in and make changes very easily and you just need to justify what your change is, save it and you're done. Again, if you don't have your user verified yet, you won't be able to do that. So if you want to be able to do that, you need to get your user verified. Another area of contribution is translations and we have a ton of different languages set up but a lot of them do not have very much text that has been translated properly. So if you go to localize.drupal.org, you'll see a big long list of all the languages and you can see percentages of how much has been translated. There's a lot that have very little translation and you can then join a team for that language and there'll be conversations there about what you want to translate and so on and you can post up translation files for these things. They're basically just text files that contain snippets of text that are replacing something in English with something in that language. So that's a great area to contribute if you have language skills that you want to share. The Drupal Association, if you go to Drupal.org slash association, you can become a member and that membership is really useful for the organization to be able to use that money for running these conferences and other things. So that is another really important way of contributing. The experimental features, as I mentioned, don't worry too much about that URL, you can just Google Drupal experimental features and you'll find it, but that URL, that'll take you to a list of current experimental features and you can go and test them out, see if something applies to something that you're working on, maybe, oh yeah, that would actually be really useful. Let me try this on my site. Obviously, we recommend you don't run them on production sites, but it's something that if you're testing it, at some point, you may be able to get it into core and then it will be on your production site. So you can also look at the past experimental features that are now in core and see what sort of things have been through that process. There is a contribution guide and in there you can find tasks that you can accomplish within a certain amount of time. So let's say you've got one hour to spare somewhere, you can look up small task of documentation and you can find in there little tasks that somebody might post up. It's not always as up-to-date as the issue queue that we'll be going into later on, but you can look in there for things that you can do to help. So it's another area where you can look for contribution. After I go and talk about the tools, we will be asking you to go through to the mentored contribution space and the dynamic of what we do there, basically we want people to be working together. We don't want everyone just feeling isolated on their own, we want everyone to be feeling like part of a group. So ideally, if you can go and join a table and one of the mentors there will guide you to a table if you have a specific interest about something. So let's say you want to do graphic design, there'll be a table working on logos, for example. And when you're working on an issue together, the idea is that everybody will post their name on the issue. So it'd be like, hi, my name is Chris D'Arc, I'm here at Pittsburgh 2023, I'm working on this issue for the next two days. That lets anybody else who looks at that issue in the future know, oh, this person was working on it, but that was two weeks ago, maybe they're not working on it anymore, oh, they are working on it right now, I better not take that issue. It also allows people to get messaged when there is progress to the issue, because when you post in the message on an issue, you will get notified. And then after putting your name in on the issue and reading through the issue, everybody in the table will hopefully decide on what to do. So maybe one person will be loading up the site on SimplyTest and another person will be checking what it is that the issue is to then identify it on that site and another person will be trying to figure out, oh, what's it meant to look like? Okay, it's meant to look like this. Let's bring up a screenshot of the before and after and then another person will be writing up and text about what they found when they did the testing. And so everybody together is working on the issue and posting something without everybody having to do the same thing at the same time. So splitting up the issue into parts so you all get to try something. We don't need you to accomplish a ton of work, we just want you to see that it's very straightforward to do. So in the future, you're like, oh yeah, I've done contribution stuff, it's not complicated, it's straightforward. So during the time that you're doing contribution, we also want you to post in the issue, oh, I'm still working on this, we've loaded up the site, we found the issue, for example. Oh, I'm working on the graphics and I've got half a graphic ready but it's still missing some styling, so on. So that people who are looking at the issue elsewhere, they can see, oh, there's still work happening on this issue. So you first put in some information about yourself and say you're working on it and then as time passes, we want you to keep the issue moving, keep it up to date. And then after the event is over, when you go home, we really want you to just keep working on it. We don't want you to lose momentum on this issue. So if you're able to, we want you to carry on and get the issue through to review and test it by the community and out there and then you've got some code or you've got some graphics or you've got some documentation stuff set up that you've worked on and is now in call, it's pretty cool. So we really want you to have that momentum so you keep that optimism, that enthusiasm going. So I keep talking about this issue queue and you're like, oh, what is the issue queue? It's basically like JIRA, it's a task list and it allows us to track everything that needs to get done on Drupal Core and on all the Contrib modules. So every single Contrib module will have an issue queue and Drupal Core has an issue queue. But we are only really looking today at core issues because we don't have the bandwidth to look at all the issue queues. We're just looking at the core ones. In an issue queue, we can report an issue, update, charge issues, so like, you know, do cleanup, find things that aren't relevant anymore, create merge requests, which is where we make changes to code, provide feedback, like, you know, this works, yep, checked, put a screenshot, do testing, you know, go through and make sure that the change actually does what it says it does. And the issue queue for core is found in drupal.org slash project slash issues slash drupal. There is a link to it from the download and extend page. But there's also a bit.ly link here, which is bit.ly slash drupal dash novice, which will add a novice tag onto that issue page filter. So I'm just gonna go to that now. And let me see, sorry, I was poking around with stuff before. Right, so this is the issue queue. And there's tags that you can apply on the issue queue. And the tag that we have for people who are first time contributors is novice. They just mean, it just means give me novice issues, which are issues that we've determined are likely straightforward and easy to work on for first time contributors. They might not always be the case. Something might have been marked as novice in like another conference, and then a year later it's become a bit more complex. So sometimes you look at an issue and it's not so straightforward. So we also do issue triage, where we find ones that are suitable for a conference. So in this case, we've got the tag for Pittsburgh 2023 also applied. And I changed it to is all of, because if you choose if one of as the default, it just gives you either one of both. So in this case, these are issues that are determined to be good for first time contribution during this event. And there's a lot of other filters that you can choose. You can specifically find things that need review. You can choose different types of categories. So like support requests or feature requests, different versions, different components. So let's say you like good at migrations, you can get some migration system or any sort of different parts of the site. So that is the issue Q. And within that, we're gonna look at one of the issues. So let's take a look at this one here. This one is on the Claro theme. It needs work and so is the internet. No, I'm just joking. It's actually much better than this morning. So the issue itself would have information about what is going on. Sorry, I was joking about the internet, you're fine. Okay. So the issue itself will show what we need to do on the issue. So normally there is various different parts to that. Let me just bring up this slide. So what will the issue need to include? It should normally contain a problem or motivation. So problem, this text isn't rendering properly. The graphic, the color is wrong. Or motivation, we would like to add this feature onto this component. So then there's a proposed resolution, which is, oh, I think if we change the color to this, it will resolve this issue. Okay, remaining tasks. Let's say somebody's already made that change, but it needs testing on multiple different browsers. So remaining tasks, test on Chrome, Firefox, whatever else, post screenshots, and write some description about what you found. Okay, so those are the remaining tasks. UI or API changes, if there is any. So if you're changing something within the API or UI that often has a bit more implication, just what those changes are. And then screenshots, if they help give some context, or in the case of an issue that you've seen, that you're reporting, like, oh, here's a screenshot of where the text is broken or the color's wrong. So going back to the actual issue that we were looking at, this one, it has the steps to reproduce, but it doesn't really have all of the context that we would like. So if you actually look and you go to edit, and you, sorry about the screen, by the way, it's happening there. If you edit the issue, and you go down to the issue summary, you'll see there's a description of the issue summary field. And that issue summary field will have a link, sorry, a page about what to put in that issue summary. And so here there's a template, for example. So this issue summary template contains, that's right, like, yeah, the problem motivation steps to reproduce, proposed resolution, et cetera. You can actually copy this template and paste it into here, and then fill in the gaps, and then you've given it a bit more information. So let's say you know what the steps to reproduce are, they're here, but you want to maybe, you need to add the remaining tasks, then you can figure out what the remaining tasks are, put them into the description, and save that. And then that itself is a form of contribution. That is some of the stuff that we do during issue triage. We go through the issues and we find, okay, here's an issue, it's great, but it's lacking context, it's lacking information. Somebody's gonna go and hit this issue, and be like, okay, I'm gonna spend 40 minutes trying to figure out what is going on here. So by updating the description, you are contributing by making it easier for somebody else, or for yourself later on, to work on the issue. So that is something that, in this case, for example, does need some work. So actually, one of the steps that you could actually, one of the remaining tasks that you could do on this ticket is put into remaining tasks, needs better description, and then you can actually resolve your own issue. But if you go through, you can see there's lots of comments from people, so there has been people working on this in the past, and actually it looks like what is happening is there is a solution that's already been made, somebody's been commenting about it, so this information down here at the bottom probably needs to be condensed into a set of steps at the top for people to work on. Then on the side we have information about what the state of the issue is, so in this case needs work, the version, the component, you have all of these tags, so for example this is part of the bugs that smash initiative, and all of this information is to help you figure out whether or not this issue is something suitable for you. Oh yeah, sorry, let me go back to that slide for a sec, sorry to that screen. You'll see here that these different entries that say dot patch on them, these are patch files which are the old way in which we used to track changes to the code base. So if you go into there you can see, remove this line, add this line, remove this line, add this line, it's not how we do things anymore, but it's how it has been for a long time. So nowadays we would like people to use merge requests and we'll go into that, but if you see these entries here, these patch files, you can use a patch file and apply it to a site, so you can use simply test for example and apply a patch file into it and it will bring in that change and then you can test it locally. But what we want to be using is issue forks and merge requests, so if you see this button here create issue fork, if you click on that it will fork the whole Drupal core for a personal version just for you which you can then make changes on and then request those changes to be brought back into the fold when it's ready. So yeah, as I said, we now have this new workflow available, merge requests, and that is something that's used on a lot of different version control systems. So just as an aside for those of you who don't know what Git is, it's a version control system, it allows you to track changes to content or files and so you can have multiple different versions of a thing and then you can merge those things together. So in the case of Drupal, we have a Drupal core and then when you do an issue fork it creates a whole new version and then you make changes on that version and then when you're happy with those changes or other people can also work on that other version as well, when you're happy with those changes you say please merge this back in. So that's called a merge request. So when you set up a merge request on the issue it'll appear there as a merge request on the issue and it'll have the version of Drupal that it's ready for and it'll have automated testing that will run and make sure it can merge in and then people can actually spin up a test environment from that and then somebody, if it's all approved and has been said yes, this works can then merge that into core and then it becomes part of core. But yes, this is what I was just talking about. You create an issue fork, you create a branch in that fork, you make changes with a meaningful and commit them with a meaningful message and then with that you create a merge request and if everything passes it's merged in. All of this stuff, the mentoring team will show you next door, so it's not something you need to figure out right now but this is what we are doing in the process. So the tools that we use for doing this sort of stuff we're gonna go into them now, Drupal.org slash tools is where you can find information about all these tools and we've got various different tools for doing testing. So as I mentioned, you might have a merge request or a patch on an issue. So somebody might have made an issue which is like again, there's text issues, we can't read this text properly at this size, this text needs a different color on it. So somebody maybe made a patch and that patch is just waiting to be tested. So your contribution effort is gonna be to test that patch and make sure it does what's intended. So you can go into simply test.me and you can load up the version of Drupal Core that is on the issue itself. Generally be the latest dev but sometimes it could be a different one. And firstly, you would load it up without the patch applied and you can then see, oh yeah, okay, I can replicate this issue. Pardon me. Just give me a sec. So you can check and see, yeah, I can replicate this issue. If there's no screenshots there, you can make a screenshot, post it up. And then within simply test, you can then also apply the patch file. There's a little section there for applying the patch file and then rebuild the site. It builds the site on the browser for you. Sorry, I've been talking too much. And then once that loads again, you can then repeat your test and see, okay, that text did appear better. I can see it now. But maybe there's a spacing issue that was generated by that fix. So okay, here's a screenshot. It's definitely better, but it still needs work. So then you can update the issue summary. You can change it from needs review to needs work and say, this is why it needs work. And that is a form of contribution. Awesome. If there's a merger quest, you can also spin up live previews. So a merger quest will appear like this and it'll show that it's all green. It's past testing. And there's a view live preview at the bottom. If you click on that, it will again spin up a version of Drupal with that merger quest applied on the browser. And again, you can follow those steps. So the one thing about the view live preview, sometimes it doesn't show up. If it doesn't, there might be something that's causing tugboat to not be able to build a preview. So you can just ask one of the mentors. A few years ago, I was looking at it and there was a glitch that they needed to fix on the server somewhere. And it was just a momentary thing when I happened to be looking at it. But yeah, if you don't see view live preview and it's all green, you can ask somebody, there's a tugboat channel on Slack. You can message on there as well. And if it's a suspended, that just means it's asleep because they don't have these servers, these versions running all the time. If nobody's looking at them. So those are two ways in which we can do testing of the changes. And then for making changes, there's various different tools that we can use. The one that we're going to be looking at now is Drupal Pod. But we also have local development environments that we can use. There's a thing called DDEV with QuickSprint, which is a way of getting a very capable development environment on your machine going fairly quickly, which is why it's called QuickSprint. But today we're going to look at Drupal Pod. So Drupal Pod itself is a full development stack with VS code or PHP storm, XD bug and everything like that, all built in on the browser with live preview on the browser. So it's pretty cool. And it gets people going very, very quickly compared to installing Docker and everything. So if you go to github.com slash Charles slash Drupal Pod, or I think if you go to drupalpod.com, if you search for Drupal Pod, it will show up. There's a read me on there, and it'll go through all the instructions. There's a Chrome or Firefox extension, which will work when you're on an issue page. So if you go to an issue, for example, in this case here, and I've got this little extension here, and I click on that, I can choose a branch. In this case, there's no issue fork, so there's no branch, but I can choose a patch. And then I can run that, and it will spin up a version of Drupal on my browser. This one's timed out, so I'll get it going again. And yes, one of the things when you load up the Drupal Pod extension, it will ask you for authentication. And it has various different options. And one of the options is GitHub, and another option is GitLab. I know Drupal is on GitLab, but it needs GitHub for authentication because technical issues. So you will need a GitHub account, which is free. So please sign up for GitHub account. That will allow you to authenticate your Drupal Pod instance, and then you can get to work with a full development stack on your browser. As I said, it has VS Code or PHP Storm. It has public and private site previews. So within the group that you're working with together, you can spin up the site, make a change, share the URL for that preview on the Slack channel. Other people can test it out and take a look at the change. You can also share your workspace. So if you're doing some coding, but you're not sure how to continue with that line, you can share your URL, and some of the others can carry on coding on that same instance on their browser. There is a setting you need to check for SSH keys, and it's covered in the Getting Started with Drupal Steps. So make sure you do read the Read Me on Drupal Pod. But yeah, it allows you to do the full development without going away from your browser. We had somebody at the last Drupal Con running it from the iPad, which is pretty cool. So yeah, it's pretty neat. Again, the Slack channel that we use for all the communications around first-time contribution is first-contribution. So if you go and get yourself onto Slack and get yourself into that channel, any questions that you've had about this during the next few days, you can post them in there. We'll be helping you out. And that is where you will communicate with people at the table. So once you go through to mental contribution, we will obviously all be wearing masks, and it can be kind of hard to talk across tables while wearing masks in a noisy room. So sometimes it's just easier just to work on the chat. So for every issue that's been worked on, there's going to be a thread, and you can just join the thread and type in the thread. And there you can share URLs and messages, and it's a bit easier than trying to yell. So yeah, please do get on there. And then all of these topics that I've talked about, they're all available as videos. So if you go to bit.ly slash drupal dash contribute, that will take you to the videos for these things. They might be a bit out of date. Somebody might want to contribute by updating YouTube videos. If you want to, let me know. But yes, those are the videos. And yeah, that's it. Thank you very much. So any questions? Okay, I'll wait for the microphone because it needs to be recorded. Thank you. I have one personal question, and then I need to be confirmed. But my other question is about patches and forks. I know in our general usage, we will come across bugs and discover a patch, try it out, and it's not accepted or merged or anything. We're just using the patch in the, well, this seems to work. Let's throw it in there and see what happens. Can you do that in the new way? Where can you use a fork to branch before it's been merged to get ahead of that and fix your bug before it's really ready for prime time? Yes. Cool. That's the short answer. The long answer is if you go into the actual merge request, you can actually put dot patch on the end of the merge request. I'm just trying to find one and it will generate a patch on the fly. So just trying to find one right now, but you can then use that URL to use for your composer patches if that's what you use. So in this case, for example, so yeah, if you go to the commits and you type patch on the end, it generates a patch for that. So yes, is the answer. And there is a bit of an effort to if you find an issue that has a patch and you go, okay, there's a patch, but it'd be nice to have a merge request. You can take the patch and apply it into a merge request. You can create an issue fork, apply the patch, put in the comments and say, I'm converting this patch into a merge request and create that. And then it will make it a bit easier for people to carry on contributing on that issue because they don't have to create extra patches and into this and the other, which is a bit tedious for anybody who's done that. So it's like, so yeah, that's definitely good question. Thank you. Any other questions? No? Okay, great. So after this, you can exit the whole and you can walk towards the light, through the light, through to the other side and then you'll find, I think Greg's over there and he'll be directing you to the mentor contribution space if you wanna do that. And there's various different tables for different topics and the mentors will be there helping you find something to work on and get going and we'll be there as well once this closes up. And yeah, thank you very much for coming. Cheers. Oh, now that's the URL for the slides if you want.