 Okay, welcome everybody, thanks for coming. Tim and I are going to give a session about our personal experiences about the issue queues and how beneficially it has been for both of us spending time there working and helping other people. Here's a little introduction about us. My name is Juan, but I'm normally known as Juan P. I'm a developer at Civic Solar and within the community I maintain a few modules such as Twitter or OAuth. I'm also the author of the trust users guide book. So if you tweet something containing the hashtag trust guide, I'll pick a random tweet tonight and I'll let you know if you want a copy. I'm Tim Plunkett. I'm from Philadelphia in the States and I work at ZibTech and I'm a core developer and I co-maintain a couple modules and I don't have a book. Okay, here we have summarized the main ideas that we want to transmit here. The main thing is that whatever your background is, you need the issue queues and the ellipsis is that the issue queues needs you as well. No matter if you are a developer, a state builder, a salesperson, you will find a box sometimes or you will find an unexpected behavior with a module or with the Drupal site you're working on and the best place for looking for a way to fix this or to understand what's actually happening, it's having a look at the Drupal.org issue queues. By saying that anybody can help, I mean that we actually need people from different backgrounds to provide feedback because it's not just a thing of developers that they keep on submitting patches and evolving modules. We need people from user experience backgrounds to submit screenshots for example, we need designers as well and there's always a constant demand for these kind of roles to help on the issue queues. One of the things that you will learn once you start helping there is that patients is like gold there. I mean, don't expect that once you write something, the next second, you know, you're gonna get a response. If you need that kind of urgency, you better move to the IRC and ask there in one of the Drupal channels and very probably, I mean, most probably, somebody will help you out there. The most well-known channels, if you wanna know what are hash Drupal or hash Drupal support. There are some others, but those would be the more general ones. There's also a link there at the bottom, which would be a good starting point. So how to start? I guess most of you have already worked with a few Drupal sites or you are part of a corporation who works with a shop or an e-commerce site. Just think about a project within Drupal.org or a module that you like, such as, I don't know, views, for example. And open the issue queue and have a look, chime in. See how people interact with each other. Some person may have an error or a doubt that you may be experiencing the past and there you can help. So as I said before, it's not just about fixing modules or submitting patches. There's a lot to do there by just commenting and sharing knowledge with each other. You'll see that the community is very challenging. Me, for example, as a module maintainer, I see that most of the progress I do on the modules is driven by the community. It's somebody who had an idea and suggested it at the community. Some other people chime in, and it was at some point me who chimed in as well, studied the API at that point, and commit something that some other guy submitted. So at the end, you can see that everybody is trying to make the modules evolve and do more and more and more. And that's a really, really, really learning process that is fun. It's really, really fun, and that's the best thing of it. You can also join with somebody else who knows about contributing and just go through some issues with him or her, and that's very effective as well. Don't know if you want to talk about anything here. Okay, I'm gonna sit down because this mic is not reaching. The issue queue form, who has never seen this before? Okay, this is how Drupal.org works. Everything goes through this form. Whenever you need to create a new issue or update an issue, you'll see this. Most of the major things like version are gonna be obvious. You're working with Drupal 7, you're working with Drupal 6, or you're helping develop Drupal 8. The component, most projects only have four components. Code, documentation, miscellaneous, and user interface. And the category are, there are four categories. Bug report, support request, feature request, and task. If you're working on Drupal because you want to help and jump in, you might work with all four of those. But primarily, if you have a problem you need to solve, it'll be a bug report or support request. And someone asked me earlier, what is the difference? The difference is support request, you're not sure if it's your fault or the module's fault. And a bug report is when you're sure that it's definitely not your fault. You might still be wrong, but that's okay. The priority, there's minor, normal, major, and critical. This is where the whole being patient and being understanding comes in. Generally, your issue is normal. There are very, very few issues that are actually critical. Saying, I have a site and it stopped working today, and my boss is mad at me, doesn't make it critical. If you click the button and all of your users went away, that's critical. And there's a big difference there. Broken for you and broken for everyone is where you can draw the line with what is critical and what is not. And the status we'll talk about in another minute. But the one thing to be very careful about with the issue queue is the assigned field. You go in, you submit a new bug, and you assign it to yourself, no one's going to look at it. Assigned means that you have it under control, you don't need any help, and you know what you're doing. So I'll see all the time in the issue queues, support requests or bug reports assigned to the person who submitted it, and they just get ignored. So be very careful with the assigned field. Don't assign it to yourself unless you actually have the intention of working on it. The status field, these are all the different statuses with one exception, but everything starts with active. When you file a first open an issue, it's going to be active. It means it's new, someone needs to look at it. The needs work and needs review imply that there's a patch. Someone has worked on it and actually put the time forward to roll a patch. Setting it needs to needs review without a patch, it'll just get set back to active. So it's a waste of time. Going between needs work and needs review, it'll generally be between those two states for the entirety of the issue. Someone uploads a patch, it's needs review. Someone reviews it and finds a problem, so it goes back to needs work. Someone updates it, it goes back and forth. If someone sets it to postponed, maintainer needs more info. It means the maintainer needs some more information from you. They need to know what version of the module if it's used in the dev version or not. What other modules are you using? The five or six closed statuses, there's different categories of those. And if someone sets your issue to closed, don't be offended. There's probably a reason for it. Most often it'll be closed as duplicate. And there'll have been another issue someone else submitted that addresses the same problem you're having. And finally, eventually, it might get actually marked reviewed and tested by the community and then committed as marked fixed. And that's a good thing. Do we have any questions so far? Okay, okay. Yes. Yes. Yeah, so most queue maintainers either get an email or they keep track of their own issues. But yeah, someone will take note of it. If it's core, it's a little different. And I'll talk about that in a minute. But in contributed modules, yes. Almost all of the maintainers know when there's a new issue filed. And the other thing is, if it's a bug, you see an error. You just paste that error into your issue body. And someone Googles for it. Drupal issues show up pretty high on Google results. Someone else might comment on it and say, yes, I also had this error. The maintainer will get another email. So if you see the same problem as someone, you can, if it's still kind of undecided whether or not it's really a bug or not, you can chime in to help confirm that it's really a problem. Yes. Specifically about core, this applies to contribute in some of the bigger modules like date and views and whatnot. A lot of the smaller modules just work. You know, you need that module. You download it and then you have no problem with it. And as I said, most contribute maintainers get emails about other issues. The Drupal core doesn't work that way. The maintainers don't get notifications about everything because there are 10,205 issues right now. But you can, you, everyone here can actually help with core. You don't have to be a programmer. We're going to post these slides or do we post them already? Yeah. Posted the slides. These links actually go to things. And it explains where to help starting with core. There are going to be two things on Friday. This Friday, a training session on how to get set up to work with Drupal and then an entire core mentoring sprint that I'm helping run to help teach everyone how to actually contribute. So if you come to that on Friday, we'll help you get set up with Git, Drupal, Drupal 7, Drupal 8 and start you contributing. And we do that also every week, twice a week on IRC. And that's the core mentoring hours. And there's also a session, Gabor's session on how to get the most out of getting your feature into core. And that's another way to learn more about getting new things into core. That's a long URL. That's why we are pasting them. So if you want to get these links, just go to the session. There's a PDF there, which is the one we are viewing now with all the links. So you got to the point that you found a bug in your Drupal site and you want to share it with the community or you want to find information about it at Drupal.org. First, you need to know what's actually happening. If you have no idea, you can do as Tim said, copy and paste the error or describe the behavior in Google. And most probable, there's an issue already created. That means that that completes the fact that whatever error you have, it's very, very, very probable that somebody else might have it already, either sooner or some more time ago. So that's why we are empowering in saying that you should search on Google and you should try to find if there's a related issue before creating a new one because that adds a lot of workload to the module maintainers. If you know that the project that is related, for example, if you know that it's a bug related with the date module or with views, then go to the issue queue and search there. We encourage you to use the advanced search engine, which it's a link that is at the top of the issue listing and it adds extra fields. Do you want to do a quick demo of that? Yeah, let's show it. So this would be the default listing of issues for views, for example, and that's the link I just mentioned. There is such an amount of issues in views module. I mean, that's why it took so long. Those are the fields. I don't know if you want to mention anything about them too. So yeah, you were asking about how to specifically find things. First thing I do, I skip. I go to Google first, especially if you have an exact error message. If it's an error message, you can Google it. You will almost always find it right away. If it's some behavior that you don't quite understand, you're going to have to do a little bit more research. But if Google fails you, which it can do once in a while, there are a couple important ways to make this advanced search work for you. Obviously, the first thing is you'll want to put your search string in. But beyond that, you can restrict it by exactly what version it is. Don't use the exact numbered ones, because people will file them against all sorts of different numbers. You know, views 3.1, 3.2. Always just use the 7x or 6x version. You can, between the two, if you're having a problem, bug and support request is an easy way to filter it down. It's generally, if you're having a problem, it's not a feature request. Leaving the priority completely blank is the best. And with the status, if you use open issues, it includes recently fixed issues, which is actually a good thing. Issues that are marked fixed have been fixed in the past two weeks. And there's a possible chance, especially if you just upgraded your module, that they rolled over a new release, something broke, and they figured it out right away, and they've already fixed it. So if you don't look at the fixed ones, you might never actually find your bug. But the open issues tag is good for that. And when you search that, it'll restrict a lot more. Especially with views, there are so many issues. They're about halfway split between Drupal 6 and Drupal 7. And the bugs aren't generally the same. It would be in one version or the other. So as you can see, there's less issues here now. Does that sort of answer your question? Yeah, when you search on Google... Yes. So just to repeat, when using Google.com, you can put in... You can use a site filter within Google Search. And that will restrict it to only show results from Drupal.org directly. And that is very helpful. The other thing is if you do Drupal all day, Google will learn that you do Drupal all day and will help restrict your search for you. That's how you know you're really a nerd, when all your results are Drupal results first. The other thing, the number one tip to debug a module is just download the dev version. The stable releases, especially in Drupal 7, are kind of a false sense of security. It's not security in the site security sense, but that, oh, this module must have no bugs. It has a stable version. That's not true. Or this open source, everything's constantly evolving. If you are using the last tagged version, that means you're missing out on every single issue fixed since that point. So with views, it was like, the last release was in June. It's been a whole summer worth of work done. And there's a really good chance your module... Or so your bug was fixed since then. So downloading the latest dev version is the quickest way to solve your problems, generally. I've done it a number of times where I spend all the time debugging it. And I've even gone so far as to write a patch and then realized I was on the wrong version and my exact patch was already committed by someone else. So that's the easiest way to solve a lot, yes. Generally... Generally happier than I am with the four-month-old stable version. Right. The way Drupal generally works is you have different branches. So with views, you have 6x, 2x and 6x, 3x. All of the changes made to 6x, 3x are intended to not break your site. If you're upgrading from 2x to 3x, everything's going to break. It won't, hopefully not. But it could and it's not promised. All of the changes made to 3x from now on are intended to make it better. So they're not introducing vastly new things. So every single commit makes your site more stable, generally. There are a few factors that you can see in order to decide if a development version of a module is stable or not. Such as how many people... If you see the statistics, you can see how many people have installed that version. If you see the issue queue, you may see if the maintainer is actually fixing things. Or it's just leaving all issues open. You can even read the latest stable release notes and see how strict the maintainer was following the standards, how many issues were fixed. And lately, if you know a git, you can just check the log and see what was lately committed since the latest stable release to the one that is the development one. That should give you enough to decide if it's actually something that you can use in production or not. And that said, when we're developing a site before it launches, we're constantly updating to the latest dev. And then once we actually launch the site, we still want to update to the latest dev, but you do that in a test site. You do not do that on your live site. So if you got coding skills and you are helping with the issue queues, you can help on actually submitting patches and reviewing other patches. It is as important to do the former than the latter. Because normally when you submit a patch, the maintainer will wait for somebody else to review it and test it. And verify that the patch applies correctly, fixes the issue, and that the code within the patch complies with the standards. Patches that are reviewed will catch the attention of the maintainer, the first ones. And that's something we're gonna talk at the end of the session about which ways are better to catch the attention of the maintainer to get something done. There are some tools here that are mentioned with their respective links. I've just attended to a session about debugging and there is a box tomorrow at 2 p.m. about X debug. So if any of you want to know about it, I really encourage you because the X debug author is gonna be there as well. Of those links, who doesn't, does everyone know every single link down there? Really? You all know all of those things? Okay, thank you. Git is the version control system Drupal.org uses. There have been lots of talks about that. Devel is a module that you use on your local development site that provides a lot of helpers for quickly creating new content or stepping through, not with a debugger, but manually exposing parts of Drupal code and helps you write modules. Firebug is the Firefox extension to inspect the actual source code of a website. Chrome and Safari have their own built-in versions of those and the Chrome one is now actually probably better than Firebug. Drush is a command line tool to use Drupal and it can do almost everything you can do with your mouse clicking on a Drupal site and there are a lot of sessions about that and buffs. So if you don't use Drush, you really should. You can do almost any administrative task that you can click on from the command line. XDbug, as Juan mentioned, is primarily PHP Debugger and Dread Editor is probably the one most people don't know. It is a browser extension. It's actually just a Drupal project, Drupal.org slash project slash Dread Editor and it improves your browser in a way to help it makes the issue queue experience a little better. So an example would be if you see a patch, find a patch. Yeah, you picked the wrong issue. There you are. No. Go to the top. When you find a patch, that's an image. When you find a patch, it provides a way for you to view and comment on the patch in your browser without downloading it and it gives you a review button that you can click on and it loads the entire patch in a nice little JavaScript overlay and you can click on parts of the code and leave a comment and it'll post it all in with the context of where you are in the patch into your issue comment. So if you've ever seen those huge blocks of reviews by people where they have like inline comments on all the code in a patch, that's how they're doing it. So yeah, it'll look like that. That's how everyone does that. It's a browser extension. It provides a bunch of other niceties for maintainers. It'll analyze everyone who's commented on the issue and who's uploaded a patch to generate a nice commit message to give everyone credit like that and a bunch of other things. It's very, very, very useful and if you spend any time in the issue queue and you actually look at patches, you should install that. This is great. For example, when you review a patch and you want to mention a specific line that is wrong with it instead of copying the beta and pasting it, you can just format it in this fancy way. Okay, so next slide. Yeah. So let's say you found a bug and you submitted an issue and you know what you're talking about and you want someone to actually look at it now and then it sits there for like three weeks. How do you actually get someone to look at it? I can think of four ways. The first is what we call triage and it's like the medical term, but it's where you just go through the issue queue, sort by issues with the least number of comments, so mostly zero and you click on it. Someone else's patch, not yours and you look at it and you see, did they file it correctly? Is it against the right module? Is it against the right version? Did they set it to critical support request? Don't ever put something as a critical support request. It doesn't actually exist. There's no such thing. And just having one comment on there, as you said, like it will ping the maintainer and it will kind of bring that issue back to life again. And if your issue is the one with zero comments and you make all the other ones have at least one comment, someone will then look at yours. And that's what there's a lot of, this link takes you I think to the triple core one. There are something like 3,000 issues that have no comments on them. You know, some poor soul found a bug and no one looked at it yet. It's not nearly as bad as in contrib, trust me. That's the easiest way for someone who doesn't write code to help. It's like thinning the herd of what's left for them to look at. As long as you can read and understand Drupal modules, not the code themselves, you can help there. If you are a coder, if you have a patch and there's a bug, if you write an automated test, it will get committed within a week, almost always. The quickest way to get a patch in is to write a test for it. This link takes you to the Drupal.org simple test instructions. The other thing is if you go into IRC and you say, I want to help write a test, like three people will stop what they're doing to help you. You can go into IRC and get ignored for weeks, but if you volunteer to write a test, they will drop what they're doing. The other thing also works better in IRC but also in the issue queue is you can trade patch reviews. So if you are looking, you have a views bug and you see another views bug patch written by someone else, you can find that person and say, well, you look at my issue and review it and I'll review yours. The bugs go away a lot quicker when everyone's working together. The other thing is if you roll a patch and three weeks later there was another commit that broke your patch, just re-roll it. It's a nice way to bump your issue back to the top of the list but to also keep your patch updated. There's nothing worse as a maintainer than coming to an issue, seeing a patch and having it be so old that I can't do anything with it. So keeping tabs on your patches and re-rolling them is a good way to keep your issue top fresh and ready for the maintainer. Just to note here, re-rolling means updating the development version that you have of that module and see why your patch that you submitted three weeks ago doesn't apply. Maybe a line change, a comment, it can be anything. What you're doing by re-rolling is updating against the latest development version so it's still valid and someone can still apply it quickly in a local environment to test it. Any questions? How to safely patch your site. Disclaimer, safe is not a strong word used here. It's safely in my opinion. There's a lot of problems where you patch a module. You're not hacking the module, you're patching it and then a new version comes out and all of a sudden, if you update, you lose the changes you've made. And maintaining that over time can take a long time. It can be error prone. And who's had problems with that? Have you ever run a site and tried to update a module and lose all your fixes? Yeah, it's pretty rough. The way we do it at ZipTech and a lot of other shops is you create a folder in your repository called patches and you put every single time you change a module or core, you put the patch that you upload to Drupal.org into that folder and you name them well. Because if you have foo.patch and astf.patch and thing.patch, you're never going to know what module to apply to. So the convention is the module name and then the issue number and the comment number. And if you have multiple patches, it can be helpful to do a comment name, some string describing it. So this was a Drush bug with the archive restore functionality. So it's Drush archive restore, the issue number and the comment number. And that way later, if someone changes your patch, you know, oh, this was from comment five. Now there's a new patch in comment nine. So you can swap it out and always have the latest patch in your repository. And every time you, every single time you go and update a module on your site, right after you do that, when you're doing this locally in your test environment, you look in the patches folder and see what, you know, I updated this module. Do I have any patches against that? And this link down here is a sandbox I'm working on to build a site for yourself to keep track of this for you. So what you do is you just enter the issue number and it, you know, every cron run it looks and says, did someone update that issue? Is there a new patch? Did it get committed and updates your site accordingly? So you get a nice chart of, you know, what this looks like. It looks, if you go to, we're using the same functionality to help run our core sprints. So if you get a Drupal office hours.org. Can I get any from here? That's just in a new tab. Drupal office hours. Yes, that one. So this is the views one. So this is the same, right? Yeah. This site is loading. Yeah. So, well, those are all committed. So these issues are issues we're working on to put views in core. And whenever something happens in the issue queue, all of those columns get updated automatically. And at a glance here, we can look at these are the issues I'm working on to work on this initiative in this module's case. It's more about I'm using for this site that I'm building, I have these patches and then you can just check this or have it send you an email and say, Oh, the module got updated. Check your patch or someone posted a new patch. Go find that patch and see if it's better. So I, you know, it hopefully it'll make our lives easier when we are in our workflow. And I think other people might use it too. Issue queue. Oh, back issue queue etiquette. So the issue queue can be a contentious place sometimes. A lot of times if you're not patient or if other people are impatient, it can get nasty. Has anyone been in an issue where things got nasty before? Or have you ever seen an issue? Which yeah, we're, well, you go into core queues. So, but yeah, it can get, you know, people, tensions run high. They have a client who is angry because their site is not working and they need that patch committed. Yesterday, that will get you nowhere. And in some times it will literally get you nowhere. Some maintainers may just say, I'm not going to commit this. Like you were rude or you were impatient. And it's my module. And each issue queue is different. Each maintainer is different. So the best bet is to just be nice to everyone. And the number one thing, as I said before, don't abuse critical or even major. You know, like humility is a good thing. Patience is a good thing. You know, acknowledging that your problem may not be the biggest problem in the world right now and everyone needs to stop and look at it. That will get, that'll go a long way. And going back and saying, oh well, you know, I'm working on Drupal 6. This issue is on Drupal 7. I'm going to switch it back to Drupal 6 because that's what I care about. And then said, no, no, no, we're working on Drupal 7 and you switch it back again. Like that doesn't get anyone anywhere. All it does is waste everyone's time. And the biggest thing, you know, all, like, most of this is common sense. A lot of it is codified in the Drupal Code of Conduct. The Drupal Code of Conduct, which is borrowed from Ubuntu's Code of Conduct, illustrates the best ways to interact with other people in a virtual and, you know, community environment. And has a lot of, you know, very well established ways to just, if you're having a problem with someone, just, you know, take a deep breath, back away. Things you learn when you're a kid. And that really, you know, reading that every once in a while and remembering that the issue queue, people you're interacting with are people too, you'll get more done. The final thing is the issue summary template. Whenever you go to edit or create an issue, there's a big blue box at the top that says, here is the issue summary template. And it basically codifies a way to, if you go to the, just edit the issue, you're posting a comment, so, yeah. So if you edit the issue, it gives a nice structure. And the, it's- That's a new one, right? Just hit edit. It's there too. It, the problem and motivation, that link, yeah. The problem and motivation for this, and it actually gives you an HTML, it's literally a template. You copy this into every issue, or you should copy this into every issue you see. The problem and motivation, you describe what is wrong, or what you're trying to do if it's a feature request. The proposed resolution. And when you first open an issue, you may not know what the proposed resolution is, but over time, who's read through a hundred issue, a hundred comment long issue, and it changes direction like four times. It's like, first we're gonna do it this way, then two months later they decide to do it a different way. And you blow three hours reading through that. Anyone ever done that? Yeah, it can, and think about all of the other people that read through that too, and think about all the hours that are lost. So the idea here is when an issue changes direction or decides to go a different way or some new information is found, the issue summary at the very top of the issue is updated. So in theory, all you have to do is read that, those four paragraphs, and then you know what happens, and you can skip the first hundred comments, which saves everyone a lot of time. This is done mostly at core, for example. It's a relatively recent thing, and core is where it started. It's actually one of the initiatives. I think Jess is the one who started with it. Basically, one of the great ways to help contributing is just by reading what has been discussed and using this template to edit the first comment at the very top. So it really contains everything that has been discussed in a simple summary. Anyone at the Drupal.org account can edit any issue now. That's a couple months ago, but any of you can go and click Edit and edit the original post. It's common courtesy to leave their original text and add stuff above it, but not everything has to be in comments. If there's some sort of consensus, that can be put at the top so that you cannot waste everyone's time, and everyone can know what's happening. So the problem motivation, the proposed resolution, which generally comes last, but the remaining tasks says, I need someone to test this. I need someone to test this in IE. I need someone to go through and manually click and do these five steps to make sure that I'm not crazy and this is actually really a bug. And then once an actual idea or change has been proposed, especially in core, we're trying to be very careful about user interface changes. How will this change? Is it going to move the button from over here to over there? Is that going to confuse people? So views, for example, in Drupal 7, we try not to change anything because there's so many books and blog posts written that have screenshots and we just don't break those so that we don't confuse everyone. API changes I think is the next one and that's for programmers. Like if we're going to change how a function works, we have to tell people that. And we don't do that in the middle of a release but that's how you know how to update your module from Drupal 6 to Drupal 7 or Drupal 7 to Drupal 8. Someone writes down, this is how you used to use this function now use this function, etc. And that's it. Are you stretching or asking a question? Oh, you're stretching. Yeah, any questions on that? So at the end, we took from Ubuntu its code of conduct. It basically says that, you know, the better you behave and the more constructive and positive you are here, the more you're going to get. Actually, I don't know, I can share a quick experience when I once found a bug with the Twitter module and I submitted an issue with a patch, nobody reviewed or somebody did after some time but then I found that the maintainer wasn't really helping on the issue queue. So instead of maybe blaming him or yelling in the issue, you can find some very nasty ones. I started helping with other issues and asking our IRC and after some time, more people got involved and I actually started maintaining the module because the actual maintainer didn't have the time at that point to keep up with it. So during all that time, I started understanding how did it work, all the APIs it used and that in the end shows you how much can you learn by just helping on the modules you use and spending some time from your free time browsing over them. So that's the end of our session. It's the end of our slides. We still, we have just a plenty of time. Does someone have a story they want to tell or a question they want to ask or ask for, you know, yes. If you could come up to the mic for this section so we can get it on the recording. Our session title was very long. So we have put there a shorter link in case you want to add a review about it. Okay, I think it's an issue we had with a module that has, you know, a lot of issues happens when you combine multiple modules and interact with each other and I think sometimes the people would say, all that issue is only related to that module. So I think that maybe the issue queue system doesn't manage that very well and I don't know if it's the people's responsibility to take care of that like solving an issue just because it doesn't interact. I mean, you know. Yes, that's actually the hard, one of the hardest problems is when two modules don't play nice with each other and it comes down to a lot of times. So this is the other thing. If you think if one module is broken, you file it in that issue queue and if someone says it's always the other module they can move it. It can always be moved and sometimes it may balance between two modules. I had this similar problem and the maintainer said, that's not my fault, it's the other person's fault. And I went three months before they figured out it actually, it comes down to it's someone's responsibility to solve it and getting to the core of that and saying, oh, okay, well, sure. No one's wrong here, but someone has to fix this. Which module does the fix make more sense in? That's, and that's, you know, no one wants to be wrong. So rephrasing it in that way and saying which would be easiest and where's the quickest way to get this done when it comes to a standstill like that? At the end, somebody has to do the proper debugging in order to understand and demonstrate what's the best solution. I don't know. The first time I worked with core, for example, with a core issue, was because I found that a bug in fit's module which the maintainer told me in the issue that it wasn't a fit's fault. Then I went down to see tools and then Merlin of Chaos almost killed me because I introduced a bug into see tools, fixing that thing. That went, that got reverted and then I got down to core where Sun had all, had just created a fix for that, for that. Then that whole after some discussion and then it went back to see tools and back to fit's. Nine months later. Yeah, that was, that's what normally happens sometimes. You know, you keep on going down and down and down until you really understand what was happening. So it wasn't just the PHP error we were getting at fit's module. It was something that was down in core that wasn't properly right and was provoking that other modules weren't implemented. So implementing some paradigm correctly. You had a vision? Yes. You know, how do I fix this? Yes. Right. And they would fly back to me saying, oh, you can change the module of that. Yes. You can change the module and you can bat and say, I do, yeah, I need advice. I don't know your module. How do I fix it? Because, you know, even if, yeah, if you know it's your problem and you have to fix it, but you don't know how to, you can get advice from someone else just by moving it to their issue queue. And so don't be afraid to do that, especially when you know, oh, these two modules don't work well together. The other thing is you can open one issue in each queue and point them at each other and say, oh, this one, like I open one here and I open one here. Know about the other ones, like someone figure it out and then at the end one will be closed as a duplicate, but it gives both of them a time to, a chance to react to it. So someone else? What are the standard recourse options available if you submit a bug or an issue and no one is able to fix it? Just source problems? It sounds like there's a specific example you have in mind. It's happened a few times. So with micro data module or voting API module, it's not supported for specific things. And there's maybe a niche group of people who are affected by it. And there's not enough resources for the developer to actually focus on that one thing. So what is an alternative? I've talked to a couple of people about doing something like setting up a chip-in for a specific... You just took my answer. Okay, but I was wondering if there was actually an effort then to organize that? There was a discussion of formalizing a way to set up chip-ins per project or per issue. That was postponed because they're still in the middle of upgrading Drupal.org to Drupal 7, but they're actually talking about that. Ability to say, look, I will pay you to do this thing that I need done. That's a possibility. And but you can do that on your own. You can contact the maintainer via their contact form or you can go in IRC. And that's... Sometimes money is the only option at that point. But generally, a lot of times it's just a visibility thing. There are so many bugs. And being proactive about it helps. Besides, some maintainers don't even have the email notification from the issues. So sometimes, for example, if they go for a trip for one or two months or... Yeah, people go on vacation. They don't check at the ideopayatation.drupal.org. They don't realize that there is a problem there and that you need help. So that's why the personal contact form that it's available on each user's profile, it helps. It sends an email. And if that doesn't help, you can go to the Webmaster CQQ and ask there for help. Just saying that this module doesn't have any support. And you'll get a response. There's an unsupported modules queue where modules go when they don't have someone to maintain them. And people take them over all the time. Like some people will... New people looking for something to do will look through that list and say, Oh, I can help with that module. So if it just sits there and everyone knows that no one is supporting it, but no one says anything, then it's not getting done. That's actually the link. Yeah, unsupported. It used to be called abandoned, but that was too scarring or something. I don't know. Yeah, that's... Because as a module maintainer, if you're not actually supporting it, you should mark it unsupported. But marking it abandoned made you look like a bad person. So that's why they changed the name to remove the guilt from the maintainer. Actually, here are steps for people who are reporting issues, but they are not able to maintain the project. Here are some resources for you to follow. And actually here, they mentioned the Webmasters queue, which is just another project that it doesn't have any code. It only has issues related with Drupal.org. So now you all know how to use the issue queue perfectly, and they'll never have a problem again. I hope. Any more questions? All right. Thank you very much. Yeah, go ahead. Yes. It's also our topic. Just who is this Stanley Kubrick fan? I wouldn't do that.