 I think so. That's it and everything? Yeah, yeah. The displays are working. Yeah. You're okay with it being a second monitor? And so that would keep it? Because you can just drag. Yeah, yeah. Oh, yeah, yeah. Not that you could drag much. But I don't think. Oh, yeah. Fantastic. I just want to make sure you're okay. We'll have a good talk. Yeah. Thank you. No worries. Okay. I think we are good to start. It's too. You're here for looking at, you know. You're here for looking at. You're here for looking at. You're here for looking at. You're here for looking at. You're here for looking at. You're here for looking at, you know, how do we build a contribution culture in a Drupal agency? But I should be audible. I don't think the mics really necessary, the microphones. So how are you enjoying the conference so far? Good. The city. I'm guessing most of you are already from here. Well, this is my first trip here. First time I've been to London. Love it. It's, it's, it's. And yeah, this is by the way, this is my first time in snow. So it's been even more awesome. Everyone complains about the weather right now, but secretly, you know, inside I'm granting that, you know, okay, yeah, complain all you want. I'm enjoying it right now. Okay. So, so I'm the guy on the left, the right. I'm getting, I'm getting it mixed up. Yeah. So I'm the one on the right. I work as an engineering manager at Accel event. We are a completely remote company. We have presence in India, US, and well, since we are remote, we can have presence anyway, you know. So for example, Nathan over there works from Japan. And we have various team members from US, from Africa, from, well, no one from Europe yet. Yeah. So I work as an engineering manager since about a year. And it's been my job, you know, even before I was formerly an engineering manager, it was, it's always been my job to look at how do we improve contributions. And we'll talk about that, you know. So we'll talk about why should contribution be important to you. So I'll put it in terms of, you know, why is it important to us, you know. So essentially, more contributions mean less work for others and for you. So maybe I should have started off with this. How many of you are developers here? Okay. Almost, I think a good majority. So as a developer, you would know the value of reusability. You know, you solve the problem once. You don't have to keep solving it. That's the real value. And if you can put it someplace, you know, GitHub or Drupal or ORG, then just reuse it later on. It's probably not a surprise to anyone that contributors have a stronger voice in the project. You know, Drupal has sometimes been criticized for being a democracy. Well, but that's that, you know. Contributors do have a stronger voice in the direction of the overall project, you know. It, ranging from Drupal core, but also to some of the popular contributor modules. And if you're maintaining your own module, I mean, of course, that's all yours. Contributing helps you learn Drupal faster. I can't begin to count how many people have learned Drupal who are excelling in their jobs right now because they began, because they started out by contributing. I just jumped in, like, you know, a few years back, I just jumped in the issue queues and started contributing and that helped me learn Drupal 8. So I started by contributing to Drupal 8. And that helped me learn Drupal 8 better. It's, I mean, like, the contributions have scaled up since then, but also, I didn't say my work quality has won it. I have a, I have, what's the word? I can think of problems in terms of, not just in terms of, you know, that this is how I would solve it in Drupal, but also in terms of this is how I would solve it and solve this problem in other frameworks, you know, because it's Drupal 8, right? It's a bit of symphony, but that's another story. And this could be true for your team as well. We, you know, more on this later, you know, how do we encourage contributions at Accelerant? And then I'll tell you about how it helps all the, all my team members, all my colleagues to really excel, to really learn, to learn in the real world, not just in a closed cabin, you know, not be limited by geography or by, you know, not just sitting in a cubicle. From a business point of view, more contributions mean more business. Again, I have a few points about that. Well, Drupal community members are good people. You probably already have experience about that. You know, I don't need to really talk about that. And there are a lot of other perks, perks like this, for example. I was in a session just before this by Eli and he mentioned, you know, how Namneet, him contributing to Umami, I don't know if you were there in that session, but Umami is like a demo profile that's being built out, you know, to showcase Drupal capabilities better. And how his contributions to Umami have helped him receive a scholarship to attend DrupalCon Nashville. And well, I mean, that's true for everyone, you know. So I attended DrupalCon Baltimore on a similar grant last year. And hopefully I will, you know, I will attend Nashville as well. And it all comes down to this, I think, you know, social capital. And the definition says that it's a, well, the definition is right over there. You can read it. But it's basically kind of an intangible, I mean, the best way I can put it is, you know, and I'm really humbled by this, you know, even if I don't sound it. When I walk into an event, you know, a conference and, you know, I get a really strong, good feeling that I'm immediately recognized. I mean, I just walked in today morning with the first face I saw, Vijay, by the way, like we were friends meeting after a long time. And that's true for, I mean, just walking through the corridor over here, and this happens all the time at DrupalCon as well. The Drupal camps we organize in India over there and DrupalCon as well. This was kind of fortunate, the photo you see over here. So DrupalCon Asia a couple of years back, there was a panel about, well, it was a couple of years back and I forgot what the panel was about. But yeah, I was invited by, you know, really prominent members like, that's Mike Lam, Holly and Jam. So by the way, Jam is here right now in the email. So these are the kind of benefits you get. The connections you make, they're really invaluable. And again, there is no shortage of stories. Any community member I talked to, there is a story after story about how Drupal has improved the lives. I mean, were you in the keynote today morning? It was all about that, really. And from a more business point of view, there is a Drupal.org marketplace, the contributions are tracked on Drupal.org in the form of issue credits and everything. And that helps you put on this ladder, which means, like I mentioned earlier, it just means more business. So this is what Accelerance page looks like on Drupal.org. And you can see that for anyone who is involved in a business to do anything, which has anything to do with Drupal, this page just shows all the information that's immediately valuable to your customer. So these are case studies and general metadata. But if you go down and you see that the contributions section starts over here, and Drupal.org does quite a good job of trying to track almost all contributions that you make to the project. They do a good job of tracking it. Like from over here, project supported, and this credited fees you see at way down to the bottom. All that is automated. So anyone who contributes to one of those projects or commits something, gets credited on the issue, it comes up in a listing over here. And of course, there are things that are not automatically tracked, and then of course, we mentioned all of that over here. So this immediately becomes extremely valuable to any prospective customer, and to an agency that's really invaluable. And of course, this presentation is mostly targeted towards agencies, but these points, they're generally applicable. They apply to you, if you're an individual, if you're in a design studio, all of these apply. Similarly, you know, going on the trend of the social capital we were talking about, this is, this chart is from the State of Drupal Contributions blog post, Drees writes every year. So this is from the 2017, and you can see that many organizations, many countries, listed over here in the rank of the contributions that they make towards Drupal. So let's, I mean, all this is good. You being in the session probably already says that you recognize why contribution is important. But let's talk about challenges, because it's not as easy as it looks, and especially in an agency, you have challenges with deadlines. It's very, very common working in a team that, you know, you come across a bug in a contributed module, or you have to write a module to solve something. You just do it now, just fix it now, and we'll contribute it as a patch later, or we'll contribute the module later. We used to do that, and we have, we have attempted to solve that problem, and I'll explain more about that later. Then of course there are general issues surrounding the skills, the awareness in how to get people started. It's a very intimidating thing, right? It's a very intimidating thing, you know, just landing on Drupal.org, finding the issue queues, and then just jumping into a discussion. It's not as easy as it looks, you know. I mean, if you're contributing since a long time, it's second nature to you, you know. It might be like filing a bug in JIRA, and eventually it should be. But of course, you know, for someone who's just starting out, it's difficult. And then there is that hurdle of connections, you know, like whom do I talk to? You need that support, you need that initial mentoring to get over your fears, over your reservations, and you know, just go in, post a patch, or post a problem in the issue queue, or go help out someone in an online forum like Stack Overflow, for example. So all these challenges exist all the time. And then of course, there are challenges in just contributing code. And this is something I see all the time. Don't think of it as open source code. When you're working on a Drupal project, and you face issues with the code, or one of the contrib modules, don't think of it as, you know, that, okay, I'm contributing. Just think of it as an upstream code base, you know, something that you're using. And all you have to do is create an issue. It's just, it's a very tiny shift in mindset, but it's actually very powerful. Because when you start thinking about writing code this way, contributing code this way, you're not, you're not intimidated anymore. You know, it's just a line of code. You know, somebody else has written it, somebody who's equally likely to make a mistake. There's nothing wrong, you know, I mean, if you're working on your project, you wouldn't have reservations to file an issue in JIRA, right? So why would you have reservations to file an issue in, on Drupal Autology issue queues? So this is a reservation, this is a mindset I've been trying to change in my organization, and everywhere in the meetups I organize, and the sprints and everything, that bring this into your workflow. And again, I'm afraid I won't be able, there's a demonstration actually, but since this is recorded, I won't be able to show it over here, I'll be able to show it later on, you know, one-on-one, about how we, how we encourage this, you know. So basically we have recorded a few videos about how we work, how do we contribute. So like one of those videos is about how we contribute, how do we, like I say over here, you know, just treat this as an upstream project, and contribute while you're working on the job. But in that I'm using a live project, and that's why it's internal. So I don't want to get in this recording. Second thing, well, another thing in dealing with this challenge is the challenge of culture, you know. And I think, you know, Ryan, in the morning, he summed it up very nicely by saying, you know, it's like do well and do good. I mean, of course, nobody wants an agency to suffer because they have been contributing. That doesn't happen, by the way, like, you know, nobody wants that impression either. And that applies to individuals as well. You know, somebody who is contributing a lot of time towards open source projects, they shouldn't be, you know, like, they shouldn't have to go hungry, you know, like I'm taking the extreme example I know. But yeah, so do well and do good. So doing good is, of course, you know, how do you build this culture of doing good and at the same time, keeping well. And there are a few ways, you know. And this is mostly experimentation, experimented on our side as well. You know, this is not, it's a very complex problem to solve. It's not something that, you know, we just decided that we are going to solve it and it's done. We have taken many steps. But I think it all starts out by saying that, you know, the informal activity of contribution, you know, getting on issue queues and going to events and talking to people, make it formal. So we actually have policies around how do you contribute, you know, as in not to limit you, but to actually encourage you to go out there, you know, and I'll talk about some of those policies shortly. Measure those contributions, you know. So Drupal.org, one of the biggest successes of the Drupal project as a whole is the issue-created system. You know, how it encourages organizations to contribute more, how it provides value to the individual contributors and everything. And get the whole team to buy-in. I mean, of course, you know, you can't force someone to work in an open source project unless they want to. So, you know, we have to obtain that buy-in, you know. And that's again by showing the benefits and I mean, of course, I have a completely different deck for, you know, why you should be contributing. I didn't go too deep into that over here. And so what do we do? You know, the policies I mentioned, we form policies to encourage all kinds of contribution. You know, really, what I just said. So contributing code, we have KPIs around this. Well, actually, I'm a little mixed about that. It's not a KPA anymore. It's like, you know, it's a different term, but we incentivize all kinds of contributions, you know. And since we are at a stage where we, like, you know, where we are getting, you know, where we are just getting our feet wet, we don't have like strict control around this. It's like, you know, you submit 10 patches in a quarter or you file, you know, you review 10 patches in a quarter. You get one point on that impact scale, you know, the scale we have internally. Attending events. We have a very generous travel sponsorship policy and which, you know... So by the way, I love to travel. In Accelerant, I have... Okay, I'm not going to attempt to count the countries, but I think the only continent I've not been so far is South America. Well, except Antarctica. I've not been there as well. So it's really, you know, like, I mean, I've always dreamed of traveling to Europe or to London, of course, and places like Australia, U.S. and I've been able to do that. This will be my fourth US trip this year and it's like, you know, I mean, it's probably nothing over here, but to someone coming from India, that's actually a huge deal. Every year I've been attending DrupalCon in North America. Europe, there's always a scheduling conflict. I'll be missing this year's Drupal Europe as well. So we incentivize these events. So for example, we have a policy that if you're speaking, if your session gets selected at an event, Accelerant sponsors the entire... All the expenses on a trip. And similarly, there are similar policies for domestic events as well. We have, like, around four to five camps within India and meetups and everything. We have similar metrics to try writing blog posts. Nathan over here, for example, you know, we worked on a model where we incentivize writing blog posts, technical blog posts, and speaking, like I just mentioned, you know, if your session gets selected, if you're speaking at an event, all the expenses are met. Participating in online forums, again, that is tracked, and I'll show. Yeah, I'll just show right now. So this is actually a target of Drupal Association as well. How do you track all kinds of contributions? And we do a great job at tracking code contributions. Not so great job at tracking non-code contributions, you know, like organizing events, volunteering at events and all that. That's, I mean, like, on the scale of Drupal Association, there are a lot of challenges. But at least for ourselves, we have built something called Contrib Tracker. We built this in one of our hackathons. And put very simply, it just tracks, you know, whatever contribution you do. It's simple so far. But the impact is quite powerful. So you have things like code contributions, event contributions, non-code contributions. These are, like, on a very, very broad level, these are the classifications we have. Oh, by the way, this is open source. You can actually go to the link right now, www.contrib.accelerant.com, and you can see this page, the one you're seeing on the screen. And the site itself is open source. So I can share the link later. You can just clone it and set it up, and you can have this running on your systems as well. So, well, you can create event contributions and non-code contributions. So I am delivering a presentation over here, and one tomorrow as well. So I would go over here, and I would file it as an event contribution. If I am organizing a meetup, that's the event contribution. Non-code contributions are, like, helping out people on Stack Overflow and all that. And code contributions, well, that's the whole magic of this project, that it tracks it automatically. So, I mean, who doesn't use Slack, right? So this is what happens. You know, anyone who posts a comment, posts a patch on Rukul.gov. So right now it's only Rukul.gov. We have plans to, like, implement the same thing for GitHub eventually. So this is what happens if you post a patch. So, like, for example, Nikun's colleague of mine, he posted a comment on, he actually posted a patch over here. So it just says that he posted a patch on so-and-so issuing Rukul.gov with one patch, and changed the status to needs that need. And he immediately asked me, can anyone help me over here? You know, can someone test it? And well, the conversation goes on, and you know, this is what we do every day. So what changed? In our workflow, like I said, we treat all code as upstream, you know, and that's, like, you know, the solution to this problem is really a simple thing. You know, just treat it as upstream. So we find a bug in one of the core modules, in Rukul core, or in one of the contrived modules. We create a patch straight away. We don't wait for that. It's not like we, so, you know, actually to help that, we adopt all the engineering best practices, you know. So Composer, you know, how many of you are familiar with Composer, right? So you don't commit your vendor directly. So if you don't commit your vendor directly, there's no way you can just add some line of code. You have to write a patch. And if you're writing a patch in peer review, it's caught over there. You know, why are you writing a local patch? Contribute it on Rukul Autowazhi. Create an issue for that. Post it over there and use it from there. This is what we do. And the same goes for contract modules. If, so, for new team members, this is caught in peer review, but you know, there are enough of your team members who just go and create it. So for example, you know, few slides back, we saw that accelerants, yeah, project supported. So a lot of these, the modules that you see over here came out of such tasks. A few examples like WordPress migration from the VTAT module. For example, that's the recording I'm talking about. That's what I use for my own example of how do you contribute while working. So essentially, in that screencast, the series of screencasts, I notice a bug in my module. And then I record myself fixing it the right way you should. Block and then machine. I think, you know, almost all of these modules, they came out this way. You know, there was a problem that we needed to solve instead of writing a custom module. We created a contract module on day one. Even before the first commit we made it. We planned it out. And we created a project and then treated it as a contract module from day one. So coming back to this. Yeah, so this is how we work. And this is the reason why our Slack channels are always full of these kind of conversations. That's simply because, you know, any problem we face with Drupal core or contract modules, we fix it right then and there. So this is what the website looks like. You know, if you log into phone, if you look at the website right now, this is what it looks like. Except the admin bar, of course. I'm logged in as admin right now. But I'll just do a very, very quick walkthrough of, you know, what this website looks like. So like I said, most of it is automated. Anyone creates an issue. It creates a road over here saying that, okay, for example, put an issue or, you know, the title is actually the comment that they place. And so we don't really worry about the code contributions anymore. It's all automatic. Nobody has to go through a form like, you know, like, you know, nobody goes through this form and fills it out and says, so this actually encourages a lot. You know, one of the things we noticed when we tried to measure contributions, you know, I mentioned that we measure contributions on a quarterly basis. We don't want anyone to go through, you know, like additional work in, you know, like filing that, okay, I wrote 10 patches. Here are the links. We don't have, we don't want anyone to do that. So we wrote a tool for that. And of course there are things like where you really can't write a tool, you know, like volunteering at an event or speaking at an event. So for that, you simply go over here and you log in through your excellent ID and it has Google plus Google authentication. And you would create one of, either one of the event contribution or non-code contribution. So let's see, I'm speaking in this event, right? So I'll just, what's the name of this session? Okay, I probably already have this. Created this. We create events like this, Google Camp London, for example, and session. So they're like, I mean, of course, all of this is controlled. It's a simple site build, you know. What kind of contribution, you know, you did over here. Technology, it's Drupal in this case. Even contribution link, I can paste in the URL to my session and everything. And this is today. So I'm saying that everywhere. And that's it. So this is what we expect all people to do, you know, while delivering your session. And a quick look at what non-code contributions look like. So again, you know, it could be like, something like Stack Overflow, for example, you know, we right now have to blog in Stack Overflow. Of course, it can be expanded for more. So for Stack Overflow, you can mention, like, you know, what kind of, you know, how much credit you're, so like over a quarter, how much credit have you collected? Said that, few comments, and the author. Moderator comments are, you know, only a moderator can see that. I can see that right now because I'm logged in. So yeah, that's about it. All of these contributions get logged. And on a quarterly basis, we build out a report. And we're working on better reports, but right now this is what it looks like. I can, like, really drill down, you know, like who contributed between these two dates and, you know, how many patches, how many files. And we are improving the reports. So like, one of the plans in future is to actually have kind of like a nice dashboard, you know, for Accelerant as a whole, how many patches did we contribute? How many team members have been contributing to various, how many projects? You know, things like that. And, you know, maybe sometime soon we'll actually implement that. So I'm trying to find my, yeah. So that's it really. In a summary, how do you sustainably contribute? It just boils down to three main things, you know, understand the benefits. If you lose the sight of benefits, you can't contribute for long, you know. You will feel demotivated pretty soon. Then once you understand the benefits, once you have made sure your team has understood the benefits, build a culture around contributions, you know. Again, it could be as simple as just treating it as upstream. You know, you don't have to get very fancy about it. And then, of course, measure and improve. That's it, three simple things. And thank you all for coming to the session. Of course, you know, if you have any questions, you can ask here. Or you can talk to me at Hussain Web. I'm quite active on Twitter. Any questions? Yeah. It's just a point. If anybody works for a company that doesn't allow them time to contribute back to the community, the change in the tax laws two years ago allows a company to charge, I think, 25% of their workers' time for R&D and use it as a tax right. So they can claim it back against tax. So, I mean, they can use that 25% for community work. And effectively reduce their tax. All right. Is that for UK? That's for UK. Everybody's been working on it for a big multinational. There's a big project, a really huge multinational mapping company. And they now, all their research on R&D and use it now tax-free. That's amazing. It's basically a tax. They can claim it against tax. So, yeah, agencies... Monetary benefit, yeah. This is more like a monetary benefit. Yeah, but that's one of the reasons a lot of agencies want to go into it. Yeah. I mean, I work for an agency and I work for a team. Really? Yeah. Yeah. It's not... You can't imagine an agency like that succeeding anymore. You know, where... Again, I'm not trying to imply that you have to go out of your way to contribute. We all need to stay healthy. We all need to keep being well. If you want to keep doing good, they go together. It's not one or the other. You can't help... You can't sustain it if you just pick one over the other. And you... These kind of benefits certainly motivate. Okay. What are the barriers of R&D? It's something I've worked with a lot of developers on. They come with different backgrounds. They haven't used R&D before. So, they're good developers, but they're just starting finding styles and introducing them to Drupal.org. They haven't seen that kind of patch-based workload because they use things like GitHub. And I think that's quite a big barrier in the moment to getting more people involved. And I know there's quite a talk around moving Drupal.org to something like GitHub. I think the idea was to get lab instance, but that seems to die down now. Well, actually, it just... From what I know, it just had its recent update that it was kind of tentatively locked at Atlation. At Atlation. The company behind Jira. So, we would be using Bitbucket. But it's not a final decision. And since we made this call that, okay, we'll use Bitbucket, I think GitLab has reached out to the community again, to Drupal Association and see how can we address some of the challenges that you're facing. So, it could, again, go either of these ways. It could either be Bitbucket or GitLab. But there is a... Yeah, there is a deadline on this. So, hopefully, I mean, I do hope it will happen. And I'm quite positive it will. But let's see if we meet the deadline. So, there is a deadline to make a final decision. It's like we are tentatively going to Bitbucket, but we still have this last offer from GitLab and if we can make it work with them. GitLab has a very strong history of contributing to open source as well. I mean, GitLab, you know that it's completely open source and they're completely open source themselves. So, it would be a very good fit, but there were some technical issues that we couldn't get around. And they have actually showed willingness. So, I heard this on a podcast, actually. And the way... I'm sorry, I'm forgetting the name. Hestanet, I think, you know, that's what happens if you're contributing too long. You know, you remember the D.O. names more than actual names. But I think, like, Hestanet, in the podcast, he was talking about this and said that, you know, they announced this that they're going with Bitbucket. And the GitLab CEO, he posted a comment saying that, you know, we are willing to do whatever it takes to make this work. Yeah. So, it's not died down and yeah, I completely understand it. It's a huge barrier, you know, the patch-based workflow against the pull request thing. So, hopefully, that'll address it. But as for the previous thing, you know, we have a very strong mentoring practice at Accident as well. So, I mean, of course, that's a more overarching thing that's mentoring in all aspects of the career. But there is a huge component of contributing to open source as well over there. Have you heard of the Drupal GIF initiative? Yes. Just vaguely. For those who don't know, it's an initiative launched, I think, two years ago that Drupal agencies have slash Drupal GIF on their website and exposing all the things you do you give back to Drupal, including modules and Drupal code contribution but also events. And I see a lot of overlap with what you build. It might be nice to not only have this information in your company but also expose it on the Drupal GIF. So, right now, the reports aren't as pretty. That's the only reason, you know, that's the only thing we are working on and I do believe we have a Drupal GIF page, right? Nathan, sorry to put you on the spot here but we do have a Drupal GIF page. Yes, we do. Yes. Did you talk a lot about contributing to the organization? Do you have a reference client in terms of actually for projects you've worked on with clients do you talk to them about how bits of their project you've been able to contribute back or do you just keep it internal? It's a mixed answer. So, being an agency the clients we have so we are kind of picky about our clients as well in a way. So, the clients we have are already on board with this contribution. So, well, you know, I'm actually a little afraid giving out the names here because well, I mean, Stanford University, Strowman Open Source, then Red Hat, like they are an open source. So, well, I'm not sure if I follow the question correctly. So, are you saying that do they see the benefits? Oh, yeah, of course. So, since this is in our practice, it's part of our day-to-day routine that we, when we are working on a project, at the same time we are filing issues, you know, we are pulling in patches from the, so it's quite apparent all the levels that, you know, from the team lead on the client side to the manager level, they are all familiar with this, that, you know, that we are contributing and of course, you know, a lot of our clients are, like I said, they are already strong in the open source ethos, so they are, it's not a, it's never been a problem for us. It's like to sell this idea of contributing back to open source. That's the way business is done right now, you know, it's like the whole, you know, like get approval before doing anything or before releasing any code is, it is not, I mean, like, you know, we do understand that there is a question of intellectual property, but then we know that where do we draw the line, you know, that this is a piece of code that could be useful to everybody and our clients understand that, you know, we are using code from open source community. It's only right to give back. Give back what we code, you know, I mean, of course, there are custom things which don't make sense and of course, that's that's still not. All right, if there are any more questions, you can always find me at Hossein Web or around the event. Thank you, thank you all for coming. There's a yacking about through and action contribution stuff. Sounds good. Did you get the mic? I'm not sure there's a mic here. There are a few stickers if anyone's interested. Yeah, just a couple. I didn't carry much. Well, I have been lucky a couple of local communities generally started to stick which is great. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you very much. Oh, thank you. Thank you for coming. I hope you enjoyed it. Yeah, it's a shame. It would be nice to get the government to do that for you. Oh, that's on freelance. So you don't plan to do that? Yeah. So we can say, yeah, we'll do this in a little time. Yeah, we do. Should we? Or would Universal be the kingdom? It's a thing we wouldn't be able to do. Well, it's going to happen. It's going to happen. They can't get rid of it. I'll do a picture of my robe on the silver one. Thanks. When you mean you haven't, your cunas? Yeah. She's the one I haven't. I think so. What's the kind of deadline for that decision to move into something? I don't remember the dates. It's a couple of months. Yeah, it's been discussed. Are you going to do that? I'll work with Big Bucket. That last year, I had a crap range, I'd say. It was during a link with that last year. What's the, what's the, Confluence. Confluence. Everything was linked together. And it was annoying me because I'd do something like that. I have to create it. Again. In another thing, I'm familiar with Big Bucket. I just want Big Bucket so much easier for you. You've got a cookie. I don't know why. It's simple. And when you, Oh, yeah. The integration is really strong. Yeah. Just link it to the comment. You just had a bad fix. That fix is that issue. The issue is closed, yeah. An issue gets turned into, you know, somebody here reviews it. I'm committed. Push to like, side-back. Side-back. Actually, I'm happy with the dead-offs. Wrong. The wrong base. Committed to the right base. But we told you. You didn't realize we were working, you didn't have to change. Granted. Some people are that fun. Yeah, right. Really? Or just saying that? No, just tell you to stop. All of your content, miss all words, or visuals. Well, it could have been bad, but it wouldn't have been so bad to have miss papers. It's very good. Crap swag, this is your marketing department. You should have been fired. That sign that your session went well is that there's lots of questions in the end. Yeah, and the work. It's a good measure. Say hi. Say hi. Say hi. Say hi. Say hi to Hussein Uncle. Hi, Hussein Uncle. I don't see anyone here. Yeah, yeah, yeah. My kids. I don't see anyone here. Hussein, tell them about building your contribution culture. I don't know. We're keeping it here. We are keeping it here. We are keeping it here. Thank you. Thank you. Thank you. Thank you. Don't you have anything else? Don't you have anything else? No. Cheese. Cheese. It's so good. We're all going to need to join you. So you're going to be in that room too? Yeah. Let's go. Let's go child. Let's go tell them again. We're not talking. We'll grab them and we'll hold them.