 Okay. Welcome everyone. I guess we are two minutes into my time slot, and it was a lunch break. So people should have had plenty of time to arrive, but they will arrive anyway, hopefully. I'm Gabor Hoici, and this is bringing your ideas to fruition in Drupal Core. I did this talk before with a much scarier title. More people showed up for that, interestingly. But the reason I'm doing this talk is because I want to share my experience with the value you can get by contributing to Drupal Core, and the value you can provide for Drupal Core by providing your contributions. I'm working with Drupal for nine years. I started out in 2003 because I needed Drupal for a Hungarian website. It was not fully translatable to Hungarian, so I needed to work on that. Nine years ago, Drupal was not much bigger than Core. So when you were about to contribute, it was not really a question of contributing to Core or something else because they were score, and if you had a bug, you need to fix it there. If you've been to Dries's keynote, that was still about the time when Dries changed something in Drupal Core. He went into all of Contrib, and fixed all of Contrib at the same time. That's not really possible anymore. So that's my experience as a Core developer. I'm also the maintainer for Drupal 6, the release maintainer for Drupal 6. That's a little bit more than five years there. So I was appointed at the start of 2007, and we released Drupal 6, and I'm maintaining and putting out releases for Drupal 6. So that's the side of my experience where I'm dealing with stuff from others, and need to critique their contributions, and need to push back sometimes. So that's that kind of experience. I'm also working for Acrea. Actually today is my five-year anniversary at Acrea, which is kind of fun. So I have that experience where I have the business pushing behind me is like, this big client needs this done in Drupal Core, and then I need to interface the business to the Drupal community and kind of figure out what if the big client pays big money, but the Drupal community doesn't really want that to happen that way, and we need to resolve these issues. And it looks like I have a lot of free time on my hands because I'm also leading the Drupal 8 Multilingual Initiative, which is in a small part sponsored by Acrea, and a large part in my free time, which is about making Drupal 8 support multilingual services better. I have a session about that tomorrow on the Core Conversations Track. Should be pretty interesting for those of you who work with multilingual sites. We have a lot of improvements and even more coming. So I have an experience in there to lead a volunteer team in the Drupal community and try to get heard and try to make stuff happen that doesn't really have like a big corporate agenda. We need to figure it out ourselves and we need to have partners in crime from different companies in that area. So I have a lot of, I've seen a lot of approaches to different problems. And what I did is I created this flowchart of my thinking of how it's best to approach working with Drupal Core and we gotta walk through this flowchart in this session and you are able to download this flowchart from my site for later reference. It has basically the summary of what I'm gonna say but I hopefully will be even more colorful. So how it starts out is that you have an idea for Drupal Core or you have a problem with Drupal Core. So you either have a bright idea that you wanted to implement and you wanted to solve it right now or you have a problem and you want it solved. Now the first thing that you should consider there is what version of Drupal you're working with. You're likely networking with Drupal 8 if anybody's working with Drupal 8. No, okay. You're likely working with either seven or six. Okay. The release dates for these are 2008 for Drupal 6, 2011 for Drupal 7 and maybe 2013 sometime for Drupal 8 as the current plan. We don't know exactly. And this means that we basically have, so Drupal 6 can already be considered old. It's four years old in internet terms that's like decades. And Drupal 7 is still very actively worked on and then Drupal 8 is hugely influxed. There's a lot of changes going on and all kinds of stuff. So if you have like sparky new ideas, like make something new shiny or put a filter there or make the node admin page searchable or make the tables mobile responsive or I don't know, whatever or make media handling better in Drupal Core, then all of that shiny stuff happens in Drupal 8 or in contrib. It's not possible to add big shiny new features to Drupal 7 or Drupal 6. It's just not possible. We maintain backwards compatibility there. So what we do for Drupal 7 is we might introduce small improvements that are enhancing the release but are not breaking backwards compatibility. One example is the latest release of Drupal 7 7.15 included some entity field API improvements. So modules can use set get and handle entity language much easier than before with 7.15. So modules can declare 7.15 as a requirement for their releases and then use those new features in Drupal 7.15. There's also maintenance fixes in Drupal 7. Drupal 6 is all about maintenance. We don't add any new features. If there are some performance problems or some security issues, then we go there and fix them. So some examples of these are for Drupal 6, we fix the big performance problem with the taxonomy term listings. We changed some index queries. We also fix security fixes regularly and there are also modules and features that were removed later like blog API that are only present in Drupal 6. So it only makes sense for them to be fixed in Drupal 6 because they are not applicable to future versions. And then there is Drupal 7 where we are a little bit less strict about changes because it's not as old and we are still actively figuring it out in contrib. So we figured out some problems with the field UI that we solved in Drupal Core. We've added these new entity API functions that improve how you can use languages and we of course also do security fixes there. And then examples for Drupal 8 are endless. So whatever can happen in Drupal 8. We are adding a brand new configuration API. If you've been to the keynote, you've seen that exports configuration to YAML files and then you can get version control it or whatever version control system you wanna use and you can push it to the site and import and export and we are working with a symphony to add a lot of parts of their framework into Drupal 8. So there's huge changes going on in Drupal 8. So depending on whether you wanna have these huge big impact changes or you wanna have simple improvements or fixed issues, there's different levels of things that you can do based on what release you're using. If you wanna include a visual taxonomy selector, that's not at all possible in Drupal 6 because it's a fixed feature set and we wanna keep it that way. So one awkward example, let's say, you wanna fix the language code form field, that's a real life example that happened. There was somebody submitted a Drupal 6 bug that the language code form field as wide as the screen and it only takes 10 characters and it's not possible to type anymore. It's very misleading and they suggested that we shrink it down to a smaller size so that it's visible, that it only takes a small language code there and they submitted this for Drupal 6. Now our process, unfortunately, for the submitter is that we want to ensure that these bugs keep being fixed in Drupal Core. So if we fix something, we want to ensure it's never appearing again and we do two things for that. One of the things is that we ask you to, okay, please do this fix for Drupal 8, although you have never used Drupal 8 possibly, but we want to ensure that it's fixed all across so we ask you to do it for Drupal 8 and then we ask people or you to help backport that fixed to Drupal 7 and then ask people or you to help backport that to Drupal 6. So although your problem is with Drupal 6 or 7, what we ask you to do is to work out that for Drupal 8, which is painful at times, but if your issue is not applicable to 8 or 7, it can get easier. And the other thing that we are trying to do to help this problem is we are adding automated tests. So whenever we find bugs, we usually add automated tests when we fix the bug so that the bug never appears again. So then if the bug appears sometime later, then the test will indicate that there's the bug reappearing in that place. So depending on where you want to contribute, there's a scale of changes that you can do and there's also a possibility that you are asked to move forward to a version that you are not even using and either you need to accommodate for that or you'll need to wait through this process to get the fix into Drupal 6. So then it becomes a decision of how soon you need that fix and which way you go. And I think there's basically two ways to go here. You either want to make sure to implement it right and then it applies to all versions of Drupal possibly, you need to fix it 8 and then 7 and 6. Or you wanna have it implemented right now and you don't care about this thing. And that's the first that we wanna talk about is when you have like a business need and you want it fixed right now and you don't care if it takes three months to get it fixed in Drupal 8 and then 7 and 6, you have a business need and you need to have it done. That's a very common need. So the reasons for this is because if you submit a patch to core, it takes time. You never know how long it takes unless you put in the resources yourself to manage it through this process. Then you have a client who needs to fix right now because the site goes down or it's a show at night, it's a big media event and the site needs to be up, et cetera. You might disagree with the community, you might wanna go your own way. There's multiple modules in contrib for having admin navigation, for example, because people have different preferences for that. Or as I've explained, the extent of change might not be allowed in the branch that you wanna work on in Drupal 6, 7, et cetera. And then there are two ways to, if you wanna implement it right now, then there are two ways, basically. One is to have custom patches on your own. So basically change Drupal core in a way that fits your need and have patches for that. For those who don't know what a patch is, it's basically a file that tells you what was the old code and what is the new code that you changed the old code to. And it's just the file listing the code that you've actually touched. So it's a, depending on the size of the change, it's a relatively small text file that tells you what did you change there. So you can maintain these custom changes for yourself. Or you can use Drupal's APIs to write custom code on top of Drupal that does not touch Drupal itself and use that to achieve your goals. I did both on different projects. So for example, I've been working a lot on the Drupal Gardens project. And we have some bugs in the Drupal Gardens project that we want to fix in Drupal core. But the process for fixing them took a long time. And we need to fix it for our clients, basically. We have the same stuff. So we maintain a list of patches in Drupal Gardens. It used to be a patches.txt file. And we now use Drushmake for that to maintain the patch list. There are different tools you can use. You can use a simple text file to list all those changes. If you really want to be fancy pence, then you can go the branching path. You can branch from the core Git repository and then maintain Git branches of your changes. And then you figure out all the changes that you make. Or you can use Drushmake. The Gardens team uses this and the Spark team that I'm currently working on also uses Drushmake. And it does apply one or two patches to fix issues that we needed fixes right now. The suggested way in this case is to submit your patches to the community anyway. Even if you really need to fix something right away and it's a very custom solution and you are certainly sure it's not the best way to fix the problem. Even then, if you submit that patch to the community on Drupal.org, open an issue and attach the patch to the issue, then anybody can come around, pick your issue up and provide a better way to fix it. Okay? So you need to fix it right away. You fix it right away. But if you submit your patch to the community, you don't need to take care of your patch. If you don't want to take care of your patch, even if you don't take care of your patch, somebody might find that patch later and help you out and provide a better fix and get it to core. So if you just start out this process, then somebody might pick it up. Of course, it's the best if you maintain it through the review process and get it in core, but you might not have time for that. And then the other method of maintaining these changes is Drupal's hooks. So if you are, if you, how many of you are developers or consider yourself developers in core? Okay, some of you are not, that's good. So Drupal hooks, I'm not gonna have code example. This is like the extent of the code I have on my slides. That should be fine. So Drupal's hooks basically allow you to hook into processes that Drupal run. So Drupal has a hook menu outer, for example, that allows you to change how Drupal handles requests coming in from the browser. So it allows you to totally change how certain pages will be handled by Drupal. You can replace the built-in handlers with your own stuff. So you can replace basically whatever Drupal would do on any path or almost any path with hook menu outer. If that's a high level change, so like you can change how all user profiles displayed by altering the user profile URLs. If you want finer grained changes, then there's hook module implements outer, which is a crazy powerful hook, which allows you to turn off or replace almost any functionality in Drupal core, anything, by writing code, or change the order of how the code runs. It's crazy. There's a lot of possibilities in there and a lot of possibilities to screw up as well. But that's an almighty powerful hook that basically allows you to do anything. So if you want a module to never run on Chrome and it doesn't have a setting for it, then you can write a three line or four line module to remove the current hook from that module programmatically. And you don't need to touch the module source code. And the module would remove it when the hooks are collected basically. So that's very powerful. And there's two more hooks that I can suggest to you. There's hook form alter, which you can use to change all the form processing that happens in Drupal core, either the structure of the forms or how they are validated or how they are submitted. So you can change the actual form layout. You can add JavaScript and CSS to the forms. You can change how any field is validated on the form. You can change how the form submission happens, where the submission goes. You can change all that interaction with this hook. And finally, there's hook page alter for all the pages that are not forms. Not all the pages. So the pages that follow best practices in Drupal and build their pages with render structures, you can use this hook to change page content, remove pieces of content from the page, add new pieces of content to the page, et cetera. So there's these four hooks, menu altering, hook implements altering, form altering and page altering, that allows you to alter almost any, to change almost anything in Drupal core without touching the code itself that does it, okay? So you don't need to go there and touch it. The good thing about this one is that the internal APIs, or the thing that you need to look at here is that the internal APIs might change over time. So whatever you change in the hooks or whatever you change in the forms, if Drupal core changes the form slightly or the hook is updated to, I don't know, take care of a security problem, then your override of the hook will not take care of the security problem, so your override will be still insecure. And of course, the bigger the change you make, the more divergent you go from core, but there's full modules to use these hooks, like hook menu alter, there is the C tools page manager module, if you heard about that, that is the nickname for it as the user interface for a hook page, hook menu alter, because you can go in and put in menu paths and change menu paths and then put whatever page callbacks for them, et cetera, on a very visual way, like assign a panel to it instead of the original page handling, et cetera. So that's very powerful and there's UIs built on top of this. And still, again, if you do these as alters, then you're writing your own custom module for the site and contributing these things as content modules is very useful. There is all kinds of modules doing form altering, page altering and menu altering, as I've said. So it's very useful to put this out to the community again because you get feedback and you might go to sleep and then by the morning or by next week or something, somebody comes back and says, though, that's a very useful module, I wanna do that too and I'm gonna help you out. And in this case, it's likely a bigger feature change. So it would also be useful to propose the changes to do plate for this case. So if you want stuff implemented right away, there is basically two paths, I believe. So either you patch your modules, you directly go into the code and change the code or you use Drupal's mechanisms to avoid changing the code and write your own code to override Drupal's code. Maintaining patches can be painful and then you, it's a hard word to say you're forking Drupal Core, but you are. So when you update Drupal Core, you might have problems applying your patches again, et cetera. And for using override hooks, you need to watch out for changes as much as for patches. So it's important to keep track of when you're updating Drupal Core what's happening there. But these are very good ways to get business requirements solved right away without waiting for the community and then still have the opportunity to push it back from the community and then get some feedback. But it's also possible to screw up totally, to do whatever you need until the next morning because the client needs to set lunch. So in an ideal way, you want to implement it right and you want to get it to the community and manage it through this process. Now I'm gonna hopefully help you out in this area. So the good thing about putting this out to the community in form of patches, in form of modules, and then trying to maintain it through the process of eight, seven, and six, if you need to, if it's a bug fix, if it's a feature, then you would only put it in, put it on Drupal eight. It's because you get very valuable feedback from the community. There's a lot of back and forth on the issue queues, but most of the time it's very valuable feedback. They tell you if you're using an API wrong. They tell you if you could write this more effectively. They do performance testing. They get you all kinds of feedback, not always. We'll get to that part as well if there's nothing's going on. But if all goes well, then you get a lot of great feedback and you can learn a lot from that and improve your own solutions as well. So that's a lot of help. Then they have to use best practices, whether they suggest you have a security bug in there or you are not using the Drupal code style proper and then people will not be able to understand what the hell's going on in that code. That's also very positive because when you hire two more people to the company to help work with you, then they will instantly understand the code if it follows the Drupal way of coding and APIs. It also helps you fix it across Drupal versions because even though your business requirement right now is to fix it on Drupal 7, you're gonna upgrade to Drupal 8 sometime and if it's not fixed on Drupal 8, then you'll need to spend the time again on Drupal 8 to figure out what changed and how to fix the same thing there, which is not good. So you want to have it fixed on Drupal 8. So you don't need to face the same problem again. You can get it off your plate, as I've said and the best part, the part that I love the most about this is then you make others build off of your stuff. So I can tell you about two sneaky things that I did in the Drupal 8 Multilingual Initiative, okay? It may be not the nicest thing, but it's very good process-wise. So one thing is that we wanted to introduce language support on blocks, okay? And we knew that the blocks initiative is going to happen and they're gonna rewrite blocks altogether and they're gonna be plugin-based and they're gonna be all different. But we've seen that it's gonna happen later in the game and we needed language on blocks. And if we wait for them to do all that conversion, they might be ready, they are not yet in core, the blocks conversion, I think, they have a sandbox. So if they are not ready on time, then we need to start the work after they are ready. So what we decided is we built the language functionality for blocks this March and we got it committed this March to the existing blocks system in Drupal Core, okay? So now Drupal 8 supports language on blocks, but it's not yet converted to the plugin system that the blocks initiative is working on. But we put in our stuff and now the blocks initiative needs to work with what we have and they will take over the language implementation because it's there, right? So we get it off our plate and then they will figure out how to make it pluginable and we don't need to figure it out anymore. Okay, so it's not our job. Our job would have been, maybe it would have been harder and our deadlines would have been much more tighter if we do it later in the cycle because then all this stuff is all different from Drupal 7, it's harder to find people who know the new system and build all that stuff. But they know how they do pluginification and we knew how we wanna do language. So combining this order, it was a very good fit for us. And the same happened, a very funny thing this last two weeks, that we posted, we wanna make properties on entities multilingual like the title and the author and the publication status stuff like that multilingual, that's not multilingual yet. And we converted some entities to that system, the test entity to that system last week, it got committed. And the property work that's happening right now needed to work off of our approach to making it multilingual. So they have multilingual property support in because we were the first to get it converted. Okay, so working with the community, there's a, you need to look for what's going on and then you'll be able to help at the right time and then get your stuff moving with all the rest of the processes, which is great. And that's very enjoyable as well. This is a quote from Catherine Sensi, one of my colleagues. So she said she enjoys working toward a common cause with smart, friendly people. And that echoes a lot of what I said is that you get a lot of smart feedback and you're working together on this process to get everything ready at the same time. And then there is a comment from a CHX who said he definitely finds it intrinsically rewarding. In other words, yes, this is the right, gives me great joy. Is a testament to the feedback loop that is an issue here that helps reassure you that what you are doing is good and others just think it's good. And then everybody can build off of that knowing that it's the right solution for the problem. And it's not just what you made up quickly for some reason. And there's really again two ways to this. You either have a huge thing that you wanted to solve like triple A multilingual initiative and then you really need to start a discussion and have meetings and have groups to triple the org group, et cetera, or you want something fixed, something controllable small and then you start an issue on triple the org. And the important thing with both is that you need to manage them through a review process. You need to talk to people about your problems and figure out the targets that you wanna reach and how to get there. Or you need to manage through all the feedback that you get that it's not performant, it's not secure or it breaking these APIs or it's not in line with what that initially wants to do, et cetera. It's only going to happen if you manage it through a review process. So as I've said before, you can drop stuff on the community and it might mature into something. But if you just drop it off, then there's no insurance whatsoever that anything's going to happen to it. If you actually take it into your hands and manage it through a review process, then you can ensure that there's actually something happening. And the most common problem there that people face is that you drop it down and then there's silence and nobody's coming over to your issue. It's like, there's nobody in there. And the sad reality is that can easily happen. So if you look on triple the org, this is stats I pulled yesterday. There are over 10,000 core issues open. And the overall average for features to be solved is over one and a half years. Okay, it's relatively good in the last month because the things that we are working on are actively submitted and then solved and then submitted and solved. But if you don't actively work on something, you keep it lingering, then it will basically go into this bin of forgotten stuff or it has a very good chance of going into this bin of forgotten stuff. So this stats and the numbers are all on Drupal.org and it shows very much that if you don't take care of what you put in, then the most likely happening is that it's forgotten. But the good news is there's a lot of tips I can give you to avoid this situation. So there is issue submission guidelines that help you submit issues in a way that takes people's attention. There's issue tags that you can apply to issues that help people find your issues. Like if you tag your, if you do have a usability fix that improves Drupal's usability, you tag your issues with the usability tag and there's a very good chance that one of our usability team people will jump on the issue in a day or two. Reason for that is there is not a lot of issues submitted with the usability tag and our usability people are very actively looking at the issues submitted under the usability tag. And there's all kinds of other tags that you can use to get attention on your issue. Obviously use the proper tags if you're not using, like if you have a database fix and you submit it as a usability issue, that's not gonna help. So use the right tools. This, these two pages explain the right process. I have these slides published. Actually I have it already on the site note, but I will have them later as well. Then if you have bigger overall work that you wanna make happen, that there's these Drupal initiatives on groups.drupal.org, which are umbrellas for big work, like configuration management, web services, multi-lingual HTML5, et cetera. So these initiatives help direct work and try to focus people on things that matter most and try to, and the leaders there, if you're interested in these topics, will love if you go and you wanna like help with HTML5 or multi-lingual. Then they will love if you come because everybody needs more hands. So if you have concerns about how the web services is happening, then you can go to Larry Garfield and talk to him. And he will certainly listen to you and see what you have to say and what you wanna achieve there. There's also a summary page, Drupal.org slash community initiative slash Drupal core. It's not the most up-to-date screenshot of that. This page actually posts regular updates of the initiatives. So every two weeks we have a telephone call with all the initiative leads. And then there's a summary posted here of all the updates that we've did in the two weeks. And all the people that helped in those two weeks are all mentioned here. So this is a good place to figure out what's going on right now with the big happenings. And there is also all kinds of other subpages here where you can find people and topics that you might be interested in. Like this is a JavaScript link there that links to JavaScript issues in Drupal core if you are concerned about JavaScript performance. Then you might go there and figure out what's the active issues and where you can help. If you click on those issues, then you can find people who work on JavaScript and then talk to those people about your issues. So you don't necessarily want to work on the issues that are there. You might have your own stuff, but you can figure out the people who you wanna talk to. There's also Drupal groups for topics, different topics. So there is the entity API group for example right here. You can go there and see people interested in the entity API if you wanna improve that one. There's a MongoDB group, there's a DevOps group, et cetera. So you can find like-minded people here as well and then find what they work on. There's a less known tip. I've been trying to advocate automating this process, but I think it's pretty valuable. If you have a problem in Drupal core and you can identify the files that are related to your problem, then you can look at the history of the file and see all the fixes that were made recently to the file and there's the names of the people who worked on this stuff. So there's core, there's Richard Erickson, there's Haas, there's Dave Reed, et cetera. So you can see who's been working on these files recently, who's also interested in fixing problems in this area, who had problems in this area recently. They likely have clients who used this functionality heavily or something. This is robots.txt, it was an easy example because it's a short URL and you can easily type it in. But you can basically navigate to all this information on Drupal code.org. You go there, there's a link to the Drupal project and then you check out the different files in the Drupal project and you can see who worked on different things in Drupal core. So it's a very direct information of who worked on it recently. There's also a maintenance text file in Drupal core, but that's not very well updated. It might have good information for you in different areas, but it's not very well updated. And then there's always real-time meeting opportunities, even virtual real-time meeting opportunities. So there's Drupal.org slash IRC that explains you the IRC chat system, which we use very heavily to discuss stuff with each other. And there's Drupal.org slash core office hours, where I think yeah, where you can go and see who to talk to for different core issues. There's mentors having office hours every week, different times. You can go there and get simple issues to work on or get help from them work on issues for your own stuff. There's a trading system. You can find others to work on your thing and you can work on other problems. And it's also very useful to look at Drupal.org slash planet, which is an aggregation of a lot of the blogs from the Drupal community. And you can have an idea of what's going on here. You can get updates from initiatives. You can get posts from people submitting new modules. And if you have big ideas that you wanna make happen, you can post to your blog and then ask to be included on Drupal planet. It's not a hard, it's much easier to get included on Drupal planet than to get a good account on Drupal.org, I think. So you can get on there. It's read by a lot of people. So there's a lot of techniques that you can use to find people to come to your stuff and look at it. The key is to try and find like-minded people. And the key is to try and find people who have time. So one of the reasons I didn't suggest maintainers.text is because those guys usually very busy. So if you look at like others who work on patches or if you look at people in the groups, then those are likely have some more time because they are not already committed to all kinds of other contributions. But if then you find a lot of people and you might go to the other side of the horse, at least Hungarians have the same, jump to the other side of the horse where you have too many voices and it's kind of getting impossible to maintain. That's a sort of a good problem to have but it can also be a very stressful problem. So then my suggestion is in that case, you should look at everybody's opinion and try to crystallize summaries of what's going on. Don't let the discussion wander into all kinds of unrelated areas. So let everybody be heard but do not cater to everybody's opinions. So try to filter it down to what's relevant for the issue. Keep your issue summary updated with all the latest thinking. The issue summary is the top of the issue is on the top of the issue and anybody can edit the issue summary, go in and fix it. It's a wiki page style solution for having updated summaries of what's going on and be there on the issue. I know it takes time, unfortunately, it's a commitment that you need to make. But if you are on the issue, then you'll get to that last month stat where it takes five days to fix something and not into the old stats where it takes a year and a half. And if you have an overall plan with follow-ups for things that are not in the focus of your issue, so if you have a clear, defined scope of what you wanna solve and the rest that's not in your scope, you can submit other issues and then work on them later if people are interested. Then you can keep your head very straight and on the goals. And there's a Drupal code of conduct that you can look at. There's a very short summary of the way that you hopefully will behave on the Drupal.org issue queues and generally in the Drupal community. That even if you're in a stressful situation, you just go there and like read the five points, it's very short. And then you're gonna sit back and drink a coffee and then everything's good. And then there are process ways to deal with this big, too many people problem. And there are different processes that people use to handle these issues. So one of it is structured tagging that a lot of us use in the Drupal community is up there at the top of DrupalCon. Is that you use specific tags to tag up your issues like my initiative of Drupal 8 Multilingual uses the 8MI which is Drupal 8 Multilingual Initiative. And all the issues that we are working on are tagged with the 8MI. And then we solve those issues, we get them committed to Drupal core. So it's all happening in the core issue queue. It's easy to find all the issues related to the 8MI but there's a lot of issues. So you get pages and pages and pages and pages of issues. I think it's like seven or eight pages of issues on Drupal.org. And a lot of things are not even yet described in issues. And then there's another approach with meta issues where people open one issue. And then that's a summary issue where you can subscribe and people post updates to what's going on. And the real work is happening in these sub issues. And that can also be combined with tagging, obviously. And then all the issues are committed one by one as well. And the good thing here is that you basically have one point of contact for the work. So you can subscribe to this issue. There's a button on every issue to subscribe to all the follow ups. And you can see what's going on there. And you don't need to manually hand down all the sub issues that are happening because you get updates of what are those. So that's a good way to organize work as well. And the third way to organize work that's being used by the whiskey, the web services initiative and the blocks and layouts initiative. For example, pretty heavily, is that they make a copy of Drupal core in a project sandbox. They make a copy of Drupal core and they have issues on the sandbox issue queue. It has its own issue queue and fix all the stuff that they wanna fix or improve and commit all that stuff that they wanna commit and improve. And then all those things, when they are at a point when a set of functionality makes sense to merge into Drupal core is being reviewed. And after the review it's being merged into Drupal core. So that's kind of a different way to work because you're working on a copy of Drupal core in a different issue queue and then your work is merged into Drupal core instead of being committed one by one. Different problems have different approaches. So if you wanna work on blocks and layouts or web services, then you'll encounter that approach a lot. And then if you are basically feeling you are done, then you can of course sit back and rest unless that is not the case. If party proper cat shows up. In that case, what you're experiencing is that what RTBC, which means ready to be committed or reviewed and tested by the community depending on how long you are in the community. So it's reviewed and tested by the community. It doesn't mean that if someone believes that it's ready to go into core, then everybody agrees with that. So people can come in and say, okay, there's still a security issue there or a performance problem or I don't agree with how you did this. So you need to be conscious of that possibly happening. And you need to be also conscious of this not happening automatically if you are marking an issue ready to be included in core. It's not included right away. I'm tweeting Angie, for example, I tweeted her an hour ago to commit a patch that I really want to be included for tomorrow's demo that I'm doing for the double aid initiative, the monthly initiative. So it might need some marketing to get your patch in. But then you are basically done and then you can go party. So if you want to get involved with this process, you can get started this week. There's a contribution sprint on Friday where people will be able to help you get started on this process. And I'm not, I think it's happening in the Wunderkraut quarter contribution launch on Friday. So if you are here on Friday, we would love to see you there and get started contributing to Drupal Core. Do you have any questions? Any concerns? Yes. So you add the same kind of issue where a lot of the sites that work on Drupal 6 or Drupal 7, definitely not any Drupal 8 sites on Wunderkraut. Definitely. And it's hard to keep track of which patches you need to keep your sites working pretty much. Yeah. To make some of the patch. So can you think there's like an easier way of keeping track of the patches that are most, which are kind of like accepted, kind of ready, ready to be rolled out and keep track of those and then have a listing of patches per issue based on the conversion to Drupal? Is there a way to ease that process of finding fixes now that aren't necessarily going to report or will take time to report? Yeah, so the question was that if you have a lot of patches that you need to maintain their importance and figure out which ones are crucial to your project and then figure out which ones are accepted or like it to be accepted and how to maintain all this information about your changes. So. Sorry if I interject. That's fine. More for like I have my own system of doing it, share that information. There needs to be some kind of system added to people that work to help share that information with other people who are trying to find particular patches. The importance of your, yeah. Yes, there is no good way of like sharing patch sets if you mean you're interested in that one. There's a model called Hatch will kind of like give you a synopsis of which models you have that have been patched or diverged from before. Yeah, it's more about sharing other people. So if I spend a lot of time trying to find and fix, if I find the right patch, is it important sharing that information and sharing it with someone else a long time, right? Yeah. And maintaining that in the community somehow. Yeah, so this is an example from Drupal Gardens. I hope this is not secret information. I think if you export your site, if you export your site from Drupal Gardens, you get this file, it's a make file that we use for Drupal Gardens. So what we do is we have the, we have meta information about the patches here and comments, so these are like plain comments. And we say who updated the patch when and what did they do. So if they re-rolled it or if they updated it because of changes or if they figure that we actually use a different patch. So it has tracking of who did what with the patch when. And this is, we don't have a good solution for like tracking this in an outside system, but we have extensive comments and we do use some patches, you can see. Yeah, quite a few patches here. Where does that file? So this is a Droshmake file. So this can build Drupal Gardens with a command. So this is like downloads Drupal Core and then applies all these patches in order and then Drupal Gardens is built. So this is automated, the patch file itself is machine understandable. And then we have patches for stuff listed here. So we have like, I don't know, different like improved text trim and then we have a patch for some, my frame, whatever issue and et cetera. So we have patches for our core and contrib as well. And we have quite a few modules in gardens, really. It's a lot of stuff. It's a lot of work and a lot of value that was put into this to fix all these things and. That's a valid picture. Yes, it is. I think if you can try download Drupal Gardens and export the site on Drupal Gardens and then see, I think this file is included. I'm not entirely sure, but I think. So that's what we do. And the Spark project is very similarly organized. I'm not sure that we have extensive comments there, but we've kind of, this is not that directory. Yeah, we don't have extensive comments, but we have a Droshmake file just as much. And we have some comments on what we do. The Spark is not an old project. So we have just like short comments here and then patches. And this is on Drupal.org, so Spark is hosted fully on Drupal.org. Any other questions? Yes. Just a comment on your opinion, the file you just showed from a Drupal garden show a huge amount of patches for Drupal 4. Yes. Is that satisfactory that you, I mean, if you use them in a production system, in your opinion, are these patches ready to be committed or are they just kind of the best thing you could do at the moment for your sites? I think most of them are very good patches, but not all of them have agreement from the community of inclusion. And in our case, so maybe I shouldn't have showed the gardens make file because it might encourage you to actually use this many patches. The Drupal gardens team has very high profile people on it, like Catherine, Sansi, Peter, and Ellen Evans, a lot of high profile names from the Drupal community, so they know very well what they do. So if you have a team like that, then you can change whatever you want because you'll be able to maintain it and figure it out and you know it anyway. So in the normal situation, unless you have people who really know what they do, I don't suggest using this many patches. It's not a good idea, but if you really have a business thing to do it, then you don't have a choice at all. It's like you need to do it. But I was thinking more nicely, isn't it a pity that these aren't committed to the call? It is a pity, yes, it is a pity. We have regular, the gardens team has regular time schedule to go in and follow up on these issues and not just when there's a core update, we re-roll them. You've seen patches re-roll multiple times when there was a core update, but we also go there and try to convince people again and try to explain why this is useful and try to explain why using it in production for a year now, but it's not always works. And we don't wanna force anything on people although Acre has sometimes considered the evil companies, force stuff on Drupal. We are not forcing, we are doing patches, we are doing issues, we are arguing with the community and when we can't get our stuff that way, then we'll have our stuff this way. And that's the same thing that you can do. You don't have time for that, then you'll need to do this. But if so, all the patches that we have there are on Drupal.org. So I posted this panel patch a couple of weeks ago posted on Drupal.org, somebody in this issue got feedback from Earl and it's not yet fixed because they wanna have a more extended fix that's better for panels, but this fixed our problem right away so we could really send demo spark in an alpha state at least because our layouts are not being saved without the patch. So we can't do layouts at all if this patch is not there so it was like very core to our needs. But Earl wants to fix this in a better way and it's a very good path to fix this in a better way. So we're gonna work this through the issue process and we'll get it fixed in a better way and then we can remove it from the patch we can remove from Spark and then it will be better for everybody. Anything else? Okay. So I hope we'll see you on Friday's contribution spend and have fun at the rest of the conference. I don't know, it used to be lighter. I don't know. I can't make it. Maybe. Maybe. I got you real water. Real water. There's like non-sparkling. I mean, it's well-presenting. Kind of. Okay. I'm back. Okay. Okay. I'm back. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. I'll just use Drushmake so you know Drush, so there's a comment in there called Drushmake that explains which model is used, which model is used, which model is of this model. It can check out models from Git, it can apply patches to models. Yeah, I'm just checking to see. This is so annoying right now. It is, so... Where's the power? Power is right there. So you can document stuff in here. So it's like you're saying this is your set point X score that you need and then you're done with your project. And you can share the file. So what we have is this make file that isn't for the argument with my project. So people can see what we are changing. It might be patched. Two JavaScript bugs, it's not a lot of stuff to see. So two JavaScript bugs and then we patched. Panels, bugs.