 I don't know that I have, I have some ideas about ways that we, like, I don't have any tips on how you can go right now and learn Drupal easier, but I have some thoughts about how we as a community can make it so that the next time you need to learn Drupal, it's a little bit easier. So yeah, it's definitely not a rant, but I also don't have any, like, if you go home and do this, tomorrow you'll learn Drupal, no problem, because the truth is you won't, it's just really hard to learn. Yeah, maybe. Alexa, teach me Drupal 8, and you'll probably, yeah, you'll just get a bunch of fish jokes. This session is, um, why is Drupal so hard to learn? And this is in the core conversations track, so the idea here is, in theory, I'm gonna give a short presentation, so probably 30 minutes or so, and share some of my ideas about why Drupal's hard to learn. And then we can have a bit of a discussion, in which I would love to either hear people's ideas about things that we can do as a community to make Drupal easier or about your experiences learning Drupal and things that you found frustrating so that we can kind of record those and know that these are problems that we need to address in some form in the future. My name is Joe, Joe Shindelar, I'm EOJ The Brave, it's just Joe spelled backwards with the brave added on because back in like 1995, when I was signing up to play Warcraft, I needed a name that sounded intimidating, and that's, I thought this will inspire fear in my enemies, and now I try to use it in online communities where I'm not trying to make enemies, I'm trying to be friendly, but it's still my name. I've been doing Drupal contribution for a really long time. In particular, I work a lot on Drupal's documentation, and so the learnability or the idea of how people experience learning Drupal has always been really fascinating to me. I also have a lot of thoughts about how that whole thing plays out. Who, who, you guys, the people that are in the audience, I think it's a combination of people who are contributors to Drupal who are interested in learning about a new, someone's experience when they're learning Drupal so that they have an idea about, like, what the things that they're building look like to someone that's learning it, and your people that have spent some time, you're somewhere in the process of learning Drupal. This might be new, you might be just getting started, you may have been doing this for years. Either way, you're probably running into some frustration points along the way, and I want to talk about those. I work at a company called Drupalize Me. Drupalize Me produces Drupal training, mostly videos that we are available on our site. We also do a little bit of in-person training. I've been doing this for a really long time, and a lot of my experience and the things that I have to talk about sort of stem from the fact that I am basically, like, I've watched people in person throw their hands in the air and frustration and slam them down on the table and be like, screw this, I'm done with Drupal, I'm never coming back. And it's a, it's, that's a moving thing. It makes you go, oh man, I created this problem. Maybe I should help try to figure out how to solve some of that. I also want to say thanks to Drupalize Me for making it possible for me to be here and talk about these things. My work helps make it possible for me to travel to Baltimore and participate in the Drupal community, which is awesome. My goals with this hour that we have together is to talk about and try to answer some of these questions. I want to share some sort of anecdotal evidence I have about the experience that people, people go through learning Drupal and why it's often perceived as such a challenge. I want to talk a little bit about the types of things that are currently being done in order to ease that learning curve, as well as things that maybe we could be doing more of. I want to hear from people that are somewhere on this curve about what your experience has been and what would have made that easier or what you would like to see more of in the future. And think a little bit about as a community, what kind of things should we be putting in place? Sort of like Drupal Core often has these initiatives, like we're going to add media to Drupal 8 initiative. Is there a need for or room for some kind of initiative around the way that people experience learning Drupal? And this is one of those. I think the answer is yes, but I also have no idea what that is, so maybe we can work on figuring some of that out. I think it's important to talk about this stuff. I think it's important for the people that are working on Drupal, Drupal contributors who have the ability to affect change on Drupal to understand what it's like to be new to Drupal. Not even necessarily be new to Drupal. You could have been contributing and participating in Drupal for years and suddenly you just need to learn one new module and that experience can be really frustrating too. And it's good for those of us that have been doing this for a really long time to remember what that experience was like. I also think that we as a community, the easier we make it for new people to get involved with and to learn to use Drupal, the bigger our community gets, the further the project goes, the more that as a community we can accomplish, the more Drupal gets adopted, sunshine and rainbows all around. And finally, I think it's important to talk about this because at some point in the future, you and I are probably going to have to learn something new about Drupal and it would be nice if that was easier. One of the things that I found when I was preparing for this presentation and thought about this stuff in the past is that when you talk about learnability or how hard it is to learn something, it's kind of hard to measure. And at least personally, I don't have any really good ways to put a definitive number on this. I don't know like what's the KPI for learnability. This is definitely a thing that I think there are probably people that have experience with. And if that's you, I would love to hear a little bit more about like, how do you measure whether something is hard or not? I think you can do some things like you could, there's sort of objective things we could do like static code analysis where you can run a tool that will tell you all of the different possible execution paths through the Drupal application and you would be like, all right, it's a really large number of them. I guess the larger number means that it's probably more complicated. And then there's things that are sort of subjective that you can't really measure like for some people, the term node is really hard and confusing and for others, they have some experience in the past that taught them what that was and they bring that with them to learning Drupal. So learning what a node is is no big deal for them. But anyways, I think that kind of stuff makes it hard to measure whether or not something is easy to learn. All right, so Drupal is hard to learn. Sorry, it's true. When you're setting out to learn Drupal, I think one of the things that we could do a better job of as a community and for ourselves is setting expectations about what it is we're going to need to learn. You might think, I'm going to learn to be a Drupal developer and it'll be great. I'll get a job. But what you might not realize is that there's a whole lot of other stuff involved in learning Drupal. You can't just learn Drupal. You need to learn PHP. You need to learn MySQL. You need to know HTML and CSS. You're going to get into some systems administration stuff. Maybe not much, but you're definitely going to have to set up a local host to work on this stuff, which is basically the same thing as setting up a server that's going to host your production site. It's all of these things that when we go into it, we're not necessarily thinking our part of learning Drupal. They're not even necessarily Drupal things that you have to learn, but it's like background knowledge that you have to have. It's important to not forget that for people who are new to Drupal and learning it, that's part of what they're learning as well. They're not just learning how to write a module, they're also learning PHP. My understanding, or what I've heard from most people, is this is what it's like when you go to learn Drupal. This is an image that's actually been around for a really long time in the Drupal community. The joke here is sort of like, Drupal has a really steep learning curve, especially in comparison to ModX, which I don't even think exists anymore, Joomla and WordPress. It's supposed to illustrate this like, for whatever reason, in the broader audience of people that are using web CMSs, Drupal has this reputation for being really difficult to learn. I have some ideas about where that comes from. This sort of illustrates that. It's like, well, if you want to learn WordPress, it's kind of easy at the beginning and then it gets a little harder and then you just kind of coast along and then apparently you can get a job doing WordPress sites. But if you want to learn Drupal, you need to climb up this cliff and there's an overhang and there's probably someone waiting at the top to kick you off the cliff and be like, no, I'm sorry, good luck. Try again later. If you can finally make it up there, that's awesome. You can do a lot with Drupal, but you have to finally make it up there. I always laugh at this image. This image also really frustrates me, though, because while it's super prevalent in the community and a lot of people have seen it, I think it paints the wrong picture of what the experience is like for people that are learning Drupal. And a lot of the reason that Drupal is hard to learn is just because we're told before we even set out to do it, well, be careful. If you're going to learn Drupal, that's really challenging. You might want to consider WordPress instead. So I think it's important to think about that. I also think it's important to think about and point out that, to some extent, a system that's sort of as infinitely flexible and incapable of as many things as Drupal is capable of is never going to just be easy to learn. It's not like you're just writing hello world in an HTML file and uploading it to a server, which even that in itself could be hard for someone, but a tool like Drupal is capable of so many things, and with all of that capability means there's a certain amount of things that you're just going to have to learn in order to do that. It's not unlike learning to speak a language or complicated mathematics or science. Those things are necessarily hard because they're solving hard problems, but once you know how to use them, you can do some really cool things like write poetry or write a novel. So rather than the earlier image, this one, keep this one in mind, this is what I think the learning curve for Drupal actually looks like a little bit more. I think this is a more realistic illustration of the journey that people go through. This is based on an article from a guy named Eric Troutman that wrote for the Viking Code School blog. There's a link down here. The article is why learning the code is so damn hard. He walks through some of the things that I'm going to talk about here. One of the things that I've tried to do is apply some of that thinking to Drupal as a way to understand the way that we approach learning Drupal. What this is showing, across the bottom, you're measuring competence. You think of competence as like, this is your ability to do something. I can actually accomplish the thing. I can do this versus confidence, which is our vertical axis. You can think of confidence as like your trust in your own ability to do something. Competence is I can do this. Confidence is I think I can do this. When you're learning Drupal, your confidence kind of goes through a wild ride of like, I can, I can't. Holy cow, I really can't. Maybe I can. Things are getting a little bit better. Your competence just sort of progresses linearly across the bottom. It's like, yep, you're getting, you are genuinely getting better, even if it doesn't feel like it at some points along the cycle. I think it helps to break this down into a couple of smaller phases. So the first one, we're going to call the hand-holding phase or the honeymoon phase. When you first go out to learn Drupal, it's, you, your confidence increases really quickly as you learn some basic concepts like, what is a node? How do I log in? Things that you can learn from really highly polished resources like the tutorials that are available and Drupalize me, where you can follow them step by step. And if you do the things that the steps say, when you get to the end, like, your screenshot will look the same as mine and you're like, holy cow, I built a view. And that's all well and good. You did build a view and you learned some important concepts, but you're also following along with a tutorial that walked you through every single step of the process. And in that, you're, you get this sort of like rapid increase in confidence, which is good. Even in that, though, I think there are some things that Drupal could be better at. So we have these resources that, you know, make it maybe easy to understand what a hook is and how to implement a hook or understand how to add fields to a site. The things that we can improve for Drupal in this phase tend to be around if it's around its intuitiveness. So a user interface that's intuitive to use is going to allow you to more quickly pick up and understand the basic concepts. Back in 2015, we did some formal usability testing of the Drupal 8 user interface. And at the time, one of the things that that turned up was that for a lot of people, Drupal has this really weird mental model where in the user interface, we tend to expose all of these things that are kind of implementation details, like the fact that when you go to choose a new field type to add to a content type for a node content type, it's like, do you want a number or a reference or some text? And you're like, no, I want a checkbox. Like I don't know if I want a number or some text. I want a checkbox that says yes or no. And so Drupal has a tendency to expose details from sort of the low level back end side of things. Users, especially new users, expect to see things from a higher level where it's like, I don't really care how it's stored yet. What I really want is a form that someone can fill out. You see this a lot in the code with Drupal 8 as well, too, where in order to do something that seems like it should be pretty simple to do, like load a node from the database, you have to first understand all of these other concepts. This illustrates you. You have to get a copy of the entity type manager service, which means you even know what that is. And then you have to choose what storage method that particular entity type is using which happens to be node in this case. And then you can finally load the node by its ID. And like, and that's important, like the way that that system works allows for a lot of flexibility. But sometimes this kind of complexity also means that there's a lot of things that I have to learn before I can just get the title of the page that I wanted to print out on the screen. So sometimes Drupal exposes a little too much implementation detail. Sometimes it doesn't expose enough implementation detail. It's like I found this line the other day that just sent me down this rabbit hole of like, you're getting the value and then you're getting the value of the value. And I just got lost and it was really confusing. And as you can see, and what this is is it's in particular here that first get method is returning a property of this current object. And then you're getting the value of that. And once you dig into the code, it's like, okay, I get that this makes sense. But I had to it bothered me that I didn't know what this did. So it sent me down this rabbit hole for a couple of hours and all the sudden I was like, well, now I understand Drupal's typed data and entity system, but really, I just wanted the value of the field. You think it's funny, but it's not. So you have this rapid increase in confidence as you're following these step by step tutorials. But then you run into this problem where at some point you're going to have to step out from that hand holding, and you're going to have to solve your own real problems where there's no longer a tutorial that you can follow. And you don't have that constant guidance of someone just holding your hand the whole way. And with that, oftentimes comes the painful realization that you actually have no idea what you're doing. It's one thing to build a view when you're following the step by step tutorial, and you can just do what it says on the screen. And it's a totally other thing to apply those concepts to your own unique situation. I'm not saying you can't do it, but it definitely teaches you how much you don't know when you're suddenly tasked with doing something where there isn't someone to hold your hand. I often think of this as sort of the cliff of confusion. So you've learned a lot. Your confidence has gone up very far. Suddenly you're like, Oh, I actually have no idea what I'm doing. Somebody shoved you off the cliff of confusion and your confidence goes tumbling down to the bottom. And you end up with something like this. Anybody want to guess what this is? This sort of. This is what happens when you're learning to output content in a theme in Drupal 8. And you wanted to change the way that the content in a node was displayed. And you couldn't quite figure it out. So you googled for an answer. And the answer sent you to Stack Exchange. And on Stack Exchange somebody said, Well, what you need to do is put twig into debugging mode. And then you need to use the dump function to dump the content variable. And then just refresh the page and you'll get a big list of everything that you can print out. But you don't. Instead you get this, which is nothing. Because you didn't know that when you turned all of that on, you also needed to increase PHP's memory limit to like 200 megabytes so they could handle Drupal's recursiveness. And you didn't know that there was such a thing as turning display errors on in PHP. So what this is, is PHP having a heart attack but not telling you anything about it because you asked it not to. It's also really frustrating. And so as someone that's new to this stuff, you just wanted to change like one thing about your theme and now suddenly you need to learn some basic systems administration things in order to work with Drupal. I point this example out partially because it's funny. It's super true. It's really frustrating. I think it also illustrates like another problem wherein this isn't even Drupal's fault. Like this doesn't really have anything to do with Drupal other than you happen to be creating a Drupal theme. This is PHP running out of memory. This is the twig theme engines not dealing well with recursively dumping a giant renderable array within Drupal. But to the person that's learning this to you, that doesn't matter at all where the problem actually lies. You're trying to learn Drupal and when this gets in your way, you immediately say, well, Drupal's just really hard and I can't learn Drupal. That's kind of an interesting thing to think about. I think that you have to learn all of these other things as part of the stack, but you often blame the end thing as the problem. So Drupal's hard because PHP is hard and so is MySQL and so is Systems Administration and so is usability and all of these other things. I think that part of the big part of the reason that people have a tendency to sort of fall off this cliff of confusion, the Drupal learning cliff, is that as you're sort of progressing along the your journey of learning Drupal, there's this relationship between like where you are in that journey and the scope of things that you need to know in order to kind of keep moving along. And that second phase is often characterized by like you suddenly just realize there's a whole lot of things that you don't know and now you need to go and learn all of those things before you can make one more small step. And so I kind of keeping that in mind. I also think that and I'll cover this a little bit more in a future slide, but I think there's kind of an inverse relationship between the number of things that you need to know and the number of resources that are available to teach you those things, which is somewhat problematic. After you fall off the cliff of confusion and crush yourself on the rocks at the bottom and you wake up at the next day or a couple of days later and you're like, all right, I'm back. I still want to learn Drupal. I'm ready to work on this. Now you get to proceed to spend the next like six to eight months wandering around in the desert of despair. This is this barren landscape in which you know there are lots of possible ways that you could do something, but there's no good marked path. You don't have a map. Maybe there's a bunch of paths on the ground, but you have no idea where they lead. And the problem is you can't know where any of them go without walking down that path first. And most of them are going to be a dead end or most of them aren't quite going to be the implementation that you want. In this phase you might, for example, already know how to implement a hook, but you don't know which hook you should be implementing in your module. Or you might know how to add a content type to or how to add a field to a content type, but you don't understand the implications of adding a text field for a list or an integer field for a list and how that's going to play out in the way that views queries your database and can cause performance issues down the road. And you oftentimes you don't know those things until you've experienced it. And that's really challenging. This phase is mostly just spending a lot of time trying out new things, bashing your head against them, backing up and trying it again. This is that thing where you, when you're learning a new programming language and everyone's like, write a to-do app. This is the part where you rewrite your to-do app like five times in a row and it gets a little bit better each time. This is again that you don't know what you don't know phase, which also means it's hard to get answers because you don't know what to Google for either because you don't even know what the right words are. I think part of why this happens with Drupal is that Drupal is super ambiguous. You know that other screen, the white screen, we could have also said, this is what you get when you install Drupal. Just a blank canvas and it's like, hey, go ahead, build things. I'm like, oh, OK. Drupal is a super complex system that's capable of doing a huge number of things and it's built by a lot of people who are using it for a lot of different reasons. And with all of that comes some level of ambiguity. It's like, you know, a tool like Views is really powerful. You can build pretty much any query with it, but that makes it complicated too. It's a lot more challenging to learn and understand than maybe a tool that's just like, you know, click one or two checkboxes. I want a list of 10 articles. So it's part of what makes Drupal challenging. Dries talked a little bit about this in his keynote on Tuesday and trying to understand a little bit better, like, who Drupal is for or, you know, what use cases Drupal is for. And I think that there's an opportunity for us as a community to either decide that to label that a little bit better and say, you know, Drupal is for building this type of site or Drupal is for these types of projects. That at least is one way that we could make it a little bit easier. I had a conversation with someone this afternoon whose suggestion about this was installation profiles as an example of a way that you could improve sort of the learnability of some of these things where you've got an installation profile that is already choosing a handful of modules for you and installing them and you can just start from that as a starting point for maybe, you know, I want to build a social network instead of forcing you to go to Drupal.org and search through the approximately 30,000 modules that you could install, half of which do the same thing and choosing which one is the right one for your particular project. There's also other things in Drupal that I think make this phase particularly difficult, which really comes to there's a lack of exposure of the rationale for decision-making within Drupal. Things like in Drupal 8, you can either, when you want to have a module that notifies other modules about the things that are going on, you can trigger an event or you can invoke a hook or you could do both and there's really great documentation about how to do these things but the documentation about which one you should use and why you should use it tends to be a little bit lacking and it's stuff that often just requires you to gain experience in order to understand how to do it. There are so many things like this in Drupal 2. It's like, you know, configuration management in Drupal 8, you can store the data here or there or you can move it to another location. You can export some of it or all of it and you're like, which one should I do? So as people working on Drupal, one of the things we can do is be better about documenting the rationale for why we've made decisions about the way that things work. After you've spent long enough wandering around in the desert, you've made enough pathways, you start to gain more confidence. You start to learn the words that you can Google for the appropriate things and you'll eventually start to, I think of this as like, eventually you'll find a path and you'll emerge from the darkness and your competence and your confidence will start to increase again and eventually you'll get to a point where those things match in a way that allows you to feel like you're ready for say a job or whatever your objective was. I think of this as job ready. Requires me to be, both have enough actual Drupal skill to do the things that an employer is asking me to do but it also requires me to have enough confidence in myself that I'm willing to say, yeah, I can do those things. This is mostly about learning things like best practices. It's sort of like shoring up the house of cards that you built in order to understand all of the different modules that one could use for various different things and just practicing those skills and getting better and improving over time. So those are the four phases that I think people go through when they learn Drupal. I did a bit of thinking about how the resources that are available to people learning Drupal map to those phases and you can kind of see there. So like in that first phase there's a ton of material available and it's really highly polished tutorials and that's part of why it creates this rapid increase of knowledge where you can follow those step-by-step tutorials. In the second phase you have things that are available to you like Stack Exchange or IRC. You know enough to ask a question like how do I inspect the contents of this variable in a twig template file but that also can rapidly lead to a lack of confidence where it also it exposes how much you don't know. And then you run into this situation where there's a really long period of time wherein tools like Stack Exchange or IRC aren't necessarily super useful resources again because you just don't necessarily know what questions to ask. And then finally after you've kind of been through and had enough experience and spent enough time you get to a point where those tools do become useful again. Things like the documentation on api.drupal.org is fantastic but it's only fantastic if you know which hook to search for to find the implementation details for. I asked for feedback from my employees about the, not my employees, the people that I work with at Lullabot about what their experience was like learning Drupal and where they thought they could have used additional help and how that panned out. And every single person that responded to this said that the number one thing that helped them get through these harder stages where they were kind of feeling stuck and like they didn't know what they were doing was having a mentor, peer feedback, someone else that they could ask and say should I use contacts or panels? Like in this particular situation which one should I use? And so the quickest way to get through that other than just walking all of the paths yourself and figuring it out is asking someone else who's walked those paths before. That said, I still think that you can't just make a resource that is a better map or better paths so that everyone can just more rapidly get through that desert of despair. There's also a lot of value for us as learners in walking each one of those individual paths. Part of the way that we learn things is we like in your brain you divide information up into chunks that you wanna understand. And then within that, in order to sort of cement those into long term memory, you basically just have to repeat that, that you have to walk the path over and over, you have to think of this as like paving the cow paths. You have to, in order to store the data for a long time, you have to do it a bunch of times. But once you've done it a bunch of times in the future it becomes easier to recall those things. So it's important to walk the paths too. So kind of balancing that, like giving someone a map but also getting them to practice and get the experience. Some of my thoughts about things that we can do as individuals in order to help improve this either for ourselves or for others. I've got a couple of ideas. One of them is remembering to this. As someone that knows Drupal already, Drupal's really easy, Drupal's easy for me now that I know it. And I often have to stop and remember that. And for me, this comes out a lot in things like writing documentation where you have a tendency to use words like, oh yeah, all you need to do is this really simple thing, just enable X debug. And people are like, yeah, sure. Like for me, that's like yeah, all you do is you just enable it. You go and edit the PHP config and you compile the extension and everything's fine. But for a lot of people, it's not just enable X debug. It's go through the process of learning what this thing is, how to use it and all of that. And so being careful about the words that we use when we talk to people about the things that we already know so that we set proper expectations for them when they're going into their own learning journey. Another thing that you can do is be a mentor and find mentors. Being a mentor allows you to practice those things that you're already familiar with by explaining them to someone else and it helps cement those pathways so that you can more readily access them in the future. It also allows other people to more quickly traverse that desert of despair. And along with that, I think that being a mentor has the effect of allowing you to experience through someone else who's just learning this stuff what that is like, where the challenges are, where the frustration is, so that now that you're a Drupal core developer who has the ability to affect change on the Drupal project, you're not forgetting what it was like to get there in the first place. There's this sort of idea of like, when you're an expert at something, it's really easy to scan your existing knowledge base and find the information and you just sort of inherently know how things work and that's awesome, like as a developer, you need that. You don't wanna have to re-look up how everything works every time but it's also sort of like the Achilles heel to someone trying to explain these things to another person because you forget that you already know how, you just sort of inherently know how these things work and oftentimes watching other people learn that is a great way to be reminded that maybe this is something that you could fix or help to fix or even just bring up so that other people know this is something that could be fixed. I have a story that goes along kind of with this. It has more to do with Drupal 7 but I taught a lot of Drupal 7 theming workshops and in Drupal, if you've ever built a theme in Drupal 7, you know that you have template files like .tpl.php files where you can change the markup and print out the title of the node and then you have the template file, template.php where you can implement pre-process hooks and that kind of thing and I would teach all of these workshops where I would inevitably have to explain to people the difference between template files in the template file and it was super confusing to be like so. If you wanna add a variable to your template file, what you need to do is edit the template file and add a new variable and it'll show up in your template file and so what ended up happening is I got really really good at explaining this and over time I could like within a couple of minutes I could help you understand the difference between template files and the template file and when I say this word, this is what I mean and when I say that word, this is what I mean and after doing this for like a couple of years in one of the classes, someone stood up and raised their hand and was like, this is really dumb. Why don't you just change the name of the file and I was like, I don't know, like that's brilliant. I don't know why I didn't think of changing the name of the file and we were able to like in that workshop, write a patch. It's like two line patch that got committed to Drupal 8 that changes the name of the file and so now no one will ever have to learn the difference between template files and the template file and we're able to kind of like ease some of that learning pathway and that's a example of practicing temperate humility and allowing people to share their experience with you and remind you of the things that you're just taking for granted and then using that as a way to help make it easier, not for you and not for them but definitely for the next person. Okay, so those are my ideas about kind of the things that make Drupal hard to learn and what I'm interested in now is I'm interested in hearing from people either what it is that you think makes Drupal hard to learn, things that you think that we as a community could do in order to help improve this or anything along those lines people have thoughts, I could ask specific questions. Yeah, you guys don't have to get up and use the mic, I can repeat the questions too. Go ahead. Well, the gentleman in the back who had his hand raised. Yeah, I wasn't actually doing anything on its own. You have to install 500 plus modules and then you have a website where as coming from jubilee it was like, oh, here's all the things that you need and you just go to my website or you might buy one commercial product and that adds to the feature. So I think a lot of the, what's hard is what modules do I use, why do I need these modules? And just like there are modules that people recommend and other modules that people are like, oh, don't use that, it's not a good idea. It's like, oh, okay, why is it there then? That was a hard challenge. I agree. The statement was that in comparison to Joomla, Drupal is difficult because when you first install Drupal there's not a whole lot there and then there's a need to go and sort of parse through the vast quantity of contributed modules in order to find the ones that are necessary to use and useful. I think that, I agree, I think that's a thing for sure, I think that there's definitely some work going on in Drupal 8 in order to help try to alleviate some of that. Like you look at the number of modules that are in Drupal 8 versus Drupal 7, there's definitely been some movement to taking things that were sort of best practices from contrib and move them into core as a way to say, we recommend you use views. I think we can do more with that too. There's an initiative right now to add a new installation profile to Drupal Core that contains a bunch of default content and the idea behind that is to when you first install Drupal instead of just getting a blank page you get a already built site. The example that they're looking at creating is a magazine site but what it does is it helps to illustrate to someone what's here and what core by itself is capable of because right now you just install it and like half the modules aren't even enabled. You have to go turn it on before it even does anything. But, so that's the thing. And if you have other ideas about how we could not say fix, I don't think it's a solvable problem but how we could improve the findability of best practice modules and that kind of stuff we're always curious to know. Thank you. Yeah, yeah, so the question is couldn't you have a module that just enabled a bunch of other modules? And actually so in Drupal we would call that an installation profile and you could get an installation profile that has instructions about enable this set of modules download this other set of modules and package it all up together so that you have a magazine site or a farmer's market site. So maybe part of it is doing that, creating those resources and then also making them more readily available. Maybe it's like a, I could see a scenario in which when you first install Drupal instead of it just being like standard and minimal as the installation profiles there's a handful of others that you could choose from as well in order to see some of the things that Drupal's capable of. So one of the things that helped me through the desert of despair was people who had made it through writing about how they found a path through to do such XYZ. I think a typical thing for us to do where I'm in the desert is even when we hit that white screen is to type something into a search engine and somebody's written about how they fix that problem. So I have two requests for the room and for the community. One, if you, just because you're in the desert you may be the ideal person to write out how it is to do the thing that you've just figured out how to do, especially for Drupal 8 because I learned those things in the desert with Drupal 6 and Drupal 7 when a lot of things were written. And there's less of it now for Drupal 8. The related request is, if you wrote such a thing in 2014 about how a thing works in Drupal 8, would you please go back and look at it and see if it's still right? Oh yeah, this is, that's it. Yeah, this is a serious thing because I'm well done that path now and so I found myself in Drupal 8. Typically I stopped Googling and I just started going and looking at the codes and the annotations because I would find a blog post and it would say, oh yes, do this thing, like here's how to do the Ajax thing and I would go do that and it wouldn't work. And then I would find a change record that says, oh yeah, well we did, we changed that in 2015 as we were in development. So please check. There's this problem with the internet where like once you post it on the internet it never goes away. Even if you wrote it for like a release candidate of Drupal and it's no longer valid. So if it's on your blog and you wrote it in 2014 or 13 or 2012 about Drupal 8, would you please check it and either fix it or bring it down because the people there in the desert are trying to use your documentation. Yeah, I often recommend either taking the time to kind of at the top indicate like, this is old and I know it's out of date, sorry. Or this is old and I've kept it up to date and it's still accurate. And if you are in the desert and you're Googling things about Drupal 8, use your search engines filter and ask it not to show you anything that's more than a year old probably. Oh, that's it, I've never done that. I do that all the time. Everyone's like, duh, Joe, why don't you do that? Because I didn't even know you could. Yeah, yeah. That's similar to what I was gonna ask is that major upgrades have always been a big challenge and there was a whole lot of anxiety from a lot of people around symphony components being brought into Drupal 8 of I'm gonna have to learn so many new things and for people who might be familiar with an old version of Drupal, it feels like you're just dropped into that period of despair in the new version without having any highlights to start with because you're already trying to solve really hard problems with Drupal 8. So I was kind of curious about other ideas about how to build resources for people who might be very capable and competent Drupal developers already in an older version but just having anxiety about the new version and don't know how to map their skills over to those changes. Also, also a challenge, the sort of like, and I think this is particularly painful with the upgrade to Drupal 8 versus previous ones. Like, you know, from Drupal 6 to Drupal 7, like the biggest thing you had to learn was the fact that there are more hooks than there were before. And now with Drupal 8, a lot of these paradigms have shifted and we have whole new ways of doing things. The best resource that I know of for that currently is the change records on Drupal.org which are great if you know that they exist. Kind of like, I didn't know that you could search and filter by date, that's so cool. So those are a good resource where they have a lot of examples that show this is how you did it in Drupal 7, this is how you do it in Drupal 8. Again, there is also a lack of change records. There's a lot of things that change that maybe should have gotten a record and didn't, that would be one thing that we could work on improving. Finding ways to bubble those up in the documentation or in other places so that people can discover them that just in a part of mapping their knowledge. Personally, I don't find the change records to be very discoverable unless you happen to land on one by Googling and then finding the original issue and then reading the 200 comments and at the bottom someone is like, oh, here's the change record. Yeah, if you have other ideas about how to handle some of that stuff, I would love to hear them. Or if other people do too, that sort of like, how do we help people who are Drupal 7 developers that are just kind of dropped into that desert of despair because you're not learning what an entity is again. You already know this, but there's a whole bunch of new concepts and maybe one of the quickest ways to get out of there is to find ways to map your existing knowledge to Drupal 8. I don't know. Yeah, there's a little bit of that problem too. It's the like change records are, they document one specific change. And so it might be like this thing in the form API changed and that's great if that's specifically what you're looking for, but the example code might contain all of the, it's like, and you have to know what a service is and how dependency injection works and the fact that there's an entity type manager. So maybe it's like within that, there's some kind of like inter, like being better about linking to related concepts kind of thing. Yeah, four. All these concepts, I think there was a list and maybe just some links to some of the Symphony Docs or things like that to help you learn the new concepts that were missing from 7, I think. Where would you go to find that? So how many people know that that exists on Drupal.org already? A list of all of the basic concepts that are in sort of like you need to learn dependency injection, you need to learn what a service container is. Yeah, it's there, it's probably not complete nor is any page on Drupal.org, but to some extent that record exists already and so part of this issue too is like making people aware and getting them in that direction. It means I'm not going to be on information. So maybe it's like we need better reference from you're on this deeper, you landed from a Google search on this deeper page. Hey, just FYI, here's a prerequisite if you don't know this stuff already. Or even like is it anywhere where there's a unit back which is hotline back to a page that explains to you what the dependency injection is. I think Drupal is trying to do this, but I think like almost having like we're saying like learning dependencies on a piece of one of the docs, going back like oh, we have that list on the d.o.documentation.com, I think. Yeah, I like that idea. And yeah, we do, on our site we do that. We have a little more control over our site so it's a little easier. The Drupal 8 user guide does a pretty good job of that but it was also sort of like an explicitly curated set of documentation where we took the time to be very diligent about referencing things. And Drupal.org, which is all effectively a wiki, there's a lot of opportunity I think for that better referencing of concepts and prerequisites. Thank you. So when it comes to Drupalize me, long time listener, first time caller. I'm a huge fan, huge fan. So I kind of piggybacking off the first two people online here actually. So basically I was in looking at those phases, those four phases, what struck me now, so I'm working for our agency currently, like I'm on the job now, I'm job ready. I was hired so apparently I'm job ready. So in looking at that though, I'm almost looking at, all right, well what's phase five and beyond actually, and I think I could even see a double dip happening. I at least know from my experience joining the agency and then I get just another dip downward, just joining, once you get on the job, there's immediate another double dip going. I think if this is your overall path, if this was a fractal and you could infinitely zoom in, the path would be made up of millions of these dips. And it's like every time you set out to learn a new concept, like say you need to learn dependency injection, you're going to go through the same path and it might be, your peaks might be higher or lower, depending on how complicated of a thing it is, but I agree with that. And then the job ready, it's like sort of, that's one measurement of success, but it's also like built a module, that's a measurement of success. I am Tim Plunkett, that's another measurement of success. Yeah, right, and so along those same lines then, and I think you mentioned kind of getting at the why behind the how, I think that's been a big, huge issue for me especially as, and I'm speaking from my current experience, as I'm working for agency now as a backend developer, and so I feel confident in a lot of things, but now it's transitioning to Drupal 8 on a lot of projects. There's just so many unknowns now for my own experience, and especially as I then work on my career path up towards a senior dev potentially lead architect in the future, I would love to see whether that's like Drupalize me or someone else takes the lead on that kind of thing where you have this almost lead dev kind of architect track for teaching these kind of high level concepts, because I feel like that's so lacking these high level explanations, conceptual explanations of all these things, like I attended another core conversation yesterday on decoupled from the inside out, talking about the decoupled architecture of Drupal going forward and things like that, and it's so easy to get so mired in these how to articles for how to make your first controller, how to make your first service, how to dependency injection, but there's no high level explanations of how you get that lead architect level in a Drupal site. How do you start conceptualizing these kinds of things? It's like the Wikipedia problem, right? You're like, I wanted to learn about things to do in Baltimore, and five days later I emerged from Wikipedia and I understood like the entire history of the state of Maryland, like, yeah, there's some of that. I think that for anyone that works with other people who are also doing Drupal, if you're fortunate enough to have that opportunity, those people are one of your, not one of, they are your best resource for learning more Drupal, even if they're at the same level as you or not, even if they're not, there have not yet learned as much as you have. Being able to sit down and have a conversation with other people about like, why did you build the view that way? Why did you use this particular module? Let's discuss some of your experience with it and the benefits that you found versus my experience in the pitfalls that I found, like it's, that's huge. And I like what you're saying about like, having some kind of mentoring leader, lead developer. Especially, yeah, yeah, but even just having a bit of the why on d.do because I remember in D7 you would go to the API page for a hook. And over time, those that build up actually, like this is what this is achieving. And then there'd be a lot of things. Now in D8 you go on the API because everything is a class now. So you just go to the class page and there's often nothing. It's just a link to a class hierarchy and there's no explanation even of a why. And I think, so I think this does need, on some extent had to be like a overall documentation effort because I think especially, and especially as it's almost a community issue because as D8 is growing the way it is into this, it's just getting more and more enterprise oriented and also bringing outside knowledge of just PHP development in general. It's, I think we're just gonna start losing more and more of people who don't have, like I said, who don't work for agencies and don't have those other teammates to rely on. And it's just gonna, that's gonna be natural progression of the community unless we actively take a step in the, of trying to still make an open project for a lot of different areas. I don't know if that's feasible or not, but. Insiders writing documentation. Yeah. So I'll come to that in just a second. I, to your statement about like, I totally think that one of the things that we can do is be better about exposing some of the rationale behind the decisions that were made. Even just myself as, I feel like I've experienced D7 developer, but yeah, like just doing the rationale behind D8. Somebody earlier made a comment about how like, when you're in that desert of despair and you've just discovered how something works or why it works a particular way, that's one of the best times to document that because what ends up, also part of what ends up happening too is like, I'm so far past having learned that, that I just take it for granted. Like it just, I just inherently know that this module is better than that module for these particular situations. And I forget even that this is a thing that I should need to document. So one of the things we can be better about as learners is taking the time to sort of document our assumptions and what we've learned along the process. I'm curious to see like how you like, as you realize me and you know, companies like Acquia, you know, see themselves as leaders in that role as well. Because for example, like, I couldn't help but like think of, I was just searching a day or two ago and to find documentation on, you mentioned that example of the entity type manager of then getting storage, letting node, like Acquia has this documentation and they have like a pretty canonical looking documentation thing and they're still referencing the entity manager class, which is now deprecated to loading. So Acquia as like the canonical company has like pretty official looking documentation on their site that's referencing deprecated classes now and is totally out of date. Yeah. But this is like phrase is like. That's another one of those like, someone made the comment earlier about like, keeping your documentation up to date because once it's on the internet it's there forever and then this is sort of like, does an organization like Acquia who has such search engine clout that their resources are likely to show up at the top, so do they then have more responsibility to keep those things up to date? I don't really get to say yes or no to that. Yeah. Somebody, you had made the comment about hiring professionals to write the documentation. I think that would be awesome. One of the things that's always a struggle in open source communities is where does the money to do that come from, like who funds that? Certainly organizations like DrupalizeMe and Acquia and others that are working on Drupal are putting resources into writing the documentation and helping, but there's, so DrupalizeMe is an example. There's sort of this relationship between like, it's also how we make a living. So we're always trying to strike this balance between like just giving it all away for free which we would love to do if we could but also this is how I feed my family and so you're trying to balance those two things. I agree with that and I think that, I think that we're making strides in that direction. I think the Drupal 8 user guide is a good example of the community sort of coming together and at least getting a couple of people who are, understand Drupal and how to write good documentation to take the time to write it. And then again, it sort of becomes a like, ultimately it's like who's gonna pay for it. The user guide is, was all done by volunteers. It took us almost two years to write it just based on like, you know, volunteering time and how much time do you have. It's awesome now that it's done. It took two years and it documents like, you know, how to install a module and click the button to turn on views. It doesn't even get into the fact that you could write code for Drupal so that it's also like a just volume problem. If ideas about, if anyone has ideas about how we as a community could help to make more people that are good at writing documentation have the time and the resources to be able to spend time working on documentation that they then give away for free. I would love to hear those ideas. You could monetize this, I'd rather, I would easily, instead of going to the heart of what you had to go through, just overarching concepts and what's different and how confidence almost has to go over and swing up in the month time and be a confidence level eight developer. Yeah. All right, 500 bucks, if anybody. Duler, Duler, yeah, comment. So to speak to that kind of thing, Drupal is a huge amalgam of different technologies coming together. And each of those technologies has its own lingo. So like views, you have view and display, those are database terms. And we talk about modules, that's a programming term, but I'm a back-ender, but I understand that some front-end people use modules as a word to describe part of that. And if we had a glossary that kind of told us what the words mean, because we use them very specifically and it takes a long time to pick up the meaning of what each of those things are. Yeah, I agree with that. And then of course, maintaining the glossary, yeah. Naturally, maintaining documentation, yeah. That's true, once you've documented in the glossary the term plug-in, yeah. So something like that, I think there's maybe an opportunity to if you could get the original version written, you could then tie it to a version of Drupal Core and say, you know, when Drupal 9 comes out, let's revisit the glossary and make sure that it's still valid, like all the terminology is still valid for the way that we use it with Drupal 9. Things get done, it just takes a lot longer, yeah. One of my responses to that, not the point I got up to talk about, but inline comments. I'm not a Drupal developer yet, but you guys can do inline comments in the code, right? Yep. Okay, do more of that, that would help. Yeah. I'm a little just notes guy, looking to Drupal is maybe a... You have to cut. Okay. All right, you can hire me later. We're being kicked out because... Okay, well, I'm going to get business out of this so it's all worth it then. But I'm going to be around, and I will, after this, I'm going to head down to the exhibit hall and I'll go to the Lullabot booth, so if people want to talk about any of this stuff more, I'd love to talk about it, or at the sprints tomorrow. Thanks for coming.