 Alright, we're going to get underway. So Drupal is 16 now and we could expect some growing pains by this age. Anyone who's got teenagers would know what I'm talking about. But this is kind of my attempt to distill my incongerate ramblings to my colleagues into something cohesive and I'm going to present first of all what my answer to this hypothesis and then we'll have a discussion about it. So there's a bit of time for both. So first of all the answer to my hypothesis, does Drupal have an identity problem? And if this thing works, yes it does. Alright let's discuss it. Now some people may be here evaluating Drupal or new to Drupal and I just want to reassure you that everything is awesome. There's no trouble in Paradise and all free open-source software projects have these issues, right? If you had an open-source project that you started today and I told you in 16 years there'd be people, this many people would come together enough, care about it enough to have these kinds of discussions, you would take that any day of the week. So we're in a good position to be in and I think someone said that open-source is basically a process of violent agreement and that's what we're trying to do here. We're trying to hash out what we think the problems are and have a conversation two-way and we work together and we're only here because we care. So let's get into it. The juicy bits. First of all, a bit about me. I just want to clarify that I'm not just some random guy waffling on about Drupal. So I've been doing this for eight years or so if you look at my Drupal.org profile but I actually didn't sign up for an account for about a year. So it's pretty ordinary. Yeah. I've worked on over 450 core patches in Drupal 8. I maintain four core modules, 40 class Contrib, I'm a member of the security team, a senior Drupal Dev at PNX or previous NEXT and I think that I'm at the point in the relationship with Drupal where I can say we have problems or we need to talk and I think, yeah, I think I can have that frame. So I'm really not used to this double screen thing. So let's start with some naval gazing. Before we look at the problem, we've got to have to gauge if we have an identity problem and so let's just start with a really easy question. What is Drupal? Right, now there is a good saying. This is from Angie, Angela Byron. Drupal is a content modeling framework, a content management system and a kick-ass community. So even when you ask a simple question like what is Drupal, you have to answer in three parts. Drees has lately been calling Drupal for ambitious digital experiences but those of you who are familiar with Ember would realize that that's their catchphrase. But I think above all the third line is the most important and as a community we've always skated to where the puck's going to be next and we dragged the software along. So Drupal is bigger than the software, it's the people and their knowledge that make Drupal great. So if we look at the definition on Drupal.org and this is really big on my screen but I'll read it. It says, Drupal is content management software. It is used to make many of the websites and applications you use every day. Drupal has great standard features like easy content authoring, reliable performance and excellent security. But what's that sit apart is its flexibility modularity is one of its core principles and its tools help you build the versatile structured content that dynamic web experiences need. There is something missing from that definition. Now I put the emphasis on the words building and make. There is nothing in that definition covers install it and you're done. There is nothing about a product. It's for making things and building things. So is Drupal a product? There's no mention of it in our mission statement. There's no mention in our three tier definition. Or is it just the framework? So to answer that, I'm going to reference Angie again, she gave a session in Dublin called how our competitors are kicking Drupal's ass and that's the link if you want to see the slides and there's video as well. And in that session she talks about these WordPress, Squarespace, Wix, Sitecore, Adobe Experience Manager and Contentful. Now they're kind of in categories WordPress, obviously everyone knows Squarespace and Wix, they're like build your own website using our UI type thing. Sitecore and Adobe Experience Manager, they're aimed at the enterprise end of the scale and then Contentful is kind of the odd one out here that's basically content editing as a service and it provides you with a REST API to access your content. But if you look at all three, all of these here, there's a pattern, they're all complete products. The things that aren't mentioned in there, Laravel, Symphony, Rails, Django, these are the things that I see Drupal as a competitor to. And even ourselves, we compete with ourselves, but I'll talk about that later. So are we a product or are we a framework? Maybe we are a product, just an ugly one that hasn't synthesized yet to the beautiful butterfly. We're still getting there 16 years later. So what is a product? Well, a product serves a need and it fills a purpose and it solves a problem. Does Drupal do that? Out of the box? And if it does, what problem does core solve? And like on its own, not much. Like is there anyone in this room who's ever built a site with just call and just the stock themes? You're too in a prize. I think instead of asking what problem does core solve, we probably need to ask who's problem does core solve? And in reality, nobody. There is no specific person that core is built for. But we have a product manager. We have two product managers for Drupal call. Were people aware of that or not? So their job is to evaluate things for Drupal. Do they fit what constitutes our product? And so because we don't know what problem or whose problem we're trying to solve, we just keep adding things to core because we have to keep competing with those competitors. But we don't really even know who our audience is yet. Is it developers, site builders, designers, amateurs, hobbyists, enterprise, content, all of these people have used Drupal for something in the past and could all stake a coin in saying that Drupal is for them. We don't even know and even core doesn't know. It's confused. So I'm going to show you some exhibits. These are from just from core. One is the CMI initiative versus place blocks and outside in. So everyone's familiar with CMI. It's like an initiative focused on a Git workflow. You separate your configuration from your content and you go through a deployment pipeline. You make your changes in a pool request, you check it into the code base, goes to dev, it goes to staging, and then it goes to production. And you've got a full pipeline there. But then we have two new modules in core that are called place box, which is an 8.2 that's led to basically easily place a block in the context of the site. You don't need to go to the blocks administration page. You can hit a link in the toolbar, hit place box, and do it all from there. And we have another one called outside in, which lets you, you can edit your menu items, but you can also edit like your site slogan or your site name and all that through the front end part of Drupal rather than going into the back end part. Now, are those features the last two focused on developers or are they focused on site owners? And if they are focused on site owners, then where does that leave CMI? Because those last two were changing config entities and configuration on your environment that can directly sort of conflicts with what you've got tripped into your Git repository. And if you deploy and do a config import, well those changes are lost unless you somehow sync them back from production back to your, you know, to your Git repository. So are they a user facing feature or are they focused on developers? I don't know. Exhibit B, composer versus the update UI module. Now Bojan maintains commerce and he also maintains the address module. So the address module in Drupal 8 relies on a composer lobby that the commerce guys wrote called addressing. And it's like a best of breed address library for PHP. It integrates with Google's addressing system. And it's, you know, it's not just for Drupal, it's for the whole PHP ecosystem. And it's being used by other PHP projects already. But to install the address module, you need to install, sorry, the address field module. You need to install the address library. And that's done with the composer. So his argument is, well, people who want to do a production update on CMS isn't our audience anymore. Now the thing is, if you install the address module and you do the right thing and you go to the command line, you use composer and you do, you know, composer install address. You get that library. And then you do the right thing and you're on your production site and you see the little warning says there are security updates available and you click on the update now. The site is hosed because when you hit that button, it fetches the table from Drupal.org which contains the vendor folder. And that vendor folder writes over the top of your vendor folder and blows away whatever you install with composer. So if we're using composer for a workflow, why not use a real framework like symphony or something? Why use Drupal? You know, have we abandoned our origins which was that you could click something together as a site but without having to go into command line into the code. And the worrying thing about this is as of July 2016, I've got some statistics from the DA here, but 20% of all D7 module downloads were from the update manager in the UI. So that's one in five module updates, module downloads. And if you think about how many module downloads there are from all the CI systems out there that are building, right? Still out of that one in five is done in the UI. That's Drupal 7. It's still 13% for Drupal 8. So we can't just say, oh, yep, you've got to use composer because the fact is more than one in ten of our users still uses, you know, the update UI. And where does that leave the developers, right? I don't want to work on the update module. I've never used it. I only want to work on stuff that I'm interested in and I haven't got limited volunteer time. And if, I don't know if you're aware or not, but the update module delayed the release of Drupal 8. It was one of the critical bugs in that critical bug countdown that was right. So it's again, and there was an open critical issue that said if somebody doesn't step up and maintain this and fix it to work with Drupal 8, we're just going to remove it. That was our solution to fixing the bugs in it. Someone stepped up and maintained it, and that was David Rostine who's maintained Drupal 7. But largely the people who don't use this are expected to maintain it and the people who do use it aren't equipped to maintain it because they don't want to get involved in development. They want to use what Drupal has been focused on for the site building. So again, we've got this confusion going on. And now I mentioned before we have two product managers. Well, spare a thought for them. How do you try and evaluate whether something belongs in your core if you have to resolve all these things we're talking about earlier? And also how do you do that when your day-to-day job isn't building sites with Drupal? You know, being the product manager for Drupal is for core and working on core is a full-time job for these people. And it is, it's a huge job. And so you kind of, you know, once or twice removed from the day-to-day work of building sites with Drupal nowadays. And you have to evaluate, is this a framework feature that I'm evaluating or is it a product feature? And who is the user you target? You know, we had a site before with six or seven people listed. And then all the while, this is what we're up against from our competitors, you know, they shipped this beautiful picture of, you know, everything's tickety-boo and it works like this. This is a house. It's always a house, right? This was built with Drupal and you didn't want a house, you could pull it apart and make an apartment, right? They have a fixed feature list, they have defined use cases and they have dedicated resources. We're a ragtag bunch of volunteers, right? So this is what we're up against and our best foot we put forward is the standard profile. If one's familiar with the standard profile, this is what you get, right? We're trying to solve everything generically, so we do nothing well, right? Everyone's heard the phrase jack of all trades and master of none. That is the standard profile. But we need to compete, you know, so people are evaluating Drupal as a solution and they've got their feature list and so we go into this death cage feature list showdown with these other people and so it's an arms race and the only way we compete is by we keep throwing modules at the problem. Product X has feature Y, we need to compete and so we keep throwing stuff in core and that comes at a cost because the maintenance burden goes up and once something's in core, it's much harder to iterate on. Innovation in core is slow and that's because there's quality gates and I'm not I'm not necessarily saying that's a bad thing but if something's in contry, it can evolve rapidly, it can get ramp up fast, change. As we know, Drupal 8 took five years and I can say this is about forum modules because I maintain it but code is like core is where modules go to die. Forum is an example, right? It hasn't changed in seven years and you can surely not tell me that nothing has changed on the internet with regards to forums in seven years, right? Do we really think that 2009 was the highlight of forums on the internet? So contry was where the innovation occurs. So anyone here who maintains contry, I think there is a bit of a, you know, there's a quality gate there. Some people don't think, oh, it's contry, but it's not as quality as core. If you put it in core, it's got that stamp of approval but that's not necessarily so there are plenty of contry developers who, and particularly Drupal 8, who apply the same level of rigor that is applied to core. So innovation in core is very slow. But we have Sember now. We can add new features. And this is an attempt to facilitate faster innovation. But my opinion, looking at 8.1 and 8.2, I honestly think Sember killed small core. Now small core was an initiative where we tried to make core focused on doing the framework stuff well. And all the extraneous stuff like forum, I can keep saying it, I'm just lucky to be able to do that, was going to be removed to contry. When we got some of the way we moved poll module, blog module, for example. But now that we're in this six month Sember cycle, we have to have something new to herald every six months. Dree's previews is at the Drupalcon, right? Coming in 8.3, we've got X, Y, Z. And nobody wants to download 8.3 if all it contains is bug fixes. Stability is not sexy, right? Bug fixes aren't sexy. Yeah? So we've got these experimental modules. Now this is a session from Gabor and I recommend you go and check it out. It's really good. And the idea behind experimental modules is we get more eyes on our future enhancements. You know, we say, well, we think that this is something that we want to have in core. It's not fully baked yet. So we're going to put it in core as an experimental module. There's no warranty but we want people to have a look at it. So it's almost the notion of a promoted contrary module. And that's really what it is. It's in core but we don't certify that it's got anywhere that it's not ready yet. Now they have 12 months to mature. So once they're in, they have to get to a beta. Then they have to get to stable. If they're not stable in 12 months then they're removed. Now I think migrate module must be getting close to that 12 months but it's getting close to the beta as well. So things are happening there. Now with these experimental modules there are no guarantees, as I said and Gabor goes into it in detail. The APIs are fluid and we reserve the right to change things. And so anyone who wrote migration code for Drupal 8.0 will know that in 8.1 it changed and it changes again in 8.2. And the maintainers of those modules are well within their rights to do that because that's what we document in our experimental policy. By that, as people building projects for clients doesn't really give us any solid platform to build on. And if we look at say for example this 12 month guarantee now maybe that 12 month guarantee would be a good thing if we had it for Drupal 7.0. I mean overlay module and dashboard module and the like probably wouldn't have lasted as long as they did but the shifting stand these create doesn't really give us much certainty when we're putting projects. So if you're using these and Gabor talks about this too you've got to be willing to be on the bleeding edge, right? You've got to be prepared that you might have to reply some patches. You might have to reinstall your site a few times. And so they're not recommended for production. And the other problem that I think these create and as I said, this is my opinion is that we're competing with ourselves. Now everyone's familiar with work bench moderation that became content moderation in core but content moderation is experimental. So if I'm building a site on 8.2 do I use content moderation or do I use work bench moderation? And the answer varies, right? But if I'm a developer do I contribute patches to work bench moderation or do I contribute them to content moderation? But the two aren't compatible. And for what it's worth this talk of completely changing the way that transitions and states are configured in the core module and that's between 8.2 and 8.3. So again, there's no stability. If you're building a project for a client and you're starting today and you know it's going to be finished in six months when 8.3 is out you probably would start with content moderation if you were doing a reinstalled sort of workflow where every time you build you reinstall. But if you were going with actual production data you'd probably stick with the first one. Now there's plans to create an upgrade path from the 8.2 work bench moderation to the core content moderation. But again, there's only one person who's working on that and that's the same person who's working on content moderation in core and also maintaining a lot of other modules and that's Tim and he's doing a great job and he actually had a blog post recently about how hard it is to get something into core and I recommend you go and read it. It's really good. But what I'm basically saying is it feels like we're duplicating a bit of effort. Maintaining two things in similar places. So I'm going to change tack a little bit here and just talk a little bit about what I said there with one person maintaining it all. Who here considers Drupal their primary source of income? So we're talking about 75% of the room yet who here has contributed something to Drupal today or this week or this month or this year or if you're an agency and your primary business is Drupal are you giving your employees time? Now there was a session yesterday from Spark and I recommend everyone watches it when it's the recordings up but they've basically said that from now on everything they build will be on Drupal.org even their client code. If it's done on Drupal.org they won't use it. So yeah, I think we all have a sort of shared responsibility here. And this is a quote that I've said several times and I just want to reiterate it. But for an ecosystem that provides gainful benefit employment for so many people so much work, false to so few. And I'll give you some numbers. I'm not just going to throw that out there. So we had 3,750 people have worked on an issue and I'm just going to do with core here for Drupal 8. Now in six years we fixed 15,000 issues. And that was done by 3,750 people. So that's not too bad. That's five issues per person, right? That's five issues, five years. That's great. We can all do one issue per year but the reality of it is that only 270 of those 3,750 worked on 20 or more issues. And so 270 is only 7% of that. So 93% is the long tail. Now 20 over five or six years is only two or three year, right? If we take it up to 50, there's only 128 people. Now 50 is still only 10 a year. That's one issue a month, right? So of all the Drupal core, 3% of the people that have worked on it have done 50 or more patches, which is one patch a month, five years. So we're not talking about huge numbers of people looking after it here. So let's be optimistic and say that the filter is 20. So 270 people worked on 20 issues or more and it took us five years to resolve 15,000 issues. Any wonder, it took so long, right? Now that's great. Drupal 8's out, who cares, right? But it took us five years to fix 15,000 issues. Does anyone have a guess at how many open issues there are against Drupal 8 right now? There's 11,000, right? That says October 11. And of those four and a half thousand of bugs. Now a lot of them are probably duplicates, right? But there's only so many, not your time in the day that you can spend trolling through. And so if you've been around Drupal long enough, a lot of this seems very familiar. Five years ago before DrupalCon London, Drupal 7 had been out for six months. Frustration with a number of bugs in core, some of the maintainers put up a white flag and said we need to make core maintainable. And that's when I got involved in core development. That was, I saw the white flag. So is this history repeating? And if you want to go back and look into this, that's the original post from Sun saying we have a Drupal crisis. And the second one is a podcast from Lullabot. It had Sun, Catch, a couple of others all on the call eating, discussing it. So is it history repeating? Or can we just pick up where we left off? Now, out of that whole crisis, there were three things that we identified the problem with. One was we needed an unofficial framework initiative. Now we did that with Drupal 8. The unofficial framework initiative was Drupal 7 is a pile of spaghetti. We need to untangle it and make it maintainable. And we largely got there with Drupal 8. There's still a few rough edges, but we largely got there. The second one was to evaluate heuristics for core feature availability. And that's just a fancy way of saying if someone's gonna spend three years working on a patch and then we say, oh, we don't really want that, we probably should have that process up front. And we do have that now. It's called the core ideas queue. So if you've got an idea for Drupal core, you don't put it in the core issue queue. You go to drupal.org slash project slash ideas and you propose your idea. And then you get some people to review it. And if they think it's good, they'll say, yeah, this is good, let's get some more eyes on it. And if you get it to RTBC, then there is a committee of Drupal core committers, so like Alex, Angie, Nathaniel, they all evaluate it. And if they think it's good, I say, they mark it fixed and they say, go create an issue in Drupal core, we're on board. So there are issues where people spent 18 months, two years re-rolling something and only be told, well, this isn't really what we want. So this is, we're there. But the third thing they come up with was Drupal as a platform. And so maybe that's the answer to identity problem. So just to recap what the problems were, we have to determine what goes in core, there's too much in core to maintain, the process is slow, we have to do it generically and we have to avoid bite shed. And so maybe we already have the technology. Maybe we should focus on putting generic building blocks in core and take the product features out and using store profiles to show how to put them together. Which is what a Lego creator set is, right? You can just see it down the bottom here. You get enough parts to build this, this or this. But they're all the same parts and we show you how to build them. And so maybe we need to focus on a real product in core. Something that serves a purpose. Something that shows people how to do things but can also act as a promotional tool. So the people that have been around long enough will probably recognize this as a snowman initiative. Right? Well, I'm gonna say the initiative, formerly known as snowman because nothing much really became of it because we were all focused back here on trying to get this unofficial framework initiative even. And we didn't have the building blocks in core. We didn't have, you know, entity reference and views and those little building blocks that you need to build a real site. So maybe it's time we pick it up again. And so to that end, during Drupalcon Dublin, we had a conversation around what sort of products would we put in core? What would it look like to demonstrate how core would work? Now, originally the idea was a portfolio site because most people that use Drupal just use them some sort and they need a portfolio site. But at the same time, the documentation team have been working on a new user guide and if you haven't seen it, I really suggest you look out and basically takes you through the discovery and the learning process of Drupal through the hypothetical situation of creating a farmer's market website. There are vendors, there are recipes and there's a baked content model, right? And they take you through how you would build that with Drupal step by step. So there's a fixed scope and so maybe, well, not only could you follow from the user guide but you could also see what the end product was. A little bit like these Lego kits, right? Got the instructions you can follow on about yourself but we've already got it here. And the good thing about that is because there's a fixed scope, we can avoid bike shedding. Now, someone proposed that we needed a new user facing theme in core because Bartek is getting a bit long in the tooth and it descended into a flaming bike shed of doom. Because you can't please everyone, right? If you put a new theme in core, it has to be able to have a treatment for every single element that core could output. It has to cover every scenario and every single site because people, the idea is someone installs that and uses that for their site. But if you have a fixed scope, like the farmer's market profile, it's a product you can get a designer in and say you're designing a site that's hypothetical for a market. And then all of a sudden, well, you don't care about all these other elements that Drupal needs to support because they're not in this install profile. So I think personally, and like I said, this is my feeling, that this is the first step in the right direction. So there's an issue called create experimental installation profile. Now this went through the ideas queue. We had a meeting, there was Joe Schindler from Drupalize Me and the documentation team. Gabor from Acquia, Kevin from Acquia, Roy from the UX team and a few others, David. And we said, we were supposed to be talking about default content in call. And we said, well, we don't wanna put something else in call. We wanna actually do something that's useful because if standard profile came with default content, who would care? Right? It's still the same old pile of random bricks, but now it's got a new random brick. So we put it in the Drupal ideas queue and it got RTBC and it got fixed last week. Now I had to change my slides this morning, but I'm happy to have to change my slides because now that means that we can start working on this. And we're not anything more to the standard profile. We're not just bolting more things on the side. And at the same time, we also discussed this idea, which is getting the installer to promote and allow downloading of vetted install profiles from the installer. So that's still in the ID phase, but in first discussions with people, there's some broad support for it. And I like to call this like the choose your own adventure of Drupal. Right from the installer, we already fetch language packs, right? If you want to install Drupal in German, that's not in the table you downloaded. It hits Drupal.org's local servers, downloads the German translation, and then you're away. From that second screen of the installer, everything's in German. So we've got a proof of concept for downloading stuff in the installer. And this would allow us to give install profiles like a first class treatment in core, but you'll notice they're the keyword vetted. I don't think this should be an open gate. I think that this should be something that our product manager's evaluate. And for me, this is the thing, all of the gripes that I've indicated for, this is the thing that kind of reconciles all of them the most, because it allows us to focus on generic framework in core and products in install profiles, which I think is where they belong. And it also allows us to compete because if you think of some of the install profiles out there, open social on Drupal 8 is brilliant. It's like Facebook. And you've built your own Facebook once soon as you install it. We've got commerce kickstart on seven. Everyone be aware of. It's a store in a box. Got lightning, which they're talking about next door, which is like geared towards publishing and media agencies. Got AGOV, which I'm kind of biased towards obviously. So yeah, when in this model, there's kind of something for everyone. Now the problem we've got with the stuff we're putting core at the moment, a lot of the time they're these boat hull pieces. They're great for building boats, but you can't build a house with them, right? If we move to this model, the things that go in core should be things that are generic enough to rebuild a house, a boat, a car, whatever. So not single use features. So the things that I see that fit in here like in line entity form. And there is a core idea for that. Having that. So someone's, this guy is a bit of a lie. No, I think it was me. Now has proposed putting that in core because it's a generic building block. Entity browser is another one. But there's also something that is for marketing because like I said before, stability is sexy. We need to have something to herit with each release. And so we can say Drupal 8.4 now comes with commerce kickstart or Drupal 8.4 now comes with inline entity form. We're not being opinionated about how you use it by putting it in standard profile, but it's there if you want to build things. And we can also market new features and profiles. Drupal 8.4 now comes with portfolio site that now includes an image gallery, for example. There's something for the product managers because they can focus on vetting the profiles, right? Process would be, okay, well, I think that this profile is core worthy. The product managers can evaluate it and they can just direct other reviews of core towards these profiles and contribute and say, what do we think it's core worthy? What do you think of it? And there's something for new contributors. So in the background of the chart, we've got here is what it takes to be a good core contributor. And so down the bottom here, this is also from five years ago. So it's a bit out of date, contributing design plans, whatever. I think you can't say at the top, but right at the top there it says URCHX and then at the very top it says, you're Chuck Norris. But with new contributors, an install profile is largely exported site building. And all of us can do that. It's nowhere near as intimidating as the whole core process. Anyway, I've spoken for long enough. We've got another 15 minutes or so. I just wanted everyone else to throw their thoughts towards me. We've got the microphone here. Yeah, thank you. I'm just curious to know if you've had this chat with the Drupal Association at all. I know that for a while now they've been talking about that sort of installation profile builder and the idea of sort of targeting it towards different communities of practice and having like a fire station profile and a police station profile and a hospital profile, et cetera. No, I haven't. I wasn't even aware of it. Yes, but he's talking about the infrastructure on Drupal.org. Yeah. Yeah. I should remember being on the conference call with you when it was discussed and it was just an idea that everyone seems to really love. So I think you've got a lot. Yeah, so it's not like with like JQuery UI you can like build your custom build of type thing. Is that what you're talking about? Yeah. Yeah, anyway, sorry. I'm just saying I think there's a lot of support behind it. Yeah, I think that's a good idea. I think anything that allows us to market Drupal as a product without feeling that we have to put stuff in core is a good idea. And like I said, this is my own personal opinion. So take it with a grain of salt. Ivan's got the mic, so three hand up. So hi, thanks for the presentation. The Drupal is the community. All right. Yes. And there's different aspects of the community. Some people claim their builders, some developers, some themers, some do various things of these. Some of them more, some of them less, but still everybody needs each other. So people have ideas, they do bug testing, they contribute back maybe time and energy. They cannot put code where they're not here. Sorry, I should have qualified those comments before. That yeah, they're not just code contributions, yeah. Yes. Like, and Donald will attest to this, that there were so many issues in Drupal 8 that were stalled on needs manual testing. Yes, there could be usability or documentation issues that people contribute, yes. But when it comes to code, because I come here as a representative of Backdrop. Yeah. I was gonna say an issue, there's too many issues created on a smaller scale, but the ratio is still the same. And I'm one of the people that creates that. So we create more issues than we can solve. And the goal is to be solved, but... If you go onto Drupal.org today and you find an issue that's been closed, maintainer needs more info for more than two years, and you move it to closed fix, you've contributed. Right? Yes. If there's an issue that's stuck at postponed needs more info and you can provide, you've contributed. I'm not saying patches is the only way, yeah. Yes, yes, yes, you tried the queue, you tried to find duplicates and close them. Yes, this is helping as well. Yes. But I'm saying the small core initiative, though it would please the people that are creating the actual code, making a small core featureless, that's the way that I see it as a site builder, would make me move to something like WordPress. But I'm not saying create a small core. I'm saying core focuses on doing something well, a framework and then we show off what you can do with Drupal with the install profiles and so that the parts are there to build it and it's all well and good to get a box full of bricks but you need to know how to put those bricks together and if you've never used it before, the install profile is the best way to do that and at the moment, the best foot we put forward is standard and I'm saying we should be putting forward a better foot than standard to show people that this is what Drupal is capable of because I would imagine there'd be a lot of people who would evaluate Drupal, install it, you got a choice between standard and minimal. Get to the thing you have created no content yet and go, this is rubbish and never look at it again, right? Yeah, don't get me wrong, I am with you on the foreign thing and I think I was the one that created an issue, I haven't been back in the queue for quite a long time but I was the one that created I think the issue about metrics, core metrics, in order to get some feedback on how many people are presented are actually using core features so we know that this is something that people are not using so let's remove it, it will simplify the developers' life easier. Oh look, the fact is we can't rev anything now, we've got API backwards compatibility but yeah. Yes, it was an issue, the experimental thing is one of the things that I envy sort of like in Drupal now, but what happens if someone starts using the experiment, I know you said no warranties or whatsoever. Well one of them is probably gonna fall out in the next cycle and that's inline form errors so that's been in since I think 8.0, it wasn't polished enough for a stable release so it went in as experimental and it's got a large issue queue, a lot of issues with it, no one really wants to maintain it and so it may fall out and that will be the first one whereas there's modules like big pipe that went in in 8.1 that are nearly, that are stable already because they have people looking after them and they have support so true. Donna said, and that sometimes comes down to people who need the feature being unable to contribute to its maintenance. Yeah and yeah, I don't wanna hug the mic anymore. So it wasn't a question, it was a discussion, that's why so. Yeah, and there's don't have to be questions, the idea is this is a discussion, right? Yeah, it was just from a side builder aspect of things, I understand that we take the plan out of quarters if we do not implement, I don't know, Composer and everything that comes with it but the rest of the community, I don't know if that's half and half or 20, 80% or I don't know what, there's no metrics about that. No. But it will make people unhappy if, because we all know that everything that falls out of core loses quality, that's why we say core quality. Oh, I don't agree with that. I mean. Well it will be a few modules like views or rules that get a big audience behind them but some of them will get back as. Yeah, I disagree. How many tests have you got in some of your contrary modules? 100. There we go. 100 tests, classes in a contrary project. Test methods. Test methods, still, that's. Test cases. Okay, fair enough, fair enough. Yeah. Right? So I think that the notion that contrary isn't as quality as core is, look there are some places where it's got awful but that's, I think I wanna challenge that, you know. And the fact is that a lot of the modules that are, like you need to build a tree plate site are maintained by people who also work on core as well, you know, which adds to the burden and the problem about there's only so much time in the day but it does increase the quality of those modules, yeah. Hi. To some extent I often describe what we do is that we're a small insect living on a large mammal because we're a small agency that builds a lot of stuff in Drupal but 99% of the logic we build is contrapped, right? Yeah. So that's unusual. We have got developers on the team but development is kind of unusual as opposed to the rule. Most of it's like logic, you know, database logic. One of the things with core is cause like we've just bounced off eight recently. We done some small sites in eight then we had to do damage control for someone else's eight site and went, wow, it's just not here really once you start to do any heavy lifting. What I find interesting is core is running around trying to compete with stuff that it doesn't really compete with. It's just trying to compete with SaaS services or it's trying to compete with corporate CMSs. Whereas what Drupal does great is I'm a framework which then allows you to plug other things in. That's kind of what I was saying in this slide back here that we, like that list doesn't even mention any of those other frameworks. Come on. Yeah, yeah, yeah. Yes, but that's what we're competing with. We're competing with .NET. We're competing with Silver Stripe and all that sort of stuff. And the reason we can win is because you can say, well, 95% of this is already here which isn't really kind of true in Drupal 8 but it looks like core has put a huge amount of effort into producing stuff that I don't know whether anyone's using. And it's trying, core is trying to be a CMS on its own even though that's not what was successful about seven was that it didn't do very much but because of the contrary community it means you could build. I think that that will catch up. Yeah, it will do. But the way, and I'm gonna be pretty blunt but the way it catches up is by people saying, okay, I'm gonna take a chance on eight and I'm gonna try and fill in some of the gaps. And like Spark said yesterday that the client needs to take, well, the client needs to take an active part in that whether that's through sponsorship and that doesn't mean necessarily sponsoring your team but your team might be able to put them in touch with the module maintainer and sponsor a feature from them or fix a bug or something like that. Yeah, we do, we totally contradict you. Yeah, I'm not saying you don't. I'm just saying that if you wanna be like, the fastest way to do eight is gonna get more features is if more people use it and sort of we all work together towards that, yeah. I completely, completely agree. What I'm saying, I mean, everyone's gotta put effort in, right? I'm just saying where is the effort going in a way? It's like the effort, I mean, this is just my perception so I'm not saying this is objectively true but we're having a discussion. Is the effort seems to be going into putting more stuff into core in order to try and make core look like a product as opposed to keeping core out of the way and leaving people to contribute to the contrib ecosystem so that it catches up and is much better in a year or two than where seven is. Yeah. I think it's fantastic the stuff that's happened to the architectural level and from separating config and content level in eight, it's great, it's needed to happen for a long time but it's odd to see the core culture trying to compete with some kind of corporate, you know, global corporate identity. I agree, I agree. I feel it's kind of sucking energy out of other places. I agree. You won't get any arguments from me on that and yeah. If anyone wants to talk about fixing things. I'll talk to you more about it later if you, you know. Yeah. Thank you for the talk. As we know that product manager are, you know, therefore main focus is towards the core, Drupal core, not the contrib. And it was by introducing the idea of, you know, wetting the profile system, you are introducing like contrib profile in the mix and they have to wet that, right? And we have seen that before the release of Drupal 8, we have this initiative of Drupal D8 upgrade for upgrading the module and actually project manager started from there, you know, to promote community to get involved and upgrade their module so that adaption for the Drupal 8 will be better, right? Yes. But then they solely switched to the core because there was no, no kind of movement at that point. So now you are telling that they have to. This is up for, you know, this is up for, this idea isn't approved obviously, but this is what I, what I, the way I think, I think about it, you know, there's probably a different way as you could go. And I'm just trying to see what we have to, we can't just have open slather of profiles. You would agree? Like you can't just have the project browser in the installer and you just pick any random thing because there's no guarantee that it's gonna actually work. You know, so if we have a better profile and that vetting might just be, yep, it's got some accessibility stuff and it's, you know, it puts a good foot forward and it's clearly marked as, you know, something separate to Drupal core and from that point forward, you know, we've got something else we can run a test suite against them. The argument for keeping forum in core is that it provides a lot of tests for the way the comment node and taxonomy integrate together. But if we had these products with the test suites, et cetera, then maybe that bit. But I see what you're saying, like there's only so much time to evaluate stuff and you're trying to add more straws on the camel's back, right? Yeah, so just one more thing. We have a lot of features or a lot of things in Drupal.org where we vet actual things like organization profile are vetted by Drupal association and project application is another where we vet, you know, the developer from the community. But the thing is, if you compare both, like the organization vetting process is going smoothly and not for the project application because there is no owner for that. As compared to, you know, the organization or DA is owner for that, you know, they are doing, they are due diligence for that and we are lagging as a community project application queue and there's a long enough queue for three years people are waiting for. I don't intend to have all the answers. Yeah, so like by introducing another vetting process and then not having an ownership for that. Someone definitely has to be. Yeah, so we should definitely have an ownership and like, and this ownership should have, you know, some kind of well suited person for this kind of job. Yes, yeah, yeah. Thanks, Lee. I was just thinking like, it's a great idea. Would you think that just, you know, promoting profiles on Drupal.org or kind of trying to emphasize the fact that when you download Drupal, like these are all the flavors of Drupal you can download. That's what this screenshot's from an actual issue. An issue to change the Drupal.org download page to be something like this, you know, and the starter is standard, obviously, and you can't see in the bottom here, but you know, there's a blog distribution that this one here says commerce. I don't know if I can... Yeah, I mean, that would be an intermediate step, right? You wouldn't have to change the installer. That didn't do anything. At that point? Yeah, yeah. To do that on Drupal.org? Yes, yeah. That's true. So the comment was that the Drupal association would need the staff and the money to do that, though. Like, is that a real choir? Yeah. But we're seeing at the moment there's definitely this identity crisis you're talking about actually exists at the moment. And so there's an idea going forward how to resolve it. But as an organization who's actually out building websites for clients, how are people managing that now? Because I even see it, it even boils down to myself. It's like I'm building a website and I don't know. Which approach am I taking? Which version of Drupal am I... Yeah. Am I developing, putting it all in code, or am I building a site and... It's not a new problem. The product versus framework debate's been around for a long time, but we've just been busy folks on other things and I'm kind of saying I think it's time now to pick it up again. Yeah, it is hard. And coming to these events is like a good way. The networking that you get face to face is obviously a lot greater than you can get in an IRC channel which is now being fractured into a Slack channel which is now being fractured in Stack Overflow. You know, like, you know, there's one avenue here to talk to people. But whereas if you're online, there's heaps, yeah. So you touched on one of the challenges that you and I have actually experienced while working on a project, which is the fiddle with it in panels, have it in code, and the natural tension where we've got CMI, the Config Management Initiative, and productive kinds of things that allow site builders to do stuff in code. And it seems like, I mean, I don't see a kind of natural resolution to that challenge other than all down to workflow, all down to process. Yeah, I mean, some of the stuff that Adam spoke about earlier today, where they have a separate content authoring site to this actual view site, if you were calling it, right? Yeah, it's a live site. Yeah, it goes- So taking the decoupling thing. It's a bit of a, yeah, yeah. But I mean, there's obviously the permission system to limit who has access to it, but I think there's two different classes of client. There's some clients that are really only going to be creating and editing content, and then there's power users that are going to be editing views and the like. And I think that this is my personal feeling that most of the sites I've worked on, the ones that want to build views that are in like the exception, without going through a Git workflow for it. Yeah, I- Yeah. And then build stuff. Yeah, and I'm pretty sure that must be frustrating for you. Yeah, yeah. And but I mean, I know that there is a UI to download configuration changes in Drupal Core. So you can download that and copy it into the file system and use source tree or a Git UI. You know, so it's, there are ways around it. I know that Pam does things that way. So, yeah. It does, yeah. Yeah, yeah. Yeah. Just real quickly, as you mentioned, obviously, the, that some of the experimental modules will start dropping out of Core for whatever reason. Is there like a process to get that into Contra or is it- I don't know, we haven't had it happen yet. And the only one that is kind of on the borderline is that inline entity form. Oh, sorry, not inline form errors. Yeah, cause I mean, like, that could be an awesome module and it could be useful, but if it just gets dropped out, then it will be able to go. Yeah, look, Paul module found a new home and blog module found a new home. So, you know, if I think that if someone cares about it, then, and they say, yep, well, I'll be that person or they say, well, I care about it and I'll find someone who can help me care for it. Or, you know, or, you know, I care for it, but I can't maintain it myself, but I know someone who can and I can work with them. Yeah. Cool. Awesome presentation. Thanks. Gotta go. So thanks everyone for my shared therapy session. Thank you.