 So I'm of course going to publish the digital version of this It's not just on paper But I wanted to give it out to you So that you can follow the session better and so if you wanted to go somewhere else You can now tell in 10 seconds if you want to stay here or go out Okay So I'm Gabo Hoichi. I am nine years with the Drupal project. I started in 2003 And I am on the famous Antwerp picture where people like stand by a fountain And it's very dark and you can almost not tell who are the faces. So I was there so so I'm an old guy here I'm a maintainer for Drupal 6 so I see that That perspective of this problem I am I'm the guy who gets in your patches and commits them to Drupal 6 and then makes the releases and decides what gets in And what's not get what's not going to get in Those kinds of things. I also started working for Acquia in 2007 kind of funny. I'm employee number one at Acquia I started working at Acquia because before anybody knew Acquia even exists and I and I was paid full time to work on Drupal 6 At the start and I'm the Drupal 8 multilingual initiative lead Which means that the Drupal community petitions my free time for different things on on the Drupal 8 Multilingual scene and I I almost had like back-to-back meetings here with different people in the community discussing different things Which are at different parts of this Handout so for those who are not here and watching this on a video This is the handout I gave out to you and it start with I have an idea for Drupal core which could also be I have a problem with Drupal core and The goal of the session is to get to the party at the end And find that find the right way and figure out how to get to that point So that's the goal of our session so it start it starts with I have an idea for Drupal core and That's usually or I have a problem with Drupal core and it's usually people post something They might might not if there's a problem They might not tell which Drupal core version it is or if they have an idea They likely have a very clear path of which version they choose But it's very important to think first about which Drupal version you want to use if you've been to trees Keynote you've seen that the different Drupal versions are at very different parts of their lifetime Drupal 8 is about to be released in 2013 as planned So it's not certain Drupal 7 was released in 2011 and Drupal 6 was released in 2008 so Drupal 6 is a four-year-old product or release at least And it's still out. They still use a lot So depending on what depending on what kind of idea you have or what kind of problem you want to solve Based on the based on the state these versions are in their lifetime The Drupal community will respond to your request or your idea in very different ways So all the shininess goes to Drupal 8 or most of the shininess goes to Drupal 8 Because that's the new upcoming version that can change anything Whatever we want to and some shininess can go to Drupal 7 Drew said in his core conversation today that we loosen the policy of backboarding stuff to Drupal 7 Which is kind of true we did backport some stuff It's not a it's not a huge change So we did not introduce lots of huge changes there And we also maintain Drupal 7 as a stable version So there's a lot of contributing models out there and Drupal 7's use more and more increasingly and we want to keep those Contrib modules stable and we sometimes introduce little Problems that we do not intend to introduce But the main goal there is to maintain the Drupal 7 version as good as possible And it's and it's absolutely the goal for Drupal 6 to make it make it be stable as possible So to get something into Drupal 6 to get something new and shiny and big into Drupal 6 is likely almost impossible for you To get something new and shiny you would better go to Drupal 8 If you want to get something new and shiny to Drupal 7 There's a process for that as well that we will get to shortly so examples for this Like if you want to go to fix something in Drupal 6 things that getting there are like taxonomy performance improvements That's kind of a funny thing because we fixed some taxonomy Speed problems in the latest Drupal 6 release and with that fix we've introduced some taxonomy memory problems In Drupal 6 that's kind of an interesting issue to follow there We also fix security Fixes and there are always things in earlier Drupal versions that are not in later Drupal versions like blog API That was removed in Drupal 7. I believe that so if you have an issue with blog API or something that you want to fix there or Slightly improved then that's possible in Drupal 6. It's not in core anymore. So you can go directly to Drupal 6 For Drupal 7 things things we would do are also security fixes and other performance and maintenance issues But also slight improvements to how it works UI tweaks. We found issues with how field configuration are how the field configuration workflow is Coded and we've eliminated one screen of that workflow for example So there's things like those improvements that can get in there easily That's likely not going to happen at all for Drupal 6 and for Drupal 8 It's brand new things like the new configuration API like basing a lot of things in symphony 2 etc So there's basically anything goes whatever we agree on we can do and we we can build it So based on what you want to do there's These are very different areas and if you want to like fix language like the language code form field in Drupal 6 That's one of the issues that I that I I've seen people encounter That it allowed the long language code and the database came out a short language code and the form field Made it look like it. It can be longer so we wanted to fix that in Drupal and somebody submitted a patch for Drupal 6 and What I'm obliged to say in that case is that please not don't do that Please fix that issue first in Drupal 8 and then backport to Drupal 7 and then backport to Drupal 6 So for issues that apply to multiple Drupal versions fortunately and unfortunately our Way of solving them is to first fix them in the latest version and then backport them as we go So if you want if you want to want to fix something or improve something something in Drupal 7 or Drupal 6 You likely will be pushed to Drupal 8 first and you'll need to figure out in Drupal 8 first and then go back That's pretty bad if you don't have the resources or if you're not interested in figuring out all the Fixing the same thing with all the changes in Drupal 8 so it kind of increases your Required involvement in fixing the issue for the Drupal community and for Drupal at large It's very nice because it means that we are not introducing regressions in later versions of Drupal So if you go to fix something in Drupal 6 It's sure that it's already in Drupal 8 and we don't need to like try to forward port it The reason we don't forward port is because we we cannot actually Assume that it's gonna be in in the later later versions before they are released next So that's basically our process. It's kind of an overhead that we need to work with so There's basically two two ways you can choose based on the version and the size of the change that you want to take You and and I've titled this with help from a lot of people with I want to make sure to implement it Right and I need to have it implemented now and There's a lot of cases you need to have implemented now And I'm I'm involved with a lot of those cases at aquia and in Drupal Gardens and I will give you a few a few examples for that and There is also a lot of good cases for I want to make sure to implement it right and basically the Drupal 6 7 scenario applies if if You don't have time to work on the the core development process You like need to have like you found an issue on your site and you need to have this fixed right now And you need to get it out of your deployment If your business needs a shorter Time to to get your fixes in if you have a huge disagreement with the community There's no way you can make it work or if the extent of the change is not allowed in the version that you are involved with So there's a lot of reasons for that and we'll see how How going this way can benefit the Drupal community at the end so if you At first seem like you want to go this way It might be a very fine decision and you'll might be able to just come back to the Drupal community with your improvements And it can be a very good experience for both of both you and the community I basically outlined two separate ways to solve this case So if you need to implement something now In Drupal 6 or 7 you likely want to either use custom patches or you want to use overwrite hooks If you want to use custom patches, I would suggest you that you track your patches very carefully Like maintain a list of what patches you have and there's two great methods for that There's documentation to branch from the Drupal core git repository and there's documentation and tools for using Patch application system in drashmake where you can say I want to use this Drupal core version And I want to apply these set of patches on that and I want to deploy that to my environment So these are good tools to track your patches and drashmake until recently actually Forced you to reference remote patches So that hopefully you would submit those patches on Drupal.org It now supports using patches from the local file system But if at all possible you should submit your patches to core anyway Kind of a funny note here is that for Drupal 6 a lot of the issue review process for me for For deciding whether it should go to Drupal 6 or not is whether you've applied it in a live environment And it worked for you in the live environment or not so I'm looking at the issue and if there's multiple people who experienced it working well and There's multiple people who thought that the they could look good Then I have a lot more confidence in getting that in so although this looks like I'm die I'm diverging from the Drupal community and I'm like forking Drupal core and I'm making my own version of Drupal what it actually means is that you are experimenting with changes and you are trying them out and You see how how it goes and then you can push it back at a community and say you work good for me It solved my problem or it improved and implemented my idea and please take it if you want it And even if you don't follow up on that patch you just submit a patch And you leave you there somebody might take it on We'll see a lot of good reasons for you to follow up on that patch and try to get in core But if you like need to go this way your business requires it or just you want to have your stuff out quick then This is not a sin Just do it, right? There's overwrite hooks in Drupal So Drupal a lot of the cases allows you to ignore stuff that Drupal would otherwise do and do something else instead in my Basic summary Drupal things that things happening in Drupal usually happen two ways It's either an HTTP request or or a drosh command or something that comes in through Or not a drosh command necessarily, so it's initially be request it comes through the menu system Which is very misleadingly named in Drupal. That's basically a router system that maps URLs to functions and Invoke them and check permissions on them So the request comes in and the menu system chooses who's gonna Execute this thing and who's gonna produce the output for this thing and if you have an issue with a concrete page or A set of pages that has a has a menu callback in the system And you can use the hook menu elder alter function to drop out what's there and put in your own stuff So this is one thing that we do Sometimes in Drupal Gardens when we want to simplify things in Drupal Corrin We want to drop some very confusing Pages or tabs from from things in core, etc. We altered those out and we think in many cases We simplify your life for you There's also all kinds of other cases like XML RPC callbacks or Cron Callbacks, etc. Which are not going through the menu system They are like generic hooks that are invoked in different ways And there's a very powerful function called hook module implements alter that allows you to do anything with hooks Like you can remove hooks from modules and add some other hook instead and do all kinds of things. It's very powerful It's very dangerous at the same time just like hook menu alter So these two who these two hooks basically allow you to alter almost anything in Drupal Corrin Without applying custom patches However, you need to copy paste the code that's there and make your modifications And then there if there's any changes in that code later in later versions You need to maintain those in your copy pasted version So the work is kind of on you, but you don't maintain patches So some people prefer this process and some people prefer the other process Now these are big chunks of code So like like dropping out a hook run implementation and replacing it with your own Or dropping out a whole page call back and replacing it with your own could be a huge amount of code There's a lot more and more targeted alter hooks like the hook form alter or the hook page alter hooks That allow you to alter the page structure inside the page or alter the Form and how the form is processed and how the how the items are validated and all kinds of other things So if you have ideas improvements additions you want to add to things you can use these hooks to do all the work Be very careful because internal APIs might change that those functions use internally There can be any number of changes there in in Drupal core as long as it's not a generic API functions Like page callbacks forms can change The bigger the change the more divergence you get from core So the harder it's going to get to tell what you change there and what needs to be updated But there is a lot of a lot of modules built almost exclusively based on alter hooks and Providing things for this. So if you've been to Earl Miles session earlier this week I think the second slide he he lead with Basically, you can understand page manager as a UI for a hook menu alter Because that's what is so you can alter what how that request is going to be processed and what's going to happen there So there's whole modules and very popular modules built around this concept of overriding all things in core So it's again not a sin. It's something that's provided by Drupal core But be careful with how you use that and you can cycle back all those changes as a country module And then you can cycle back all those suggestions as a core patch And I wrote Drupal 8 here, but if those changes apply if those are fixes for Drupal 6 or 7 then feel free to submit there as well okay So I've explained two methods for solving your problem when you need to implement something right now You don't need to cooperate with the Drupal community for any of these things You go in your own stuff. You do your own custom patch or you do your own overwrite hooks You can collaborate with the community by submitting your overwrite hooks as a set of A set of override hooks as a module and your patches in the drupal.org issue queue And then hopefully you'll follow up with with those for the community so they can get All those changes This is very good for for fulfilling your business requirements and getting fixes in very fast and moving forward But if you want to implement it right You get a lot of benefit by working with the community Because you can get feedback from the community from all your changes that you make It's sometimes good feedback. Sometimes bad feedback you need to tell It's how it works. We are humans So you get a lot of feedback on what what you did They help you use best practices. We have a lot of a lot of process to help you Use the right coding standards to help you use the right apis to help you use The right approaches to things so we have a lot of process where people come in and help you figure that out Before it can get into core. So you basically have it all cleaned up by a team of smart people I love this process because I'm So I I am a cs major But I would not be able to work in like 3d modeling or anything like that. I'm not not at all that So I I my my mind is limited to certain things and I always like that the drupal community can extend my mind infinitely So they can help help with all the stuff that I either did not have the time or did not care or did not have The knowledge to care for It also helps you fix it across drupal versions Which is great if you wanted to fix it in your drupal 7 site you write an override who occur a custom patch If you work with the community to get it in When you upgrade to drupal 8 you're not going to be um Required to worry about that problem anymore because you got it in drupal. So the community takes care for you on wards Right, so you can fix it across drupal versions. You don't need to care about it anymore Which is also the next point you can get it off your plate And if it's in drupal core, then it's going to be maintained with the rest of the stuff So you can just There's no requirement for you to maintain it anymore And the best one I think is the last one that you can make others build off of those changes So like if if you are fixing the theme functions in drupal core to be much nicer Then all the all the contributed themes would work from those theme functions And everybody would be happier with those changes So you can take those contributed themes and it will be easier for you to tweak them Etc because you fixed underlying issues which made them harder to tweak right So if you if you help drupal core fix issues then everybody else will work with that system And that's one of the reasons i'm sticking to core development all the time and although I sometimes have my down moments as well This is the reason that i'm trying to Put all the stuff into drupal core because it means that others will work with that thing And I don't need to pray for all the module maintainers to like please implement my api Because it's in drupal core and they will work with it. Okay Um, so it's very powerful Uh, you extend your uh, you extend your arms very far And uh, I got a few quotes from people. Uh, captain senzi said that she enjoys working towards a common cause with smart friendly people Which is kind of what I feel as well and a little bit different perspective from chicks He said he definitely finds it intrinsically rewarding in other words. Yes, this is done right gives me great joy so You get a lot of feedback and you kind of get a lot of um Verification that your fix is good and it's not just like something you did on the site And it works for you But who knows whether it's actually good or not and whether you install two more country modules and it's going to break down in flames Okay, so it's very good for uh for your work long term And I uh set this up into two different Branches as well. The first is you start an issue the second you start a discussion It totally depends on the size of the change you want to make So if you want to do content staging in drupal core starting with an issue Is likely the worst thing you can do because it's a huge topic It needs to be broken down to different things you need to have a discussion with people either on Either here at drupal con or on groups of drupal at org or on irc, etc I like try to get opinion and socialize your idea Share it with people and get feedback and then when you have It broken down you can start working on issues If it's a small problem like fix the damn language field to be shorter because it's short in the database Then you start with an issue. Okay, and then in both cases I've said before that if you have a core patch you submit it to the issue queue And if you leave it alone, that's still fine But if you want to get all these benefits here, you need to manage it through the review process It's not like you submit that patch and then Armies of drupal people will jump on it and fix it for you because drupal core They care about fixing those things for drupal core. It's likely not going to happen What's much more likely going to happen is that nobody cares about it at all You submit an issue and it sits there for months and nobody cares about it ever So if you look at the issue stats for drupal core, I pulled this from from drupal.org Bag reports overall on average Are not fixed for 33 weeks Are not in are not getting in to the fixed state for 33 weeks feature requests A lot a lot more time. Okay So this is on average So there's a lot there's a lot more to to the other to to the other end where there's like years and years Things are not fixed. So if you just put it there and wait for someone to Find it, it's not going to happen You need to maintain it through the review process find people get get those reviews manage all those reviews Put updates and then manage it to get it in. It's a lot of work But you get all the benefits that I mentioned before and the drupal community gets all the benefits as well And there is also a 9,500 core issue. So you submit it Likely nobody's going to find it. So what are you important to start the issue? In a way that people can identify what is about There is the issue submission guidelines on that url. It's in the head. It's on the handout as well And there is a most common issue text document right there So drupal people like to add all kinds of meta information on their issues Why it's related to what kind of problems it solves performance problem or whether it needs tests or whether It's related to any initiative etc So those are those are what we use text for and the issues submission guidelines explain how to use different status of issues And the different components that we have i'm not going into those details here Because that would take 45 minutes alone But that's where it's documented if you have any questions you can come up at the end What i'm more interested in is how you get your issue noticed So this is like submitting it so that so that people understand why it is but then you need to get people There's a lot of ways to get your issues noticed There is drupal initiatives that are official initiatives for drupal core and there's a very few of those mentioned Compared to all the things that's going on for drupal core is just a tiny number of things But they are they are things that cover a lot of big Big problems, so there's configuration management web services design multilingual html 5 there's mobile there's layout So there's all all those things if your problem or idea maps to these initiatives You can find these people here and their respective groups you go to the news link and you can find Who's working on that and how to get involved? And you have issues linked there that you can look at all their issues And you can get your issues into their issue queues if it's related to their work, okay There's also a lot of other things that people work on. This is not a very up-to-date page But jubu.org slash community initiative slash drupal core has a lot more initiatives that are not Official initiatives, but people work on them. It's a lot of sub pages of different things that people work on and who to contact and What they plan to work on etc Bear in mind that this is much less Up-to-date compared to the drupal 8 initiatives page So this would require a lot of love But it helps you identify people who are interested in things and what they want to work on etc to plug in your Things there's also interest groups on groups at drupal.org If you pick working groups in the group type, then you get Groups like the drupal 8 blocks and layout everywhere initiative Or entity api or a space advocacy Which is like lean out a drupal core patch thing Etc so Although I do have rocket ship for drupal core issue issue overviews now that I I connect the dots so So there's all kinds of working groups That you can choose you can join and find people there who are interested in the same thing So if you have an entity api thing then you can go to that group And find people there and post there if if you think that your your idea Is interesting for them a very interesting Approach that I I'm not seeing a lot of people use is go to the history of the files that you want to change This is an example of robots dot text, which is not a very good example, but it's a very short url So that's why I chose that one So I can put the url on this slide. So you go to drupal code org Pick the drupal core branch Go to the file and look for its log And the log tells you two very important things One is who worked on this file. So there's all the names of people who worked on this thing Okay So those people are likely interested in changes to this file There's also all the issue numbers that were discussed regarding this file So if you find issues that are similar or or Or even reasons for the bugs or problems that you are trying to solve Then you go to that issue and post a comment. I found a related bug Please see here and help me fix it And all those people are also likely interested in more fixes to this because they they cared about it They worked on stuff for this So you can try to find them and try to talk to them about your changes Again, robots.txt is not a good example. It's not like something that people are passionate about Just like people find bugs with it and they fix it, but That's basically how how to find like concrete people who worked on on stuff And that is again, if you've been to dracyscore conversation There's a lot of talk on data and how we have a lot of data that we don't use and this is This will be very good data I had a discussion Last two book on with people that if we can mine this data and like put on people's profiles That this guy worked on robots.txt and the entity thing and etc And you can like find people who worked on the entity thing you click on the entity thing And it could list all the people who were participating in those issues, etc So we have a lot of data We don't have a lot of tools for you to mine them. You need to manually look at these people And when you have people you can find these people on irc There's drupal people love using irc. It's a it's a real-time chat system Not hard at all. This is explained here on the drupal.org slash irc page It suggests you clients to use it should suggest you rooms And how to get there so you can find people there You can try to email people as you it's usually not going to work So if I don't know your name and you email me I can tell you I might not answer that email Okay, I get a lot of email If I know your name, I like I more like the answer that email if you send me an issue url with that email That's perfect. I'd likely go to that url and we'll either follow up Either follow the issue or or put their comment if you send me an email explaining your problem Not good. There's also core office hours Which is a real-time meeting where you can where you can go and you can Pimp your issue you can send in your issue and you'll maybe get another issue to review And you'll experience the whole review process and How you can how how you'll get some feet some feedback on your stuff and How we try to connect people and how we try to find people Interested in that and you can learn a lot from there And improve your own approach to finding people for your work if you work on big improvements There's Drupal planet Where a lot of cool stuff is posted about Drupal core if you want to fix the language field length Do not post a block post about it. You will be kicked out of Drupal planet, but if you're working on bigger initiatives Like mobile first Drupal themes then you would you would want to post about that so you get the word out People go there you can post issue links here You can post an overview of what you work on and then direct people to your issues, etc So you can get a lot of A lot of visibility on Drupal planet I haven't checked recently, but it's an insane amount of people subscribed to Drupal planet. It's just it's it's unbelievable So there's a lot of ways to get feedback on your issue. Okay, so you need to find people to get there You have ways on you have ways with the initiatives the non the non official initiatives looking at file history going to irc going to office hours Edward has your stuff on Drupal planet at Drupal con at buffs Etc and then you have a different problem because now everybody is on your issue and they post all kinds of stuff And and there's no there's no no end in sight Okay, so um, I think a lot of you would love to have this problem Uh, but if you post uh, if you post very interesting stuff, you might end up with this problem And it equally requires some uh experience and people skills To be able to move forward from this point just like that nobody cares about a point So when everybody cares about it, you're gonna get a lot of feedback Your your issue might go to hundreds of comments Um, I think you should consider all feedback But uh, do not cater to everybody there's gonna be all kinds of people wanting to sidetrack your discussion to all different All kinds of different ways So try not to cater to everybody. Uh, try to stay try to keep your issue focused And resolve it as um as focused as possible Instead of letting it explode Keep your issue summary updated people come there's uh, so the issue summary is the original version of the Issued that as was submitted and then everybody can go and edit that summary to update it to how the latest discussion and decisions are shaping Um, it's very good for new new people coming in to like see there What's be what what is already decided and what's still to be decided etc So they are not uh diverging as much from the main topic that you want to keep And yes triple core development requires you to devote serious time sometimes To that so try to be present on that issue and respond where needed Um issues can get stuck when when you don't we you don't respond to questions or concerns And it's just it's around and nobody knows where to go And if there's a lot of side tracks that are appearing then have an overall plan with follow-ups That you're going to fix later It's not the task of this issue to fix them But you're going to fix them later and there is a triple code of conduct that we have for um for working with the triple community The reason I bring this up in on this slide is because these are the discussions where The air can get very hot very fast And if you can keep in mind that all those guys are people and all those guys are well-intentioned And they want to have your stuff be good for triple core Then uh, then you should all be good So for these big things people do different approaches to to try and try and Get their stuff in triple core And these are three approaches that i'm i'm seeing uh working with drupal 8 and they have different benefits and and drawbacks um My initiative drupal 8 multilingual initiative is d8mi what we do Is we tag issues with d8mi So all issues related to d8mi that we know and we identified are tagged with the d8mi tag So people can find them and we work directly on the drupal.org issue q on the drupal core issue q And we get we fix stuff issue by issue We actually break down a lot of things to like small Small smaller steps like introduce these three special language constants and then we have an issue for exposing them on interface And then we have an issue for revisiting how it affects existing code and then we have an issue for I don't know what So we break down things and do smaller chunks and we get a lot of feedback from people in that way And we get it into drupal core and why I love this method is because then everybody needs to work with our changes because it's already there Um, and it's uh commit by commit in drupal core So we use I I named that structure tagging because we also use other tags to identify sub initiatives under the main initiative So there's all kinds of tags that we use for that. There's the meta issues approach that the entity api Um Work uses for example where they have a meta issue that summarizes all the problems and it links off to sub issues And it and it tracks and it gets follow up and it gets follows from people and it sometimes posts common summaries of what happened Um, which is kind of also good and it also works in the core issue q and gets commits individually in the core issue q What the configuration management initiative and the whisk initiative do is that they Have a drupal.org project sandbox for their work And they take drupal core and then they and then they double around in that they modify all kinds of stuff And discuss their own issues and make their own comets there Make their own branches for different approaches. So it's it's very flexible It allows you to try a lot of things And then when they decide that it's ready for for the people Um, it's not very well Visualized here, but they actually submit an issue for a drupal core Propose it and then it's and the whole thing as built is discussed there And then if it's okay, then it's merged in based on their sandbox commits. Yes Yes, so there there is a merge process and there is a patch process I think cmi the cmi patch used a merge process recently that got in got in I don't know two weeks ago or a week ago and there's also like Summarized patches of all the changes in in one big patch that are submitted in drupal.org issue q So the benefit of this is that you can play around you can branch to different areas You can experiment with what you want. You are not not limited by Breaking stuff down and making small changes and then building on your own work Because you can experiment whatever you want But the but the inherent problem is that then you need to Discuss the whole thing with the rest of the community who was not involved with your work So there is good things in in all the three approaches The for d8mi the structure tagging worked really well I think for the scale of changes required for cmi and whiskey they could not be able to do that process in any way So if you want to work on drupal core There's even different models to work on different changes for smaller changes The issues work very well for bigger changes You need to have those discussions and you likely have a sandbox to work on And then when you manage yourself all through this process you get your patch as rtbc Which does not guarantee that's going to be committed It's not very unlikely that it's bumping back to any previous state Or even disregarded altogether as happened Quite a few times and even if it's committed sometimes it rolled back later So So even if it's rtbc You it means ready to be committed or reviewed and tested by the community Depending on how long you are in the drupal community it meant different things through the life of drupal.org So reviewed and tested by the community is the is the current version Um So it just means that uh the the people who looked at it thought that it's good for drupal core And then there there are a lot of um people looking for the queue that has these issues and go there and say, okay This is not good. This not performing well by just reviewing it or it does not match documentation coding standards or whatever It's going to be pushed back in those cases and you go in and fix that And there's also could be any extended time to commit the other issues are processed first. So It can't take some time. But when it's done We reach the party part and And you're and you're there and you contribute it to the drupal community Uh, if you want to get started on that and you haven't Done it before there's all kinds of sprints tomorrow There's uh jess also leads the core office hours Sprint tomorrow so you can go there and she's gonna Take you forward from the end of my session. I believe tomorrow on the sprint To get you into the Into the nitty-gritty details. So that was basically what I wanted to say So We are open for questions any questions Yes So I always wanted to get involved with core development or any, you know, drupal module development as well Um, and I have you know, I run a drupal firm. I have like 20 clients. We have our own process of I know patching them, you know maintaining them as well. But when getting involved in uh, you know I guess any of this management for core these contributed modules you guys use git I use subversion my development environments aren't like your environments Now I was wondering if you guys had any documentation or our workflows like this of How to deal with different things that might come up like somebody patches your patch Or you get your patch or how to set up your development environment in an ideal way to be most optimal Sure, I don't think drupal core development actually requires any special development environment Um, what I use is actually like totally Totally everyday thingy So I use this very free tool called acquit after I stop Uh, it looks like a marketing plot, but it's not And I use it for drupal 8 development. I have two copies of drupal 8. I have a copy of drupal 6 I have a Copy for my localization development in drupal 7 and I have a gardener and gardener's copies for my work um, so So there's no special requirement. There's like very simple tools like this that you can use just to Um Just to work on core. I I don't think I have I have anything that that would that would not be available off the shelf Um, I don't have any URL in my head for Documentation on how to set up all this environment for you. I know I know the next next gentleman standing in line is working on the boston initiative Which is which is um a step by step Um Documentation and Well, it's not really documentation. Well, he's gonna explain it So he's working with the boston initiative and they have very good tools for you To help you get started and to spread this knowledge and help others get started as well Thank you. Why thank you for that very kind introduction I was invited to speak here because no, I'm just kidding. Sorry. Um, I don't want to hijack the questions but this was such a great presentation and uh, since Learn drupal.org actually came up In conversation Learn drupal.org is a community initiative to put the great information That's coming up in in sessions like this and Lessons that people want to build themselves to help people go from Whatever level they are in contributing to drupal to also being seeing how they are able to contribute to Core and you can do that at a number of different levels. So here is my request for you and for your audience Gabor, if you're willing to make your slides, which are really wonderful Available and perhaps maybe occasionally answer a question or two about the best way To have these things go into a ladder It sounds like there would be some great step by step lessons that would come out of this Then also since I promised to answer your question and thank you for giving the opportunity The first couple of steps at learn drupal Dot org address getting set up specifically on dev desktop. There will be other Development environment discussions that end up becoming parallel ladders, but that one happens to be on learn drupal.org right now Thanks Thank you Yeah, I I'm jess. I'm on drupal.org and I do the core office hours in case you missed that earlier So I'm also going to actually answer the question about development environment a bit in that Another way you can get a development environment set up if you want to work on core is come to the sprint tomorrow It starts at 9 a.m. And we'll help you set up Development environment and actually it doesn't even need to be nearly as complicated as like Your environment was way more complicated than mine. I I just have like map and get on my computer and I have I just take have a clone of core and I branched sometimes It's very very simple. So you really don't need anything special that you wouldn't you wouldn't do for the trip So come tomorrow It's also a great opportunity for me. I'm not you know that that blob the head of the top said I have an idea for drupal I don't have ideas for drupal. Um, I try to help fix other people's ideas for drupal And that's what the sprint tomorrow is about it's about solving that it's about Solving the nobody cares problem for that to help other people's ideas get in core So if you're just getting started out, maybe you don't have a great idea for drupal Maybe you might someday come to the sprint tomorrow and we'll help you help other people's ideas get in In small manageable chunks. You don't even have to be a developer Um, there's lots of stuff that you can do to help with other people's ideas Even if you're just a slide builder, so um, please come tomorrow And thank you go for the great session because the slides I think Captured the core development process in a way that I don't think has really been I led to say that um, there is not always I want to contribute by I have an idea It could be also I have development time that I would like to devote for your community And one question I I've been trying to Do that several times and I okay I'm going to spend one or two hours starting to help on some issues and the question is where do I start Because you start on one topic and you see those huge issue which 100 comments on it and you say okay I will spend four hours reading the the comment and when I reached the bottom I just have to reload the page and there are 20 more comments there Yes, there's a lot of ways to get involved core office hours is a great way to get issues that point it at you That would be good for for reviews and might not be that complex There's also the novice tag on triple that org so you can look at issues tag novice Which are there for Those who are are getting started in the community or only have half an hour to develop right there and they can still contribute at that time and If you want to work on Work on any of the big projects and need to have something for you. What I did is that I Or what not not just what I did So what the initiatives do for triple that I for example is that they hold meetings every two weeks on irc So you can go there and you can say you want to get involved in this initiative And then the initiative leap can help find you a task that is good fit for you So I've been tweeting about my initiative and looking for people and also on the irc meetings I got people and then I kind of had the had a side discussion with them one on one What are you interested in? What are you? What's your experience? What kind of work you want to do and then I paired them with one or two issues And then try to help them through those issues and try to get them in And it turned out to be very successful for some people Which is good. So you can go there and and that's for help there as well and the rocket ship rucks for that Also Yeah, thank you Just one comment about the 400 comment issue if you take the time to read an issue that has 400 comments and you spend that That that yes For your take you've just taken two hours take another 15 to 30 minutes to write a good issue summary Post that issue summary then you save every single other person on that issue that time for reading that issue So please always always always do that and that's something we do in office hours, too Yes, I haven't mentioned sharks yet. So sometimes core issues can get pretty intense Do you have advice for sort of staying motivated and staying happy? I guess working on Yes, so that so I'm not sure people heard the question. It was not it was kind of yeah So the question was I haven't mentioned sharks actually and uh, and sometimes issues can get very, um Very hot and and intimidating and if I have any suggestions for people who who Who kind of burnout in that or or or kind of feel I'm motivated by that What I do is that I work on all all kinds of things. So when something gets very hot and and and people are are Are our bike shedding into death then I can just ignore that and go somewhere else and then do something happy there Instead of just going off from Drupal and not doing anything and that maintains my good My good my good mindset because I have success So I go to somewhere else and I maintain the maintain that I'm I'm successful And I'm contributing to Drupal core and I'm and I'm working with people and we are doing good stuff And then I will come back to the other thing later when it wins down if if it does and And then and then try to take it from there. So what I try to do is that I'm I'm trying to Trying to try to find other ways to feel successful Instead of like trying to get bucked down in one thing and then burning it burning down Burning out with that and going away. Are there any plans to improve or any ideas to to improve this? issues discussing issues because last Drupal 6 release an issue was added that was that talked about nearly two years to get in Are there any ideas or plans to improve that? So the question was whether there's any ideas or plans to improve issue Issue time life so to get getting issues Sooner and there was an example of a Drupal 6 issue that was there for two years and just got fixed um Drupal 6 is very Scary in a way that there is no testing system and there's a huge shortage of people using the development version So i'm very reluctant to commit big or scary looking changes and even like the rdbcq is growing big in Drupal 6 because I rely on crowdsourcing for testing. So I rely on you suffering a little bit Before before before we can see that it actually worked So we we need to have people trying it out and confirming that it worked because we don't have a system to test it And we don't have a system to to verify that it will be good And even then we make mistakes that's like the the last Drupal 6 release only fixed two bucks Two and both of them were introduced in the previous release So we make mistakes, but we are humans And so we don't have that testing system. We do have a testing system in Drupal 7, which is also not perfect But it speeds up a lot of things and it'll allow Drupal 7 to make a lot bigger changes And and that's part of the reason that we can make even bigger changes in Drupal 8 So for Drupal 6, I don't really have a good solution there, unfortunately If there are no other questions, then thank you for those who arrived later. I have a handout version You can take this session To home with you So if you don't have a handout you can get you can come forward and get a handout and walk off with that. Thank you