 So this is a slightly fuzzy topic. It's a little less focused than we should require drush or we should require extra things. Go, fight. But I think hopefully it will spark some interesting discussions that actually mesh pretty well with some of the things that we've just been talking about for the last half hour. Basically, the more I've been trying to work over the last year or so on trying to help the actual experience of people who are using Drupal. I'm not like a UX person, but both in terms of the client work that I've been doing and the things that I'm trying to now go back into the core development cycle and work on. A lot of them are about what people can actually do with Drupal outside of just pure development framework, which is ironic because I was the guy who wanted to trim Drupal down to a folder full of include files for a long time. But I think one of the really big challenges that we face is we start trying to polish these things and talk about improving what people can do with Drupal out of the box and what it is like for them is a bunch of trade-offs between features that we start recognizing would be very useful for these people or functional changes, basically like stuff that lives at the product level. Like, I am a person who wants to build websites. I'm going to use Drupal. I have Drupal, and it is a product I build websites with. Awesome. There are features I would like it to have. Those are features that we talk about implementing. CCK, fields and core, that kind of stuff is product features for people who are building stuff. The problem is those add complexity. For better or worse, those kinds of things that we put in as benefits for people are code, and they add complexity, and we have to deal with that. And the other issue at the bottom isn't competition with WordPress or Django or Joomla. It's competition with our own contributed module ecosystem. How do we deal with the fact that as we make core richer and better and smoother, are we cannibalizing or duplicating work, or how do we deal with that tug of war? Who here has heard that views in core would be awesome? Really? OK, there was at least like three people, because there is a roomful of people in the Drupal world that outnumber us probably by like several thousand to one that want views in core. But that complexity issue is a real killer for just taking views and jamming it into core. I'm trying to figure out the best segue. But I have a patch for Drupal core. I'm working on it. It's a feature that I think would be really cool. It's a check box that you click, and it adds a listing page per content type. It's not views. It's not complicated. It's just like 200 lines of code. You check it, and you get a dedicated listing page for that piece of content, and you get a dedicated sidebar block. I really like it. It's 200 lines of code. It's not views in core. So the question is, why did I spend a year to two years talking about how we need to start ditching stuff like that and trim Drupal down to a developer framework and let this kind of stuff go off and thrive and install profiles and contrived modules and distros? Why am I now trying to convince us to jam just one more feature in like all of the stuff that I do think is a complexity problem? Well, first, I don't know how many people from the US are listening right now, but has anybody here ever heard the phrase, only Nixon can go to China? Yeah, only someone who is incredibly aggressively like warmongery can really make peace with an enemy nation, because otherwise they don't trust you. So maybe only the guy who wants Drupal to be trimmed down into a tiny little framework can surprise people enough to get them to commit his patch that adds a feature just while they're confused. Maybe that's my plan. But there's something deeper than just me trying to fake everybody out so I could get a patch committed. Ultimately, I've come to accept that one of the original dominant concepts of the small core discussion, trim Drupal down to a framework so that it's easier to manage, easier to develop and install profiles, spring up in a magical world full of ponies to fill product requirements. That's fundamentally a non-starter. One of the reasons is we don't have a good track record of ripping stuff out and then people who care just arrive and build up user-focused products. That's a fantasy scenario. I want it to be the case, but ultimately, unless we figure out how to start cultivating and building those things and then start spinning off the crap that we don't like to maintain, it's just going to be us killing features and it becoming harder and harder for people who aren't wanting to use Django in PHP with more arrays. People who actually want to build websites are going to suffer very, very badly. So the question is, if small core is a non-starter and we want people to have a useful product in the form of Drupal core, if we want Drupal core to be something that someone can download and do cool stuff with and be engaged by, why add new features to it? Because it really sucks as a product until you start adding contrib to it. I don't like saying that, maybe a little, but not a lot. Drupal core is the world's most complicated blog with forums. That's a problem. Now, anybody who gets into the community for more than a week or so has the aha moment and realizes, oh, you download views and there are these three favorite modules that the person who was talking to me about said, I should download. And they start that ball rolling and suddenly they realize there's this awesome framework and they're going to have to get two books to learn how to use views and stuff like that. But ultimately, there's this aha moment and they start building out the toolkit that we all kind of really consider real Drupal that you start building with. But we know that it's a complexity non-starter to just dump all of that stuff into core and say, hooray, core is now six times bigger, but it also comes with views and panels. So you can do all kinds of crazy stuff. But it's also a non-starter to just chop stuff off and say, someone else will solve that problem if someone actually cares about end site builders. That's somebody else's problem. We're gonna be refactoring our includes folder again. Both of those extremes are non-starters. So the question is, how do we actually start improving the core product to the point where we have some sort of on ramp into using and building Drupal without just opening the floodgates again for 80 bajillion, oh, I would really like this feature kinds of patches or, oh, I'll bet end users would really like this. So I'll put it in. That's a problem. I totally ignored my actual bullet points, but I think all of them I'm still willing to stand by if somebody posts a flicker photo and tries to hold me to them. The idea is that we have a lot of brick walls for people who actually try to build sites using Drupal core. Isn't there anyone who hasn't seen the Drupal learning curve cartoon? It's an uncomfortable laugh, but we laugh nevertheless. And again, the flip side of that is those product features, things that smooth that builder experience, things that make it easy for people to just get rolling, those suck because it means that core gets bigger, it gets more bloated and more complex. That's how we got pole module in the first place and we've been trying to figure out how to kill it ever since. Shouldn't people just use views? Then if we start implementing simple light views in core, then we're in a tremendously uncomfortable scenario where we're essentially competing with one of the single largest contrib modules in Drupal core and we're duplicating work, we're possibly pissing somebody off who's invested several years in it and then we're forcing all the people who tie in with existing APIs to rewrite all of their stuff yet one more time for a new core release because now they should tie in with the core listing API or something like that. There's not a lot of super easy wins in that scenario. And one of the other things that's important is that as we start adding more and more features, fewer and fewer of the hardcore core devs who are in there trying to make Drupal work as a piece of software actually give a rip about things like iteratively improving the experience of adding a new content type if the system works from a functional standpoint, those kind of iterative smoothing tasks that are important, that smoothing out of the on ramp for somebody who isn't a dev, that's a really big other person's itch to scratch and that's actually perfectly okay. I mean, it's guilt tripping everyone into working on someone else's problems isn't a long-term sustainable model. So just telling all of the overworked core devs, you really should care more about my cheese monger who wants to make his nine page cheese website is probably not great. So those are all issues. The big choices we've got are, A, either saying, okay, nevermind, we are just a framework. We realize we don't like this choice and we're just going to strip it down and go back to the fantasy of someone else will solve the problem outside of core in contrib. The other one is just shouting wee and jamming everything that anyone uses to actually build Drupal sites into core. Core becomes six times larger but now the top 50 modules are built in so who wouldn't like that? It's like a cornucopia of crazy modules. That's probably not a great direction but I mean, it's one way we could just say the goal is that someone should never have to use contrib ever to build out a major site. You should be able to build out anything other than like one of the top 10,000 sites just using core. Another option is we can just keep sucking in that weird middle zone where you can't actually build too much with core but we still keep all of the sort of half vestigial remnants of when we were trying to clone slash dot in like 2003. That's all there and we don't want to jettison it because there's people who still want it but we're not really willing to actually make any new concessions to those people for things they've been starting to want to do since like 2005 on their websites. The other one that I've been talking a lot about is we treat it like one actual downloadable product. We're not like kicking stuff to the curb and saying go play and, you know, go play and contribute. That's where pole module lives now, have fun. But we ship that framework basically with install profiles that can configure essentially a 60% configured website for a use case that it's an on ramp for someone essentially. I can say, oh well I wanted to set up a brochure wear site for a small business or something like that. It's not like we've added all of those contrived modules. It's not like we're trying to duplicate every piece of functionality someone is going to use on an eventually shipping site but that early on ramp, you know, that first 12 hours you spend with Drupal trying to figure out what the heck is going on, actually providing them some pieces to work with to say oh, okay, that's the kind of site I want. I'll do that. But that actually requires features because we come back to the problem of you can't actually build out many of those kinds of install profiles using what you have with Core. I ended up arriving at the listing feature that we were talking about because I'm trying to work on an install profile to go into Core that does a little bit more than standard profile. Eight to about a dozen people built out test sites trying to experiment with it and what they found was if you can't list stuff, you actually can't build much which leaves you with log forum poll, maybe tracker, it's a tough problem. Lisa from the D7 UX project and now the Prairie Initiative, she's really spearheading a lot of interesting stuff, has used a restaurant analogy. What she said is that Drupal is like a restaurant that you walk into and instead of a menu, the waiter walks up and says we have every ingredient in the universe. Tell the chef what you'd like. Also, you're probably gonna need to ask one of the other diners for a recipe because they did some of that hard work but you might wanna change it. Do you have any allergies? I don't know. That's problematic. That's daunting for somebody who isn't really excited about that specific experience and that's sort of what like installing a fresh copy of Drupal Core and trying to come up to speed on the what can I do with this thing question feels like. So the idea is that putting new stuff in is kind of inevitable, we do it already but if we start trying to shape questions about what we're going to put into Drupal Core and we're informed by this issue we're trying to make that on-ramp experience easier, how can we use some basic heuristics to determine what should go in and what shouldn't go in so we can avoid the pure floodgate of hey, I know someone who needed this feature so we should go in now, that's a death spiral. But the first thing is something that we've always kind of agreed on, pure framework-y stuff, pure Drupal plumbing like database the next generation or a caching layer. Okay, that goes into core, that makes sense. There's never really been too much argument about those kinds of things. The other one is and there's a little fuzziness around what really constitutes can't live in contrib but stuff that really can't effectively just live out there, stuff that has to be a part of the baseline, the baseline install of Drupal for it to really work effectively like language localization. You can't bolt that on to a system that doesn't have it baked in to some degree so it's gotta live in core or at least some percentage of it has to. The other one is stuff like just pure defining features, stuff that captures the essence of what is Drupal versus WordPress or Cake or something like that. Those features like the fact that you can make content types, different kinds of them, you can segment your content and choose the fields for them. Those kinds of fundamentally defining features are very valid to say this needs to go into core because it is what is Drupal. If you take that away, you essentially just have lots of arrays and a request handler. The final bullet point is actually the trickiest one that's the easiest for us to get super mired in and that's super sexy stuff we just couldn't resist putting in or we tricked someone into putting in. I'm pretty sure I've actually tried that on Dries once or twice. I do still actually owe him two ponies that I promised in a blog post once for one of those commits. It's really hard, especially if we're willing to acknowledge the real genuine needs of people coming in and using Drupal as a site building product to avoid those occasional falling off of the wagon and we committed something that we later regret, but it was really, really cool. Yeah, that's the stuff we committed just because we couldn't help ourselves or stuff we pushed through just because, oh, but it's so yarny. The basic reason I'm trying to get this conversation going is so that we can start asking ourselves, beyond my ha-ha, I've got a patch, I would like it to be committed. I would, but the deeper question is, why should it or should it not be committed? What are the heuristics we can use as a community to determine whether or not we're going to let something go in and potentially increase that complexity cost or not? One of the things that I think is important for us to consider is how a piece of functionality affects that first four to eight hour experience of a person evaluating Drupal. This is not the same as we would like a hypothetical, completely non-technical person who should really just be using a blog and clicking through and adding pages to our blog. How can we make them happy being a site builder? That's not what I'm saying. The issue is for those people who would be site builders, who would maybe start going out there and downloading views and downloading panels or even say, God help them, roll a custom module to do something. How do we smooth that first four to eight hours in which they're staring at the front page of a fresh Drupal site and saying, so, what do I do now? Right now the answer is, congratulations, start doing your schema modeling. Yay, you can make content types in fields. Start decomposing your problem set into content types. That's a hard sell for that first four hours. Lisa's restaurant metaphor, one of the things that she said is very problematic is that we don't give enough payoff in that very, very early part of the evaluation curve for people to decide it is worth my time to keep at this. It isn't that we have to deliver 100% of an end site function to them when they click install. It's that we've gotta do a little of this negotiating dance with the person who's staring at it and saying, should I keep at this or not? And learning how to decompose your problem into content types and fields and now download views so that you can list stuff, that's a really hard, it's that learning ledge horrible cartoon. That's how that ledge happens. So beyond asking ourselves how something affects the first four hours. Well, I mean the negative side of that is also, if someone would only really need this functionality, say two weeks into the build out or when they wanna roll it out, well, hopefully somebody who's done that a bit of that dance with Drupal and figured out they want to try to continue building, well, we wanna start steering them towards the world of contrib once they know they wanna stick at this. So it's not that we need to start dumping XML site map module and image galleries and stuff like that in there. It's that we at least want them to get a little farther on before we say, have fun with contrib, start filtering your 12,000 modules. The other question is can we implement it simply in core? Both from a code perspective because we're not interested in just jamming 600 additional K of PHP and JavaScript and stuff like that into core because that's a problem. It's not like core devs don't have enough to deal with already. And also from a UX perspective, if figuring out how to implement a particular feature means that we're gonna have a five-person UX team tied up for the next six months just trying to figure out how could this be done in a way that makes sense? Maybe that's a problem not to try to solve in core right now. That's not an easy win thing that we can do to smooth that on-ramp experience. It's a huge undertaking. And we should at least treat it as something very different than we're adding a feature. The other question is can users grow out of our on-ramp style feature and start using more powerful tools in contrib that have the luxury of iterating faster and trying out things and basically just adding features and experimenting at a pace that core doesn't have the luxury of? Are we going to force people to undo a bunch of stuff they did during that? I'm getting my legs under me process with Drupal core when they actually need to start using the more powerful tools in contrib for site building. The final question that I think we can really look at here is also does this thing in core now make life much harder for the contrib ecosystem or even a significant sub portion of it? By implementing an easy win feature, are we now basically like building some goofy addition on our house that means our neighbor can no longer actually get into his backyard? This was a problem during the very early phase of database the next generation where Earl Miles working on views was suddenly faced with the prospect that the entire views query generator was going to have to be rewritten from scratch. And there was a back and forth sort of dance that occurred between the database the next generation team and Earl and another group of people who ended up jumping in and helping with that relatively significant work but it's an important consideration. Does this easy win we're implementing now make it much harder for the people evolving solutions out in contrib to do what they do? If it does, it's absolutely a red flag. And finally, these kinds of product level features things that make life easy for people using Drupal as a site building tool or whatever, they can't be driven by sitting around and saying, oh, I bet it would be really cool if we need things like actual product use cases and user stories, the kinds of things that like product people and UX people and design people and workflow oriented task thinkers are actually talking about when they think of product. If we have a product to build websites, okay, what are the tasks involved in that? That's where we get our possible features that might be useful, not just from me really wanting there to be a talk like a pirate filter. You know, that's not a product driven feature. And this is one of the reasons why I think having a couple of targeted use case oriented install profiles in core, even if they don't build out hugely complex sites, they give us use cases that we can ask, does a person building that kind of site need this? Does a person building that kind of site need it? If the answer to that is no for all of the different kinds of use cases we've got, maybe we just don't need it in core. If it turns out all of them are hitting road blocks and brick walls when they try to build out sites like this in that sort of early on ramp phase of figuring Drupal out, we should think about it. And that's how we ended up coming to the conclusion that there needs to be some sort of basic way to list content because everyone building out a simple site with core hit the wall trying to list stuff. It appeals to the particular use case we were trying to describe and it was a big blocker during the very earliest phases of trying to figure out how to make things work. So that's it. That's all I got. Everything else after here, I think we've still got like 10 or 15 minutes or something like that. Any questions? I think it was, okay. Oh no, I don't think so at all. Yeah. And I think I'm a little neglected because that's what I vigorously advocated for several years and eventually became convinced that it was a non-starter because if we start pulling contrib modules into that main on-ramp download, essentially we are putting views in core.