 Welcome to the last session of the day. Hopefully it will be a somewhat upbeat session. We'll see how that goes. This is a core conversation session. Don't know me already. My name is Larry Garfield. You may know me online as Krell. You may also know me as the Dancing Crab. That's proving that I am in fact ready to be committed. Anyway, I'd like to talk to you about the most powerful word in the English language. There's a word that has the ability to create, to destroy, to build, to bring people together, to tear people apart. It's a very fine weapon that has to be used very, very carefully. That word is no. No is one of the most important things you can say. I know it's politically incorrect to say. You want to say yes to people or yes and. No is one of the most important things you can say, no matter what your job is. Saying no is how you provide focus. It's how you optimize and prioritize your work. And saying no is part of leadership. Being a leader involves saying no. Let's talk about each of these. Focus. Focus means saying no to 100 good ideas. It's not about saying I'm going to work on this. I am not going to deal with these thousand other good things. Innovation is saying no to a thousand things. This is from Steve Jobs. Remember when the iPhone was the first released? Who actually bought the original iPhone? Couple of people. Remember the lack of copy and paste? Or the lack of downloadable applications? They couldn't figure out how to do that well. So they said no to that functionality. Apple's doing pretty well for themselves still. They said no to everything except what they could do well. Nothing else. Everything else that you could have done on a phone they said no to. We still don't have a real Apple TV. Why? They're finally getting into the watch business a year late because they don't feel they can do it well. And so Apple is not willing to put out a TV the way the trade press has been talking about them doing for four years now until they feel they can do it well. Until then they continue to say no to that type of product. We have to say no in our business too. You remember the client of Doom, right? No one, was that the pre-note? The client who wants a thousand features, 20 levels of dropdown menus. You know, you have to say no to a lot of this functionality because if you try to put too much into one website or one application or one interface you will do it all badly. And it's much better to get a few things really right than 50 things crappily. It's a quote from Lauren Scheselut. He's, I believe he's a developer in Europe. Quoted them last year as well in a core conversation talking about complexity. As a tech lead I see my primary contribution as saying no to features. Why saying no to features? Because every feature you add to a piece of software increases the maintenance cost. Every single feature, every single line of code you add makes maintenance harder. Now, sometimes that feature may add only linear complexity and linear difficulty of maintenance. Or if it's something that touches a lot of different systems it may be geometric. Adding one new feature to this system makes it 10 times harder to maintain because that one feature touches 10 other systems. Saying no and keeping the system light is important. In the same article that's linked here if you want. He talks, he quotes a developer and tech lead at, I think it was Universal or some movie studio that built their own lighting software for doing animation. And the most important thing they did was keep the feature set small. This is a very hard problem space doing good lighting and shading in digital animation. This is a hard problem. And they kept their feature set small. Just enough that people could get their job done by assembling the few features it had. And it worked. Because they didn't try to layer in every possible feature they just had the few features they need and are able to build from that. Anything bigger and it would have been an unmaintainable mess. This is a quote that's been attributed to about 50 different people who knows where it actually comes from. How do you bake an elephant? Grab a big block of granite and chip away everything that isn't an elephant. You identify what isn't an elephant and you say no to it. You remove things to produce what it is you want. There's another quote. You're not done when there's nothing left to add but when there's nothing left to take away. That means saying no to things, taking things away, removing functionality, removing features, removing design elements until all that's left is the important pieces. That's saying no. Who's played Bejeweled? Almost everybody. Probably. This is a very successful game. What's your interaction? There is exactly one thing you can do with this game. They focused on very simple gameplay and it's one of the most successful games of the past decade. Far more so than games that had a lot more complex bits and pieces to them. The first game is far more successful than any of the follow-ups that had bombs and fruit things and all this other stuff. Keep it simple, focus on the one thing you do well and people can pick it up and play it anywhere, anytime, in seconds. Contrast that with, this is the F-35 Joint Strike Fighter. I mean Joint Strike Failure. This is the US military's next generation air superiority fighter and bomber and stealth plane and reconnaissance plane and yeah, it's designed to have vertical tech off and landing, you know like the Harrier so the airplane can take off vertically and it's supposed to be stealth design. Guess what? Those don't actually work together because the physical way you need to build the plane to support one of those is incompatible with the way you build the other. They're trying to make it a Navy fighter, a Army bomber, everything all at once and that's why it's a trillion dollars over budget and the best analysis says, boy the Chinese are gonna pick our butts with this thing because they're not doing the stupid thing of pushing everything into one design. We've all seen what happens when you try to push everything you can think of into a single design, right? Nobody told, nobody said we should not put every feature into this car. We just added everything we could think of that seems cool and the results were rather predictable. Nobody told Homer, no. No lets you optimize and prioritize. Let's you decide what is going to be important by saying no to things that are not important. The HTML5 working group has this mission statement or it's a guideline. In case of conflict, consider users over authors over implementers over specifiers over theoretical purity. This is their framework for deciding what to say no to. This is their framework for saying, you know what? We're going to have to make a decision here. Someone is going to be upset with this decision. Someone's life is gonna be made harder by this decision but we can't avoid that decision. This is how we decide who we make upset. Is this, this is their prioritization metric. Is this the right one? I don't know, but they have one. They have the ability to say, we're going to be consistent in how and when we say no. Does Drupal do that? Well, as of when I started talking about this, we didn't even have this metric and the discussion thread there, no one could agree on what the metric should be. We don't have a metric in Drupal for saying no. See some other examples. Ultrabooks, it's a new fad in laptops in the last couple of years. Very thin, very light. Trying to get good battery life and most of them they usually do a halfway decent job. Very nice systems, how do they get that? Well, they don't have CD-ROM drives or DVD drives or whatever they call them these days. They don't have many of them, even in SD card slots. The only output they have is HDMI. You don't get any other video outputs. But that's how you get lighter. That's how you get a simpler, lighter system that is a thinner piece of hardware by taking out hardware. You take out functionality from the device and then you don't need to spend the space on it. You don't need to spend the weight on it. Take it a step further, the new MacBook Airs. They say no to everything. You get one port and that's it. Okay, and a giant dongle, but whatever. They're saying no to all kinds of things you could put into a laptop. And that lets them build a very thin, very light system that doesn't even need a system fan. Which, whatever you think of Apple, and I don't like Apple as a company, but whatever you think of Apple, that's pretty impressive. If you're not willing to say no in prioritized features and leave things out, you end up with one of these. Which is optimized for nothing. It's too big to fit in a hand. I don't know how I would even use it. Apparently they do sell this. I don't know who's bought one other than as a gimmick. Like a hundred tools and I can't even tell what all of those things are. To toenail, clipper, wrench. There's probably a kitchen sink in there somewhere. And it's useless. It has every feature you could want. And so it's a poor fit for any of them. None of those features are usable because they are too many of them. Contrast that with an impact driver. It does exactly one thing. It applies lots and lots of force very quickly. That's what it does. And it does great at that. You want to nail that's going into something hard? This will take care of it. You want to use it for something slightly different to open a can of paint like you can with screwdriver? Don't even try. But this is great for the one thing it's designed for. How about in the tech world? Databases. We're used to using SQL databases, most of us, but there are plenty of other types. We started this straight off. Consistency, availability, and partition tolerance. Cap theorem. A couple people. Mm-hmm. Yeah, pick two. If you're designing a database, you get two of these. If you want to have, in SQL's case, consistency is what's important in doing replication. So you have generally one master database and a couple of replicas, maybe. But everything goes through that one master, generally. The emphasis there is data integrity. In something like Elasticsearch, that's a database, but its priority is not perfectly consistent data at all times. Its priority is speed. And so it will take care of moving things between servers as needed, but there may be a delay. There may be a gap. There may be a temporary inconsistency. And that's okay in that use case, because the priority is not consistency, the priority is speed. If that's appropriate for your use case, then that is the better tool than SQL, and vice versa. How good of a job do we do in Drupal of this? Who's working on a theme system? Did you know that there's actually two completely different approaches to theming, philosophical approaches to theming, baked into Drupal core? You can theme an object, like a node, in which case a preprocessed function is responsible for most of the work. Or you can theme individual variables, in which case the template is responsible for most of the work. Both of these coexist and are philosophically incompatible with each other, which means that as a developer or as a themeer, you need to understand two completely different theme systems with the same syntax. Who thinks this is good DX? Exactly. But we have not been willing to say no to either one of these approaches. We've said, yeah, okay, use it and whatever, and people do it in different places, and it means it's very inconsistent. And for more information on this, Steve Perche has a pair of blog posts and a presentation that you shall go to this morning. Excuse me, you shall go to yesterday? Yesterday. You shall go to yesterday. So follow up on those. The last one is the presentation yesterday, which you should all go to. But this refusal to decide, this refusal to say no to certain philosophies of theming, of certain ways of structuring a theme system. Neither of these is necessarily wrong. I'm not saying either of these is a wrong approach to a theme system. But the fact that we have not said no to one of them, the fact that we allow both to coexist, is how we get to this mess. This is a partial diagram of the Drupal 7 theme system. And in the Drupal 8 theme system, we've removed two or three of these clouds. Which, well, this is an exponential growth, so removing two or three of them is actually a huge improvement, but we still haven't resolved that fundamental question. We still have not said, we're going to say no to this way of theming, to make this way of theming better. If you're controlling the look and feel of a Drupal site, part of that involves figuring out what the markup's going to be. Who's responsible for choosing that markup in Drupal? Is it the template author? How about the module developer? Are they responsible for deciding the markup? Or is it the site builder's job? All three, we have not said no to any of these people. Which is why we have this convoluted theme system. And just a simple example. We're talking to some of the leaders in the theming community all the way back in DrupalCon Copenhagen. Let's say you've got a block, and you want to put markup around it. The block's going to be wrapped in some kind of tag. Is it going to be a section tag or an aside? Both are perfectly legitimate. Or maybe it's an article element. All of these are perfectly legitimate. If the theme developer's job, then you have a template and it has a section tag in it. And if they want to change it, they change it to a div. Cool, okay, done. If you want it to be the user's job, someone pushing buttons in the UI, then you give them a select box in the UI somewhere, and you print a variable in the template. What happens when you have a template with variables in it to control what the markup is, and the themeer gets their hands on it, and replaces that variable with an element that they can actually read and control. Guess what, you just broke your UI. And now we've got this fancy UI that doesn't work. I'm going to go ahead and say, who's used the semantic views module? Few people, yeah? Semantic views is a module that lets you control an awful lot of the markup that views puts out through the UI. It just gives you more buttons in the UI for views to control what element you're going to use for what part of the template. With all the stuff we put into Twig, I think those are fundamentally incompatible with each other. I think it's fundamentally incompatible to have something that is editable both in the UI and the template. I keep saying this, and some core developers keep yelling at me, but they've yet to prove me wrong. Because currently, your answer is, we're not going to make that decision. We're going to let you choose what you want to do, because we refuse to say no. And what that means is, you as someone maintaining a site have to learn three different ways of maintaining markup, because it could be any of them, and could be multiple of them on the same site, depending on who was actually building that part of the site. By refusing to say no, refusing to focus on one of these users as the primary user for making this decision, we make life harder for everybody. Render API and all of its complexity exists in a large part for this reason, because we want to support module developers and themers and a secondary module developer and the UI, all controlling output. And the result is gigantic anonymous rays of doom, which we have not actually gotten rid of. We've just moved them out of the template, which means what we've effectively said is, hey, you people who want to have a comprehensible output system that you can understand and debug and maintain, well, guess what? No. And that includes documenters. That includes people running training sessions. That includes people maintaining sites. That includes end users. We have said no to all of those people for what they need, which is something they can understand. Because we were unwilling to say no to one of those users who could control things. And so by refusing to decide who gets to be important, the answer is everything sucks for everybody. When you refuse to say no, something will say no for you and you will usually not like the answer. Saying no is how you lead. Saying no is how you lead. A project, a community, whatever. There are lots of things you can do, but just because you can do something, just because you could write some functionality, just because you could add something to core, just because you could add functionality to a site doesn't mean it's a good idea. Just because you could add five levels of drop down doesn't mean you should. Just because there's modules that make it really easy to add a hero slider to your website and to the homepage. Please don't do that. You need to say no to that. What functionality do we put in core? Saying, you have to say no to some of that functionality or else we can just move all of contrib straight into core and say no to nothing. Now, to be fair, most software projects do not involve rampaging murders of velociraptors unless you use go to. Leading means saying no to velociraptors. Now, okay, we don't usually have velociraptors at DrupalCon, but we... Sometimes that's a good idea. Well, the culture of an organization is shaped by the worst behavior its leaders are willing to tolerate. If you're managing a community, you have to be able to say no to bad behavior. You have to define what behavior you will tolerate and what you don't. We have a code of conduct. We have a community working group. Those are tools for saying no to people who are going to misbehave. If you have someone in your community like this, you have to have the ability to say no. If not, they will drive away everyone else. That is saying no. That is putting your foot down that is making a decision that is drawing a line of the sand that is part of leadership is saying no to people. Who was around back in 2007 in Drupal? Oh, a lot of people. Okay. Who remembers the deletion API? Ha ha ha ha. Jeff Eaton arrives just in time. So this was the work mainly of Chad Phillips or Hun Monk was his handle. We have not really heard from in a long time. The idea was that rather than when you're deleting a node rather than letting every hook just delete its data with a delete query, instead we have this system that would collect the delete queries that need to get run and batch them all and run them all together at the end. And before it does so, it looks, all right, what am I about to do? Let me save that data to a backup which would let you then have an undelete ability, an undelete feature for content, which conceptually sounds great. This is a good idea functionality-wise. And this was in fact committed for about 10 minutes. Was it two days? Okay, about two days, not for very long. Originally committed by Stephen Wittens who at the time was one of Drupal's core maintainers and rolled back by Drees afterward. Because according to Drees, it was just not a fully baked enough system, it was the wrong approach, lovely idea, not the right approach. Honestly, I completely agree. Having looked at the patch, it was a lovely idea done wrong. And so saying no to that functionality, that point in time, done that way was absolutely the right call. But remember, we haven't heard from Chad Phillips in a very long time because that really turned him off from core development because Drees said no after he'd been working on it for four months. The timing of when you say no is just as important as the fact that you say no. This is something that we are actually very bad at in Drupal. Saying yes or no before the work is done. Because really nothing sucks more than pouring your heart into something to be told meh, that's called spec work. And designers in the room, right? Spec work evil, right? Yeah, not saying no early enough is abusive. It's a waste of people's time. More recent example, there was a very long thread on Drupal.org that ran for about a year on and off to update and refresh the Drupal icon mascot. And there were a lot of ideas put forth, a lot of discussion, some very good work went into that thread. And eventually there was reasonable consensus around a refreshed Drupal icon. I kinda liked it myself. And Dries showed up for the very first time in that thread after it had been marked RTBC with a copy of the SVG file for it and said meh, and that was the end of it. He said no, sort of a year late. Saying no early shows respect for the people's time. It shows focus and encourages people to go into somewhere that's going to be useful, that's going to be productive, that's going to get accepted. Just didn't say it soon enough. Now sometimes we do a good job of saying no in Drupal. For example, we say no to backward compatibility between major versions. I'm not criticizing that decision. That's a very clear explicit statement that the ability to innovate is more important to us than backward compatibility. We say that explicitly and we stick to that on major versions. And that is a good thing. Are there trade offs for it? Absolutely. We accept those trade offs explicitly. That's the important part. Other projects take the exact opposite approach of we'd rather have backward compatibility than be able to improve our software. Is that a better or worse trade off? I'm not going to say. There's a good argument either way. But they're saying no to something explicitly. They're explicitly making a preference known. They're explicitly making a statement. We used to say no to object-oriented programming. For a long, long time, putting classes in core was just not the thing you did. Eventually, we got over that and said no to procedural code. In Drupal 8, the only functions you write are hooks. We are saying no to procedural code in modules. If you have a Drupal 8 module, that is procedural code, that is not a hook, you're doing it wrong. We are saying no to that. That is the wrong way to do it. This is an explicit statement. That's okay. Whether you agree with that statement or not, you can debate that. It's an explicit statement of no. An explicit statement of the preferred way to work with Drupal 8. We've said no to cheap hosting. Let's be honest. If you don't have an opcode cache, don't talk to me. It's that simple. Drupal 7 onward. If you don't have an opcode cache, don't even bother. Not everyone agrees with how hard we've said no, but we effectively said no, even if we didn't. Everyone was in a conscious decision. Drupal 7 just doesn't run properly without an opcode cache. Drupal 8 neither. And that's okay. We say no to code style violations. We are very, very strict on patches. Your code style has to be right. Your documentation has to be right. We will reject patches because we value the quality of the code on a micro level. Do we do it too much? Someone's saying no? I don't know. That's debatable. But this is a clear explicit statement of our value. That we value the micro quality of our code base and of our documentation enough to say no to patches that are otherwise fine. That's a very clear explicit statement. In Drupal 8, we have said no to hosts that are behind the curve. We require PHP 5.4. Most of the PHP world is not running on 5.4 yet. We're saying no to those old hosts. We're probably gonna push up to 5.5 if not before launch, then sometime within the 8.x cycle. And saying no to hosts that are running completely unsupported and secure software. Is that a good answer to make? Is that a good statement to make? Personally, I think it's an absolutely good statement to make and I'm very proud of us for taking that stand. But it's an explicit statement of if your host is running PHP 5.3 or God forbid 5.2, no, go away, we're not supporting you. Because using stable supported software, using the functionality in new versions of PHP, protecting our users from security holes and older versions is more important to us than running on every server we can find. That's a statement of focus and a statement of value. We've said no to not invent it here in Drupal 8 because everybody loves Pi. I put this slide in every presentation I can manage because Pi. Any kind of Pi you want, but it has to be Pi, no cake. The cake is a lie. I talk a lot about functional programming techniques or dependency injection, all this newfangled stuff in Drupal 8. This is a process, to do this properly you are saying no to having state in your code. The language will support it, you're not going to do it. You are saying no to that style of programming. You're saying no to having implicit dependencies in your code. You're saying no to taking the quick and easy way to things. Yes, formal, clear, explicit dependencies on your services is more work than just instantiating something and calling it, or just commanding the calling function. Yes, it is more work to write. We are saying yes to long-term maintainability. We're saying yes to testability. How do you do that? By saying quality code is more important than doing it the quick and easy way. That's an explicit statement of what we value. Is that a good statement to make? Is it a legitimate debate to be had there? I think that's an absolutely critical statement for us to make. I fully support this statement. I fully support it saying no to quick and easy in favor of long-term maintainable. You can disagree, but at least that's in the clear statement of saying no. And if you wanted to disagree, then you're saying no to long-term maintainability in favor of quick and easy. You can't have it both ways. Who is Drupal for? Who is the end user of Drupal? What type of user is our target audience? And some of you are probably thinking, well, everybody, that's a coward's answer. That is saying I am abdicating the responsibility to decide a focus. I'm abdicating the responsibility to prioritize somebody and serve somebody. And that means I'm going to serve everybody poorly. Who is Drupal not for? Who should not be using Drupal? What is not a good use case to use Drupal? If you cannot answer that question, you do not know what you're doing with Drupal because you don't understand what Drupal is. Saying no should always be a deliberate, explicit action. If you do not make it a deliberate, explicit action, someone else will say it for you and you will not like the result. By refusing to say no to one class of user or some certain piece of functionality, you are implicitly saying no to quality. You are implicitly saying no to serving this user really well. By not saying no to piling in all the functionality you can to a laptop, you are implicitly saying no to people who don't want to break their back for carrying it. You have to say no, you will say no to somebody. Make it explicit, make it deliberate, make it thoughtful. You may make a bad call, you may make a bad decision, but that's okay, at least you made a decision and if it goes wrong, you explicitly know why, you know what happened. It's not implicitly I couldn't make up my mind. Deciding what not to do is just as important as deciding what you should do. And that means if you want to build a product, a platform, a tool, a community, the most important thing you can do is decide clearly and explicitly when and to what you're going to say no. If Steve Jobs can say no, so can you. I want to run this discussion phase a little bit differently. I want people to come up to the microphone and you feel free to disagree with me. If you come up to the microphone before you can make a comment, I want to hear you suggest a feature Drupal should not have, a use case should not support, a user base that we should not go after. Doesn't, I don't even care if you believe it. But suggest, it's better if you do, suggest something that we should not do, that we should say no to. I'll start. Digital asset management system, a CMS for things that are primarily binary files. We can definitely improve Drupal's file handling. But we should not try to make Drupal the premier digital asset management system on the market. There are others out there that do it well. We can integrate with them. We should not try to make Drupal a great tool for that. There's my proposal, there's my no. Let's see what else you've got. Where did Eaton go? Eaton said no to this whole session. I always really enjoy your talks, thank you. I say we say no to render arrays. Didn't quite get there yet, but we should do that. So how does this work out with, and maybe I'm not up to date on the governance model for Drupal, but how does this whole thing work out with the duocracy? That is one of the big flaws of duocracy as a model. Yeah, because the examples you mentioned were duocracy type of examples, so maybe it's flawed. That is one of the big drawbacks of duocracy because I'm gonna do, and then no one wants it. And that sucks, or I'm gonna do, and it gets in, and then like, okay, now what? The PHP Internals team, for example. If you do not have a reputation of doing maintenance, they won't accept an RFC from you for improvements to the language. Even if it's a great idea, do maintenance for a year, then propose an RFC, it'll sail through, I've seen it happen. That's a different take on duocracy. And then the next just quick thing, so the whole reviewed and tested by the community. This happens at the very end after all the work is really done, and this is the flag that committers look for. So maybe that's flawed too, because committers aren't seeing what's being done until it's been reviewed and tested already. Yes, and there have been a number of attempts over the years to rectify that with various issue tags for your needs, commit, or feedback, or something like that. They sometimes work, sometimes don't. With the new governance model for the project we're trying to put in place, part of that is tagging for who needs to look at this thing early, and we know that tags are insufficient for that. Improving that tooling on Drupal.org is something that is somewhere on the DA's well overworked teams list of things to do. But yeah, improving that process is something we need to do, so we can say no earlier. Thanks. Hi, quick disclaimer, I'm not a Drupal developer, but if I had to pick something that Drupal shouldn't be used for, it's the infotainment system in your car. Okay. That's another disclaimer. What I'm, another disclaimer is that what I'm about to talk about isn't really about me, it's about a friend of mine. And so imagine, visualize this pecking order. You have the CTO, you have the vice president, and then there's me, I mean my friend. And, asking for a friend. And then imagine this scenario. There have been a couple of releases, two of which have been rolled back, and this third time is a third try because this particular feature didn't quite work as it was expected. So now you're releasing at nine p.m., because we need to get this out the door quickly. Again, there's my friend, the vice president, and there's the CTO. It's nine p.m. We're doing the third, my friend is doing the third try on that deploy. Suddenly the CTO, oh by the way, I'd like you to add these, this, this, this change. Do it. How do you say now? Again, the CTO is right here, the vice president's right here, and my friend's right here. And here's the dirt. That depends on the company culture. Good example there. I'm gonna go back to the 80s for this one. You can't get that over there. No. I do remember the 80s, at least some of them. General Motors, on their assembly line, had a policy of the line doesn't stop. And if someone stopped the line for some reason, good chance they were gonna get fired. GM had a reputation of producing terrible, terrible cars. Toyota had a policy of any single person on the assembly line can stop the line if there's a problem. Quality is everyone's responsibility, which meant they didn't guarantee the number of cars that came out of the factory every day. But if you stop the line, the state information supervisor was not, what did you do wrong while you're holding us up? It's, what's the problem? How can we fix it? And Toyota produced much higher quality cars, and they worked with GM and taught GM how to work in that model, and the quality of GM cars went up when you had people empowered to stop the line in the name of quality. In that case, they're saying no to predictable output in favor of quality. The other approach is saying no to quality in favor of predictable output. So, whoops, the question isn't how do you say no, it's what do you say no to? And at that point, it's okay, CTO, are you going to say no to having a good chance of this actually working in favor of this feature? Can we say no to this feature and do that tomorrow or next week? Which are you going to say no to? Quality or shipping? There's a good argument to be made either way. Personally, I would opt for quality. But explicitly, you're going to say no to something. Be conscious of that, and conscious of which one you're saying no to, and stand behind it. Okay, so my proposal and my question are kind of the same tiny bit of topic. So I think Drupal 8, we should not use functions, like at all hooks, right? Why are we not using like class interfaces, for example? We have a lot of hooks, and we could only kill off so many in one cycle. That's pretty much what it comes down to. A lot of hooks were replaced by plugins. Some hooks were replaced by events. Some were replaced by a YAML file. Some we just didn't get around to replacing because there's only so many hours in the day, even over four years. But it is the ideal state. I cannot say it is an official plan, but I would not be surprised if hooks don't exist in Drupal 9. That's as much as I'm willing to say on the record. Hey, Larry, one of the things I want to continue saying no to is doing bad things in templates. One of the reasons we added twig was because we knew making database calls in template files is a thing that we do want to say no to. And one of the reasons we added twig was to be able to say no and really mean it. Make it so that you couldn't even make database calls from twig files. But to extend from that metaphor of Jurassic Park, you were so obsessed with whether or not you could. You didn't stop to think of whether or not you should. Another encycl quote from Jeff Goldblum. Life finds a way. I was in a twig session yesterday, and one of the hot features that was shown off was you can use this debug and you see what variables you have, you see what objects you have, and you see what methods you can call on those objects. And I thought to myself, wait, the whole point of twig was that we weren't going to make function calls. We weren't going to do anything other than print variables. How do we remember what we said no to and mean it? Now I don't want to say that any one method call in twig is dangerous. I think we've seen over the evolution of twig over the last two years in Drupal, is that what we really meant was we want the functions we want and we don't want the functions we don't want. But that's hard to maintain over time. How do we keep our nos specific and meaningful over time? Documentation, peer pressure, and setting a good example. It is possible to run a database query from twig. You have to write a twig extension to do it for you. For the love of God, please nobody do that. But even putting rubber bullets in a gun doesn't mean someone still can't put a hole in their foot. You could use a, or you could try to use an impact driver to pry open a can of paint. I can't stop you from trying to do it. I just think it's a really stupid idea. Documentation, peer pressure, and setting a good example. Which means making sure course templates are things we want people to emulate. Garland's the theme, for instance, was a terrible, terrible theme for people to emulate. It did all the things we told people not to do. Bardic is better in that regard and it got better in Drupal 8, but we need to make sure. When we're doing something in core, we're doing it the way we want contribute to emulate. And that's something we talk about a lot in the issue queue, actually, is contribute is going to look to core for examples and they're gonna copy and paste stuff out of core so let's make sure we do it the way that we want contribute to do it. That's very valuable. It's hard, but it's valuable. And so clearly stating what we're saying no to and then making sure we follow through is really the best we've got. Thanks. Okay, so what I think we should remove from Drupal 8 is the module uploader UI. You're not the first to say it. Okay, but my question is just in the Drupal community, do you think we have enough people who are able to say no for people or do we have too many people who are able to say no so then no one will say no because they expect someone else to say no? Until about two months ago, my answer would have been nobody has the ability to say no except Drees and Drees refuses to do so and that's the problem. The rather intense discussion last fall after DrupalCon Amsterdam around leadership in Drupal, part of the outcome of that was this revised power structure for core. Is it perfect? Not even remotely, but it is a step forward. It does mean here's the people who can say no on markup grounds. Here's the people who can say no on accessibility grounds. Here's the people who can say no to a certain subsystem and we don't say it in those terms, but it is definitely an improvement in that regard and I'm very, very happy to see that happen. That is a big step forward for the project to have a structure by which we know who gets to say no and who should be saying no. If you're a subsystem maintainer in Drupal 8 or a module maintainer for Drupal 8 core, part of your job is to decide what you should say no to for that subsystem or that module. That is a power and authority that you should exercise very, very carefully and not be a dick about it. But part of your job is figuring out what to say no to and saying no at the right time. And that's the responsibility those people take on now. Thank you. Anyone else wanna tell me no? No. No. Someone just said yes. What are you doing here? Thank you, enjoy the rest of the conference.