 First of all, thank you for the opportunity for letting me present here. So just a very basic introduction regarding Drupal Contributes. I've recently been working with Drupal Contributions as a part of my concert by Salsa. So earlier I used to do some contributions, but now that I'm doing it for Salsa and learning a lot of things from Christine and a lot of other team members. So I just thought maybe I'll sum up and I'll present some things that I've learned new and which may be helpful for everyone here. So it's not a very structured presentation, but hope this helps you guys. So let me start with defining what is an issue workflow in Drupal.org. When we create an issue on Drupal, it starts with the active state, then we work on it, we move it to needs work, needs review, and then finally reviewed and tested by the community. So this is the general workflow that we follow. So I'm going to stress on the reviewed and tested by the community, ITPC step, and how do we do that, how do we comment, and what are the best practices. So I'm going to focus on ITPC step. There are a lot of other statuses as well, closed, fixed, closed, duplicate. These are the ones which we generally see. And yeah, so this is the general workflow of the Drupal issue. I'm going to start this presentation with like how do I find issue for work? Generally, I start with this URL. There are multiple ways you can do that. Firstly, you can just use this project search window. What I generally do is I use any of the issue tags mostly, no, or or bug smash initiative. There are a lot of issue tags which can be really helpful for finding issues to work on. I also sorted by last updated so that you get to work on issues which are like actively being worked. I also choose the needs work. Or if I want to review an issue, I choose needs review here. One more thing that I wanted to show showcase to you guys was there's an issue Kanban as well. Searching an issue with this to like on this search issues is sometimes very difficult. So Kanban really helps here. So let me show you an example. So you just need to have the issue keyword like issue keyword and use this Kanban board and you will be able to see what are the active issues, what are the needs work. So it's not loaded for me, but like it generally does. You can select the priority. You can also choose type of issue that you want to work on and choose issue. This is how I generally search issue. You can also join the Slack channel and there are a lot of channels. For example, announcement support, Drupal SEO needs tests, a lot of them. Most of these channels have bi-weekly meetings so that you can attend and you get to know what is being worked on and that really helps. Next up, I want to talk about some helpful tools. I'm not sure what you guys use for general development and Drupal contribution like which tools you use. Most of you must be generally using a Drupal setup environment, but I use something called as a Drupal pod for review. I'm going to demo it how exactly that works. You need to install an extension of Drupal pod on Chrome and once you have it, you just visit any of the issue pages. If you want to try out this patch, if you want to troubleshoot or try out this patch, all you need to do is open this extension, choose which patch you want or maybe which branch you want to use alongside. For example, if I want this patch to work with 9.5 and whichever installation profile you want to troubleshoot it with and just open the dev environment. This is going to build an environment for you and you can also modify the code. You can also troubleshoot the issue here. This is really helpful because you don't have to have all the environments, for example, if you want to work on an issue on Drupal 10 and suddenly you have to switch to 9.5, it takes a lot of time. Whereas over here, it instantly creates an environment for you and you also get access to the code. Let's wait for this environment to get ready. It should be up within 30 to 40 seconds. We have this environment here. You can either open it in whichever editor you use or maybe you can also open it in the browser. I prefer using it in the browser itself. Once I have opened it in the browser, a VS code repository opens for you. This is where you can see all the code and the patch is applied. You can also use standalone VS code and it will open the code for you. It quickly runs through a few steps and applies the patch that you're using. In the meantime, let me show you the GIT pod. This file saves all the configuration for you. The extension, you can add extensions. The next time you open this VS code again, next time you open GIT pod, those extensions will be pre-looted for you. You can also use XDbug over here. I'm going to let it run for a few minutes. This patch file is getting applied and should be ready very shortly. In the meantime, we can see the ports directly, the ports window. Here you'll see all the ports that are being used. This one is particularly for the website. You can preview the website or you can open it in the browser. You can also make this public and share this entire project with someone else. For example, if I'm stuck with some issue which I'm not able to resolve and I want to share this code with someone, one of my teammates. I can do that by just clicking on this button and this URL can then be shared. Any code changes also get applied immediately and then you can troubleshoot it. I think it should be ready now. I'm going to access the website preview and see if I see the site. Yes, the site is up here. I can open it in a new tab and show you guys. This makes use of DDEV in the background and Drupal pod is free for, it provides 50 hours free and if you are a contributor, you can get an unlimited access to this service. I generally use this for troubleshooting. I can use DDEV in order to enable in order to enable XTbuck, you just need to add this command DDEV, XTbuck and go here and listen to XTbuck. That should start debugging for you and as usual, we can just go to the web directory and wherever you want, we can add the breakpoints. This is how I generally troubleshoot with Gitpod. General instructions have been provided on this particular page. These are the instructions. If you are using it for the first time, this can be really helpful. This was about Gitpod. Next up, I'm going to talk about another repository that I use. Drupal contributions repository is... If I need to review an issue, I generally use Gitpod. But if I need to work on an issue, if I have to create a patch, I generally use this repository called Drupal contributions. This is a repository which allows us to also quickly switch between versions. It has following functions. It allows us to run PHP unit test cases. It allows us to reinstall a site. You can quickly use a patch. You can revert a patch. You can run all the course checks. These are the ones which are run by Drupal.org when you submit a patch. For example, this custom command failed. If you run a Lando course check, it's going to identify all the issues for you and it also allows you to create a patch. This is how it looks. It has a config file wherein you can set the Drupal branch you want, for example, 10.1.x. After that, you need to run the command Lando. Once you run this, the environment will be set up for you and you can use this. One more important command that I generally use is Lando patch and the patch URL. Any Drupal.org patch, you can directly apply here. This can be very helpful, also PHP. It gives you details regarding the patch, whether it's applied and what are the files that were changed. This also is a very helpful tool. Apart from this, I also use DR editor. Moving on to the next topic that is reviewing an RTBC. How do we review and how do we RTBC? I'm going to talk about it in short. These are the questions that we really need to ask ourselves when we move an issue to RTBC or when we review. Are there reasons to not make this change? Can it be done in contrast? Is the scope correct? Is it an allowed change? Is it significant change? Is it experimental? All this needs to be, a review needs to be very significant. One more thing that we generally mention while doing RTBC is, first, is whether the title is accurate and clear of the issue. Second, issue summary. Issue summary needs to be clear. It should have steps to reproduce. If any of these are not there, we generally don't mark this ticket as RTBC. We ask for these changes to be made. Third thing is, has the before and after screenshots been embedded in the summary? Then we check the metadata, whether the project is correct, whether the version is correct, whether status is correct, etc., etc. Next thing, if we have any parent issue, we need to check. We need to add that. We also need to add related issues if applicable. Then we only need to display screenshots and relevant files. For example, if you see this particular issue, there are unused files. These are not required, so we need to hide it and find the code review, whether the patch applies correctly, whether coding standards have been tested, the documentation is clear. I'm going to show an example of RTBC issue, which has been tested. This gives a very clear thing on how it has been tested, whether the patch applies correctly. It has screenshots of how the model was installed, configured, etc. It also tells that a great status was checked. We have checked for any database DB logs in issues or warnings. There were no issues or warnings in the DB log, and code review was done. Only when all of this is done, we move the issue to RTBC. That was mostly it from my side. If you have any questions, I'm open for it. I haven't been contributing to Drupal for a long time, and I know that they've moved to GitLab. The new issues that I see have pull requests instead of patches, but I see still there's a lot of issues that have old patches, like dotpatch files included. Has there been any official decision to start moving those patches into PRs instead, or are we currently working with both PRs and patches? Currently, we are working with both PRs and patches, but it is like PRs are a preferred method, but I find it sometimes slightly difficult because someone creates a PR against the base branch, and the component version changes. We have to rebase and do a lot of stuff. There's no official method for it, so currently PR as well as patches are good. I would like to add to that. Sometimes the integration with GitLab on Drupal gets broken, and sometimes you try to create the PR branch, but nothing happens, so I fall back to creating a patch in any case. Are there still conventions on the patch naming that trigger the bots for the automated tests and things like that, or any name will do? Because usually we used to do the issue number, and then dash, and then the comment number, and dotpatch, whatever it was. Has that changed? Do we have a different convention? We have, it doesn't trigger the review as such, but the general convention is issue name hyphen, the comment ID, I mean comment number. I have also seen another convention that is description of the issue, then issue number, and then the comment, but generally I prefer using just a simple one. This naming standard doesn't trigger a test. Once you add a patch and move the issue to needs review, only then a test is triggered. Dotpatch would generally trigger a test. Also, we generally provide diff, so interdiff, which for example, if there's an interdiff here. Changes between previous patch and current one. Yes, so any changes between version is generally provided, so this helps in reviewing the patch. It makes it not easier. Okay, and so the trigger to start bot test basically is to move the needs review, right? And I haven't, as I said, I haven't looked at this, but it used to be multiple versions of PHP that we was checked against. Is it only the recent, the most recent now? No, it depends upon you. When you upload a patch, I think I'm logged out, but let me see if I can. When you upload a patch, you can specify the patch. What you want to test and you could also say if you want to test it or not. Okay, okay. Also, you can append your words, do not test to the patch name. And last, the last set of text, just put do not text and all, do not test in all caps. So if you don't want that particular patch to be not tested. Okay. When you upload a patch, you can specify the words in here. Okay, cool. Cool. Thanks. So maybe I'm just curious, I didn't do a patch, like I uploaded a patch, but I didn't do the whole workflow before. So my question is, do you know where the figure come from? Like as like for each patch, we can see like it had been testing in specific version and how many has been passed. So that figure, do you know where it's come from? Like it's just test by different size or it's by like a different, yeah. So do you know where that figure comes from? Like how, yeah. Yes. So firstly, you specify the version you want to test and there's a Drupal CI, which does the testing. It's automated CI, which will run all the tests and we had tests in, I mean, PHP unit tests and it'll let you know if there are any issues. It'll, it also runs through PHP CS and, yeah. Yes. Lint also advanced. These are the things. If you use this repository, the one which I mentioned earlier, it lets you, it lets you run all those commands. You can run Lando core check and PHP unit. So these are going to run all the tests which are there in CI, I mean, the Drupal CI and your patch won't fail after that. Sorry. Cool. So could I, to be honest, I didn't use Lando before. So do you reckon, but I heard it's a lot like a talker solution. Do you reckon this maybe Lando is the best, the most popular talker solution for like a Drupal hosting now? Also, maybe it's also widely used in for patch and workflow. Yes. Lando as well as DTAP. DTAP is, I think, a preferred one because like I read a lot of documentation on Drupal.org which specifies DTAP. Oh, yeah. There's a, there's a development tools page. This specifies DTAP and Lando. It also specifies Gitport. Yeah, that's great. So in order to use Gitport, do we need DTAP environment setup or like when we set up Gitport, DTAP will automatically like, automatically run, but if you want to run Gitport on your local machine, then you need to install DTAP locally. Okay. I'm using DTAP for my local environment. Okay. Yeah. So I can try Drupal for it's really the feature which is like switching between versions that's really helpful. Yeah. It has helped me a lot and I heard a lot of people use Drupal.org to make changes and showcase it to the client as well. So I'm not, I haven't explored that aspect of it, but I think that's a very helpful tool. Can we change the PHP version by Drupal.org? Yes, you can. You can do it in the www.drupalpod.yaml file. Right. Thanks. You can additionally run this local on local and these are the commands. I haven't really used it that way because I prefer using Lando contributions with Drupal. Right. Sorry, one more question. So about Drupal patching or like create merge request, is there any code coverage requirement from Drupal or from the country module or mainly a decision by the developer for the patch or the merge request we added or submitted? Like as you said, we need to run the Lando p3 unit. So for unit testing, is there any certain role like the new edit code must be 80% covered or any roles like that? No, any developer, anyone who has an account on Drupal.org can submit a patch. Okay. And you don't need a specific role for that. For merge request or if you want to create or if you want to work on a merge request, I'm going to quickly show how that works as well. If a merge request is already present and if you want to work on that merge request, let me show how that works. I think this is the one. You go here and once you're logged in, you will have this button. You have to ask for, there's a problem. But generally, if I click on this, get push access, it gives me access to this MR and I can then pull and also push this merge request. Does that work as sort of like, is it a collaborative way of having multiple people contributing to the same? Okay. Yes, exactly. So this is a merge request created by someone else and I have access to it now. But first you need to click on that get push access button. And once you've done that, you can easily push and also there's a way to change this version as well. So this pull request, I think it has a specific version. So you can also change that. And if the issue remains open long enough and the work becomes outdated, who is responsible for rebasing? Is it the original person? Do you? Generally, anyone can revisit who has pushed access. Okay. So it shouldn't be a problem. Okay. Yeah. Mostly that's it from me. Any other questions? Thank you. I have a question about it, maybe not related to this. So I think I can see the lendo it's free like open source to build based on Docker. And I think Docker desktop has a license like if it's used by like the companies, it's not free. We need to pay for that. So is there a similar limitation in lendo or like as far as free, we can just use it straight away. So any license issue in that site, do we need to pay for anything? I don't think so. Actually, there is there is an issue. So did they've started an issue? I think they're already support. I can't remember the name of the product, but I'm looking in GitHub to find the name and I'll put it in a link. So it's sort of like a more open version of Docker basically. And the dev already supports it, I think, but lendo has an open issue to include support for it, but not yet. So in theory, everyone that is using Docker for commercial use and not personal use on their computers should have a license. But if you're asking if people are doing it, then I appreciate it, man. Yeah, that's the issue. I think I was I have like I was told you I can't use Docker for the commercial use. So I need to figure out something else. Saxman, if you could share the link, I really appreciate it. Thank you. Yeah, yeah. I'm trying to find it now. Yeah. Yeah, the workaround I had is I just use a virtual box and get similar tasks down in as a Docker desktop, just use Docker compose and manage everything in the Linux virtual box. But it's very, very, it's not really a good solution. Like it requires more resource and somehow in syncing files and resource. Yeah, it's fairly buggy solution. So the software that is alternative, there's actually two, Rancher desktop and Colima. So the dev I think already supports Colima. This is the issue in the lambda queue. I am not sure if I can remember, I haven't bookmarked or start the respective issue for the dev. But I guess you got a lot try to find like Colima. So I think this is a great place for me to start with. Yes, really helpful. Nice. Yeah, and this is the link for others as well for Colima, which is the sort of like open source alternative of Docker. So, thanks. And there's me plus one in it since past May. So that's why I know that's Clonus meeting. Thank you. Yeah. Thanks for that. I wasn't aware. Yeah, I use Lambda heavily as well with my contributions to the backup CMS. And I have my own scripts that's been up D10, seven, eight, whatever versions. I'm hoping to open source that at some point. But yeah, it has come up multiple times because there's some people that are very cautious with software that are doing things in a, I don't know, perceivably unethical manner or, you know, not entirely open source. So yeah. All right. Do you have any other questions? Yeah, any more questions? No, no question. But just out of curiosity, I'm working on one feature, which is multiple taxonomy filter as a Sorry, that's not relevant to the presentation. I might just stop the recording.