 Welcome to the first contributor workshop. Let me, for just a minute or so, I'll let me tell you about this workshop a bit. So this is a workshop that happens all the time in Drupal cons. It's the first time that this one is happening in Drupal South. As the name suggests, this is basically to help people who want to contribute to the Drupal community, to the Drupal ecosystem, but they are not able to. So, yeah, first time, first time's a charm, right? Okay, let's go, let's start. Just an introduction, my name is Sushi Gurg. I'm a technical manager at Salsa Digital. I have 24 plus years with open source web development. I started with Drupal when Drupal was 4.3, gosh, I'm old. But yeah, I've been a developer, I've been a senior developer, a tech lead, a solutions architect, a mentor, a trainer, you name it, even a project manager. Okay. She says that when discussed. I was forced to do a scrum training, a scrum certification, scrum master, yes. That was ages ago, I will not tell how many years ago. Okay, so a bit about the agenda. We'll be talking about who you are, why should you be contributing, types of contributions, then we'll be talking about some issue Q 101 and the kids of the issue Q, then a very quick intro about merge requests and tooling and documentation. And I will leave enough time, actually we will have a lot of time for Q and A because this is a 45 minute session, I thought it's a 30 minute. So we'll have a lot of time, if you have questions. Even before we start, some general hygiene things. So Drupal South Code Sprint has a Slack channel. So is everybody part of Drupal Slack? If you are part of Drupal Slack, you should go to that particular thread and that's something it will be helpful for you to do the Code Sprint tomorrow. And generally for first contributors, there's also a channel called First Contribution. You should be going there in case you have questions, in case even if you want to see what should I work on and you will have a lot of healthy discussions and that will really help you get started. And a little bit about the dynamics of the minted contribution, how does it work? So it works in a way that there will be many tables, there will be people who are mentoring. If you find a table, join a team. Teams will mostly be arranged by topic. So it can be something like bug smash, media, Drupal 10 porting. Look for a team or a group which is working on something that interests you and join in. Find something to work on. Find an issue. How do I find an issue? Let's try and do that actually. Not very, so this, I'll just show you this particular page. So as you can see, this is the Drupal.org project issue queue, right? And this is a really, really, really great tool for you to get started. There are some, I'll just go to advanced search here. Click, it's not click, happened. Yeah, okay. So when you go to advanced search, then it, of course, everybody knows what an advanced search is. But if you're a one-time contributor, they're the first-time contributor, not one-time, sorry. I hope you're not a one-time contributor. So if you're a first-time contributor, you want to start with something small. So issues are tagged very appropriately. So you can probably search for something like, novice, you know? And then you might start finding issues which you feel that, yeah, this is good enough for me to start with. Also, for Drupal South, there are actually issues tagged with Drupal South. So these are probably the issues that people will be working on tomorrow. I've also heard from the mentors of tomorrow's code thread that they want to work on the issues that have been tagged as postponed maintainers need more info, and that is something you can actually find here. Not closed. These ones, and when you filter them out, you'll probably find issues that people are working on tomorrow. So this is a great way to start off with. Okay, coming back to my... Okay, so find something to work on. Now, you found an issue, you feel that you'll be useful in that. The first and the foremost step that you should be doing is update an issue. Assign ratio to yourself. The reason why this is very important is that we don't want people to be working on the same issue when then doing the same issue. Why duplicate the other person can work on? So that is the first thing that you should be doing. And if you're on a table and people are working on the same issue on the table, on the table, I'm sure the mentors will help you in that, but you need to decide what everybody will be doing. So for example, somebody could be testing the issue, the other person could be creating the screenshots, and the third person could be creating their own local development, or things like that, or making a patch to say, no, this is not working, I'll create a new patch. So that is very, very important that you do that. Once you have done that, the next step is you have to keep the issue updated. What do I mean by that? So you found an issue, let's say you found an issue which already had a patch on it, and you tested that issue. It's very important that you have tested and let's say it didn't work. You have to update the issue and make sure that you say, excuse me, this didn't work. These are the steps that, but don't post something like, this did not work for me. Please don't do that. Nobody likes that. This did not work for me because I followed these steps. These are the screenshots. This is a result, that's why I did not. Or if you're saying this did work for me, again, just work for me, no, please don't do that. This did work for me. These are the screenshots, these are the steps I followed. The result, and that's why it worked for me. Another thing that you need to about the issue updates is that each and issue has a status. So once, again, for an example, there's an issue which had a patch and it was ready for review. You have gone through, tested the patch, it works great. You have put in all your details, commented, put in your beautiful screenshots, yes. Edit the issue and mark this as RTBC, reviewed by the community. That is super important because that's when the owner of the module or core or they will look at it and they'll say, okay, this patch works. Let's try and analyze it for them. So keeping the issue updated is very, very important. And last but not least, I already covered it. Don't be a one-time contributor. You're contributing tomorrow great, but keep on contributing. You don't need to wait for an event to contribute. You can contribute from anywhere and everywhere. So keep on contributing even after the event. Oops, I pressed the back clicker. Okay, so who are you? Who here is new to the world of Drupal? Great, how much time you started with it now? You're not new. Oh, okay, okay. I'm sorry. Another thing, so yeah, you're new to you, but I do understand you might be not comfortable with Drupal, but you're not in that contribution space yet. So yes. So when I look at the audience here, I'm pretty sure you have some which are new to the world of Drupal contributing. Let's put it like that. Then there are people who are like, I've been around forever. I've been in the Drupal world for six years, never contributed. How many? I'm not going to name and share. And that's very, very normal. I think I know a lot of people who've been in the Drupal world for 10 years, 15 years, but never ever contributed. There are a lot of factors around it and I don't think there's your hair you want to contribute and that is amazing. So a pat to yourself on the back. Then there are people who may or may not be in the Drupal world, but or even if they are, they're looking for new ways to help out because contribution is not just about code contribution. We will be talking about that. There are a lot more ways of contributing. And this one says have not worked with the new process. For the people who have been contributing, I don't know if you know, but it's not new anymore, but people still like to say, because earlier the whole Drupal.org system was based on CVS and it was patches, et cetera, et cetera. About four years back now, they moved to the GitLab. So now they do have merge requests and people are still not comfortable with that. And that's why they are like, I don't want to contribute. So we'll be talking about the merge request process also, but very, very quickly. We'll not go into a lot of detail. It's not very different from what you do on a daily basis. Create a merge request, you do that every day. So basically, who are you? Can be anyone. You can be a person who doesn't know Drupal at all and still you can contribute. And we'll be talking about how. Why should you be contributing? Should I even talk about this? And I'm sure everybody here heard the Drees keynote yesterday. So I can just build up on top of it. You, Drupal is open source, right? Open source depends on you. Unless until you contribute back and it doesn't have to be good contributions. Unless until you contribute back, it cannot thrive. It's people like you and me who actually make Drupal, Drupal, the whole ecosystem. I have made some notes, I'll read it out, okay. So Drupal is an open source project reliant on community. Everybody knows that community contributions from organizations as well as individuals to keep it moving forward and improving. Your contributions are valued very much. We all have a unique and diverse lived experience from different countries, cultures, races, genders and developer roles. And contribution also makes you a more integrated part of the Drupal community because it helps move the project forward and helps to stay relevant with innovation. I also feel, and probably that's a next slide conversation, but still, if you're contributing back because you're working with such smart minds across the world, you're not limited to people who are in direct contact with you. If you're contributing to, let's say, a module that was created by somebody who's sitting in Belgium or somebody who's sitting in US. You're talking to them, you're talking, you're having conversations with them. You are getting different viewpoints. You're working with such smart minds. It challenges you more. It increases your expertise. It grows you a lot as a professional. So I think that is one huge reason why you should be contributing. I'm sure there are no agency owners here, but still. Why should agencies be contributing? Well, companies who consume Drupal as free open source project, they should be certainly giving it back. They should appreciate the value of helping each other and helping others. They should also help with reducing the duplication and redundancy. Because if you're talking to each other, people are not working on the same problem. People are working on individual problems and their synergy. In tech industry, you're using and contributing open source is also considered as a good corporate citizenship. So as an agency, yeah, it's a good brand value. I help my people contribute. Sure, why not? And as I was saying, it helps with talent recruitment a lot. Why? Because your talent, your resources, your people, they feel more excited to work because they're working with people. They're being challenged. They're working with people with diverse backgrounds. They're working with people with such smart minds that I think some people say money and empowerment, et cetera, et cetera is a core reason why people leave jobs. That's not only always the reason. I know for myself I left a job which paid me more because I was bored there. I was working on the same something, dash, dash, dash. I'd be a project for two years, working with the same people, doing the same thing again and again and again. And I joined a company at a much lower pay. And because I was not being excited about my work. So talent recruitment is one huge thing. And people love the community and attending events. We are here. We are attending the event. Yesterday, Dries mentioned about the Certified Partner Program. So if your agency is contributing, it helps with the ranking of the community about the partnership as well. So that is also another reason. How do you start? I'm sure everybody has a triple dot ago. Please don't say you don't. But why? This is sort of a resume. Whenever a resume comes to me for a Drupal developer, I don't look at the resume first. I look at the dot O profile first. That's what I always do. And I'm sorry to say it, but by the time I come back to the resume, I'm already thinking about the person in a certain way. I'm already biased. It may or may not be a right thing to do, but it's very important. So having a D dot O profile is really, really important. And as I was saying, do you need to be a coder to contribute back? No, you don't need to be. Some of our most prolific contributors are non-code contributors. You can be huge as that to the project without ever writing any code. I can give you my own example. I started off as a developer, as I told you. I used to contribute, code contribute a lot. But in the past few years, I have not been doing that. But if you go to my profile, you'll see I still have a lot of issue credits. Why? Because I've been contributing in different ways. I organize a Drupal Melbourne meetup. By the way, you should join that. It's online, so you can always join. Second Wednesday every month. Second Wednesday every month, 5 PM Melbourne time. So you can always join that. We do that monthly. We don't always get speakers. Then I have to arm twist my colleagues to give a presentation. But that's how it works. I have to get that done. And that is a great way of contributing, because you are actually making sure there's an event happening. People are coming together. Somebody is presenting and sharing their knowledge. They're also contributing in their own way. And event, this Drupal South, it's an event. It's joined by contributors. And this is a huge contribution that you can make. But I'm digressing, because we are talking about that here. We'll be spending a little bit time on this one, because the moment I say contribution, everybody thinks code code. The moment I say Drupal contribution, everybody says, but I don't know how to make patches or something like that. But you don't have to do that. There are a lot more ways that you can contribute. I'm assuming that many people here are here for code contribution. But let's try and widen your thinking a bit as well. You don't have to be a code contributor. What else can you do? You can improve documentation. Did you know that Drupal.org? And I'll go to this one. So if you go to this particular URL, this is localized.drupal.org. And you should actually log in there using the Drupal.org credentials. You can log in there. And you can see the different languages and what is the status of core translation that has already been done. So for example, I'm from India. I know Hindi. I should probably go there. I've already sort of done that. But yeah, I should actually go there. Search for Hindi, click on there, and try to see what all can be done. I'll just click on anyone. I don't know Finnish at all, but still, let's see. And it's very, very simple, very small contributions you're making. If you know a language, you would easily know error message. Oh, in Finnish, it is called this. So just edit it, add the translation, and you're done. That's your first contribution, which is you have spent maybe two minutes, not even that. And you have done your contribution. So you don't have to have, like, focus on a bug, focus on doing this and this and this to contribute. Yes, all those are really, really helpful, really, really useful, but there are other ways. I don't have a lot of time for contribution. Do some documentation contribution. Do something, right? Coming back here. Issue triaging. Now, what is issue triaging? Is there anywhere here from service test experience, service test kind of a background? Then first level triage, that's the only thing you do. What do you do while triaging? Go ahead, if you can, speak, yeah. And try to, yeah. I think the first thing is whether it's a problem or not, because at times that happens. Oh, it was just a cash issue. They had a problem at that time. They had an internet issue. So that's the first thing. So issue triaging is something you can do. When you look at an issue, it might be a new issue. Look at it, read it through. Try to reproduce it and say, is it an issue or not? That's the first thing you can do. The second thing you can do, hmm, okay, let me try to reproduce it, that those kinds of things. And then try to look at, try to do some research and see if there is a duplicate issue already there, because you don't want two issues for the same thing. If it's a duplicate issue, go ahead and mark it as duplicate. This is a duplicate of that issue, close the issue. If it's a proper issue, yes, this is an issue, sure. You can say, okay, I tried to replicate this, this is what I did, this is a valid issue. That's issue triaging. In some cases, you need some more information, because some people just go and say, I have this bug, I can't do this and this, but give us some more details. So what was the version you were using? If that's the case, issue triaging and contribution would mean you comment on the issue saying, hey, X, Y, Z, whoever put in the issue, can you please give me some more details? What are the steps you followed? What is the version of PHP? What is the version of Drupal, et cetera, et cetera? So that is also super, super useful. There is actually a blog, there is actually a blog that, I don't think I have opened that up, but if you just search for Drupal.org, triaging issue, there is actually a very good blog article which explains that in detail. And also, our friends said, previous next, so I'm sure you know, tomorrow is a code sprint, and previous next is sponsoring it. So they have a great blog, and I'll be giving you a link to that blog later on. They have a great blog in which they have a great video for issue triaging as well. So that's issue triaging. The, oh sorry, I talked about translations when I was supposed to talk about documentation. Really sorry, we've already talked about translations, let's go back to documentation, and nobody said anything. Wow. Let's go back to documentation. So documentation, there is lots and lots and lots of documentation on Drupal.org. Again, if you go to the issue queue, you can actually see a specific dropdown for documentation, so you can find the issues which need documentation, and you can go ahead and do that. The multiple types of documentation that Drupal.org has, there are official guides, there are curated guides, there are documentation guides, which are community guides, there are contributed contribution guides, contributor guides, which are essentially guidelines on how to use the Drupal.org tools and services, and then there are contrib guides. Yes, there are contributor guides and contrib guides, not confusing at all, but the contrib guides are the documentation for contributing modules. So how can you give back this documentation? Oh, I use this module, it's very great, but to set it up, it was a nightmare. Yes, it was a nightmare. So how about you go ahead and create a page on Drupal.org. This is the documentation for this particular, and put in an issue in that module as well. Hey, I had this issue, I've created this page, and then it's on the owner of the module to go ahead and accept that documentation as correct documentation. They might want to tweak it a bit, et cetera, et cetera, but you have contributed, right? All right, translations we have already talked about, not talking about it again. Marketing, you attended Dries's keynote yesterday. Did any of you attend the Q&A after that with the Drupal association with Tim and Dries and Owen? So marketing, I should not be talking about it again, but Dries talked about this in great detail, both at the keynote as well as in the Q&A after. So there is a very, very strong initiative to promote Drupal, and you can actually become Drupal ambassadors by promoting Drupal in your networks. How can you do that? You can share, share and re-share articles. You can go to non-Drupal events and try to promote Drupal there. You can have social media, you can use social media. So some of the tasks on the promote Drupal initiative are presentations, like what I'm doing now, but I'm not really promoting Drupal a lot because I'm doing it in a Drupal event, but yeah. Social media, photography, logos, et cetera. The promote Drupal team is always in need of project leads, writers, designers, videographers, communicators and other marketing roles. So there is actually a promote Drupal initiative and let me just open that URL here. You can see it gives some details about that and if you are interested in volunteering for that, there are, you have those options. You can click on that volunteers to get involved. Coming back to my presentation. And the last type of non-code contribution is sharing your knowledge and mentoring. I'm doing that, right? All the people who have presented yesterday and are going to present today, they have been doing that. All the people who create YouTube videos telling you how to do even something as simple as logging onto a Drupal site. They are actually sharing their knowledge and that is a sort of a contribution. And mentoring, yes, we'll be, we'll have a lot of mentors, but even if in your own organization, a new person joins in and you are there for them and you are there for, they're answering their questions and you're there answering whatever questions they have about Drupal, you're mentoring them. So that's another type of contribution. And now let's talk about code contributions. These are pretty straightforward. Test experimental features. So take for example, there are, when Claro was being built, Claro, does anybody, everybody know what Claro is? Yeah, okay. So when Claro was being built and it was shipped with Drupal as an experimental feature, if not enough people actually tested it and reported back, it would not have been added to Drupal back as a core feature. So we need people who can test the experimental features that the Drupal.org team is building or even country module. If it has started off as experimental, we need people to test them, unless until people test them, how's it going to work? So test them, give your feedback onto the issue queues, onto the project issue queues, and that's how it works. The next one is creation of merge requests. So that's actually the code contribution. You found a bug or you saw a bug, an issue on the Drupal.org website. And you face that, yeah, I saw that in my project last month. And this is how I fixed that. Please go ahead and create a merge request because that's how others will use it. And then it is possible that if it's a contribute module, the owner of the module can merge that back into their module and yeah, you'll be credited as well. So your Drupal.org profile will get another tick, which is always good. But I think that's an additional cherry on the cake kind of a thing. The cake itself is that you contributed back. Bug reports, you found a bug, you don't know how to fix it. And I'm pretty sure everybody here created a Drupal.org because of that. Oh, I found a bug. I can't find it. I can't get an answer. Let me post a bug report. But that is a form of contribution. Don't think you're not contributing when you are raising a bug report because everybody wants that what they have built should be bug free. And if you're raising a bug report, you're actually contributing back to the community. It's super important. So even when you have created a Drupal.org account just to raise a bug, still you are valuable to the whole community, so be happy about that. Test existing merge requests on issues, like I was telling, there is an issue which already has a merge request. Test them so that it can be marked as RTBC and then it can be merged back into the module or core, whatever, and provide feedback for anything and everything. All right, so issue queue 101, etiquettes and etiquettes. I've given a link of the Drupal core issue queue, but this actually applies to all the issue queues around. So this is the core issue queue. You can, as I was showing you, you can go to the advanced tag. You can show, you can filter the issues using tags. You can filter the issues using at what stage they are. So if there is an issue that you found and it is at RTBC stage, then that would mean that, okay, the merge request that I see here or the patch that I see here, it works. It is possible that the owner has not merged it back, but I can use that patch, right? So if you face an issue, you found it. If you face a bug in your system, you found an issue that replicates that, but then there is a patch, it's RTBC, great. So those are the things that you can use to search stuff. If you're a novice, if you're trying to give back, contribute, go back for the first time, there are some kind of issues that you should stay away from. Don't look at the projects that are not actively maintained. There is no point, probably. So try to stay away from them. There are multiple issues that are actually not won't fix. So try not to go for them. If the issue was raised five years back and there has been no conversation on that for the past four years and 11 months, please don't look at that because most probably it's outdated. So let's not look at those. If the issue has more than 20 comments, I mean, if I look at this one, it was created almost six years back. It has 256 comments. Please don't, you're a newbie. Don't try to dip your toes in here. And if you look at the lower one as well, it's got 120. Also, if there is an issue that has been moving status along, when I say moving status, okay. So over the period of its history, it's gone from RTBC then back to in progress then ready for review RTBC and so on and so forth. That means that there is something complex going on there. The people are not really sure of what direction should be taken to fix the issue. So probably because you're a newbie, try not to go for them. If you look at the second column here, I'll show you what I'm talking about here, this one. So when people create issues, they can actually mark that as critical, major, minor. So as a newbie, don't assign a critical issue to yourself. Let other people take care of that. Go ahead and look for which are minors and novice tags and so on and so forth. I thought that this is pretty relevant to what we are talking here. We've already sort of covered it, but this particular slide is pretty relevant because each issue will have these things. So each issue will have a title, category, priority, status, version, component, et cetera, et cetera. Please note that we did not talk about version earlier, but it's super important to know the version. If there is an issue which says Drupal 8.x, I don't care about that issue now because most probably it's fixed in Drupal 9. If it is not fixed in Drupal 9, then that or Drupal 10 actually, not even nine, because then that issue should be edited and updated to mark it as a Drupal 10 issue. It should not be a Drupal 8 issue at all. So that's also super important. This is also super important for, in case you are starting to report a bug. So you want to create, you face an issue, you want to create an issue on data. What all is needed? Title, of course. Make the title, it should have a good description, but it should not be very long. And the reason for that is when you see the issue list, if it's, the titles are shown there. So if it's a very long title, it doesn't look good. The category, whether it's a bug, sorry, whether it's a task, a bug, a feature request, a support request, et cetera, et cetera. Priority, minor, major, critical. And it is possible that you create something else because you think it's a critical thing, but the owner might say, it's a minor thing. So they might change it, but you can go ahead and create it accordingly. Status, it's still new. Nothing has been done, et cetera, et cetera. Version, version is very, very important. If you are creating an issue, make sure you put the version correctly. Even in the summary, you should be putting in all the steps, all the screenshots that you can, and put in your versions. Not only the Drupal versions or the module version, but it's always good if you provide more information, like PHP version, for example. Sometimes the issues are because of a PHP version rather than anything else, and so on and so forth. Tags are important. Tags are important because of what we earlier said. No ways, Drupal South, et cetera, et cetera. This is an issue summary template. It actually gives you all of these things to fill in. So if you're creating an issue, you'll probably see something like that that will help you in filling out the issue in a more robust way. Do this, report the issue in the correct project, read the relevant documentation. If you find an issue, please search for that issue. Don't just go ahead and raise it, read, re-read the documentation, search for it, et cetera. Check if you're using the latest version or not. Try it if it's fixing the latest version. Try to get help from the community, search the issue, et cetera, et cetera. And leave the noise issue for new contributors and don't do it at this phase. So the security issues have a totally different flow. So if you find a security issue, please do not log it as a normal issue. It needs to have a different flow. Don't hijack other issues. When I say hijack, you find an issue sort of similar, but it's not the same. Don't say, oh, I face this, but I face this also. No, create a new issue for that because that's not cool. And so on and so forth. I don't have a lot of time and I'll be giving you a link to where you can download my whole slide. And then you'll be able to see all the YouTube links and all the good documentation links. So yeah, and we already talked about that, right? Historically, Drupal.org was CVS-based. Now it's GitLab-based. Much cooler, much better. CVS was old. Developing tools. Any of you know what DrupalPod is? All right, I'll do a very, very quick demo. We'll probably not see the whole thing, but okay. So this is an issue. DrupalPod, GitPod, you might have heard GitPod. So basically everything is in the cloud. Your whole ID is in the cloud. Now from GitPod, DrupalPod was created for specifically for Drupal. It has a Chrome and Firefox plugin. If you look at this cute little sign, this one, this is DrupalPod. So if you go to any issue on Drupal.org, you can actually click on this. And I hope it works. So and if this particular thing had more than one branch, it will have given you a list, you want to test the branch that was created. So you'll say something like, all right, this. Now Drupalcore version, no, it's 11.x. So I'll do this. No badge and install profile. Let's say minimal and open Dev environment. I'll not wait for it to be built because it takes about five minutes or so. By the way, for GitPod, you have to log in to GitPod. You can log in user GitHub account, GitLab account, whatever you have. And you will do this, continue. And now what it does is it starts creating in the cloud an IDE that will start installing Drupal with that particular branch, with that particular patch, et cetera, et cetera. And it will start giving you information and you can see what's happening there. So everything is in the cloud. Hopefully, I mean, this will work if you have a great internet connection. If you have a crappy one, it won't probably work. But this is how it works. And once this is done, you actually have the Drupal install showing on your right-hand side and your ID on the left-hand side. And then it even has Drush access, SSH access, everything. So you can actually build everything in the cloud. You don't have to install anything on your local at all. And it's available within 10 minutes or so. So very, very cool. And as I said, I'll not wait. And it gives you a lot of what to do, what not to do, et cetera, et cetera. So yeah. The other options are, of course, local Dev environments, MAMP, WAMP, WAMP, who uses Windows? But yeah, people do, I know. Government. So LAMP, et cetera, et cetera. Ddev is very used a lot. There is also Lando, Doxel. People use that a lot. And there's a site called Simply Test Me. Has anybody used Simply Test Me at all? It's a, again, it's a very good site. You can actually say, I want to Drupal install build with this particular module and it builds it for you. We've already talked about this one. I skipped ahead, because that's cool. Now, at the very last of my thing, there are some contribution videos. But as I said, I'll be sharing the slides. So you don't have to really write them down or take a picture. You should be able to. So there are some great contribution videos. These are more video playlists. And these are some resources, QR code for my slides. So if you want, just go ahead and scan that and you'll be able to get my slides without speaker notes, of course. Everybody done with the QR coding? I'll wait, because then you'll be actually able to click on the link.