 So, everybody welcome. First session of the day. I guess right after coffee break. I think it's not awake yet. I know I'm not. Welcome to our core conversation. Less is more. So, the primary tenant of this conversation is really about components that are in core, how they are maintained and really having a discussion about whether or not certain things should be removed from core, and what that process might potentially look like, what are some hurdles to that process, whether or not anything should actually be removed, additions, you know, it's actually a large topic. I'm David Hernandez. I work for FFW. My role is largely training, but I'm also a coordinator for our contributions and community activities. This is Peter Willanen. Hi, I'm Peter Willanen. I work for BioRap currently. I'm an application architect there. Peter Willanen and Drupal at Oregon have been a long time contributed to Drupal core and on the Drupal security team also. You're wearing the same shirt. And I'm wearing the same shirt just for fun. We're both from New Jersey, and we rock with our sprints in our camps, in our meetups. Okay. So, some history, some baselines. Why might things be removed from core? So, this has happened in the past, obviously, certain things, modules, components, APIs, things that have been removed in the past, but what is sort of like the rule set, the baseline we've sort of adhered to. Some things are inherently insecure, like we've removed the PHP module because of that. Even if there was nothing wrong with the module itself, it was pretty much a bad practice to have people embedding PHP everywhere, and it creates all kinds of problems, so we decided that was a very good reason to get rid of that thing. Some modules have, essentially, we've just moved on from the technology and the things that they do, like the OpenID module was removed because of that. Again, not necessarily anything wrong with the module itself, but when you start having use cases of like, why do we need this thing anymore? It's not really something people use very much anymore. That's another good reason for why something gets removed. If they're, you know, pretty much the same thing as the next bullet point, if they're not commonly used, they don't have good use cases, their features are not particularly good, those are all reasons why something starts getting on the hit list. Lack of maintainers in interest, I think is something that we should talk about more, because, and this goes along with things like the technical debts and innovation and things like that. There are a good number of modules that exist in core right now, and are there, I think, essentially for just the feature set so that they are something that we can identify as being part of core as a feature, almost, you know, I call this sort of like the marketing bullet list of being able to say that like out of the box Drupal does these things, right? But those modules are often there, even if they're not insecure, they're not buggy or anything else, they often will lack feature sets, they lack innovation, people are not paying attention to them, they don't have anyone who's giving them attention and putting effort into them, so they start stagnating right? And often it's, they're better off not being in core and being in contrib instead. And then, yeah, better alternatives, so sometimes, and we see this with a lot of things I think, there's always better alternatives that are in contrib, so people will tell you things like, oh, I never use the forum module, I always use advanced forum instead, and anyone who ever builds a site with forums will use advanced forum instead of the forum module, so it's like why is that even there? And I think it's there just to say, we have forums in core and you can use it out of the box. So we do have some modules that have been removed. It's like the PHP module was removed for a trigger profile poll blog, those were all removed for various reasons. But the one thing we want to really identify here and make a point of is these dates are added for each one of them. So we went and looked at when the original issues were opened for these modules and then when they were finally closed and those things were actually removed. And you can see it took what, six or seven years to get rid of the poll module. So it's not always an easy process, it's not always easy to get consensus from people to get rid of things. And sometimes it's not always easy to actually physically remove things because some of those modules can start becoming intertwined with various features that are within core. Alright, so what are the consequences? Because nothing's for free. Some people will say, well I'll just leave it there, like who cares, it's not a big deal, why worry about it, we have other fish to fry. But there's always consequences for doing that. A big one is the stagnation for development. So some of those modules that are there, they're okay, they could be a lot better. I look at things like the form module or the color module, which I think actually do have value for people who are building sites and using those particular features. But they will stagnate in core because often it's really difficult to modify those features, get them attention, get updates to them. Whereas if somebody's really loves and cares about those modules and works on it and can trip and has access to them, like commit access to those modules, can actually work on those feature sets, work on enhancements, experiment with different things, listen to the user base for those modules instead of just the entire core user base. And they can prioritize the features that they want instead of core developers as a team having to work on their own set of priorities which are going to be completely different. And then maintenance burden, right? So it's not just the maintenance burden of the individual module because you have to look at core as a group as itself, right? So when working on core development, if like a patch needs to be made to modify an API, right? Then it's not as simple as just modifying that API. If that API is used by seven different modules inside of core, all of those uses, instances have to be updated. And that can be kind of tedious when dealing with like I have to update these five modules that like nobody uses anyway and it makes the patch so much bigger and more complicated and annoying and all of that has to be tested if that wasn't part of core and make that process a little bit easier. So what do we think would be the result of this if modules actually get removed? So generally they would have to go to Contrib. I don't think any have been outright deleted. Yeah, they'll always go to Contrib. At least if someone has a theoretical path forward or upgrade path. But that means that somebody has to commit to maintaining that thing. And often I think I've seen cases of something getting removed get shot down simply because we can't find anybody who will actually maintain it. So it'll stay in core because like who's going to take over responsibly for this thing and nobody raises their hand so okay it has to stay where it is. Because what we have to do is move it out into a project page, it gets its own repo and somebody has to be a maintainer, somebody's going to have to pay attention to it. Look at the issues, commit updates and bug fixes and things like that. And if nobody does it then it just kind of sits status quo where it is. Why we can't what? Can you clarify why we can't just take a module out of core, put it in Contrib and leave it unmaintained? Well every project has to have a maintainer for one but also there's always going to be people who were using it. So there are whatever the use cases are if we try to do that say during Drupal 8's life cycle someone who was using that module still needs access to it and someone has to be responsible for it because bugs will be found at some point anyway. Unless you are indicating some other point you want to make? Well I'm thinking if it's in core then it has a stable release and if we move it to Contrib it could be unmaintained there but it wouldn't have a stable release so it would be like people would start getting alerts on their sites that something that used to be fine is now like not covered by the security policy because there's no maintainer for it. So it's not just like it's unmaintained, it's like it really or that it's not going to get future development, it's going to like alert people and frighten them and all kinds of things. So to respond to that though, is that the experience we want people to have if they installed Drupal and thought it was a stable core product? If I turned on a module in 8.3 and in 8.4 we decided it was terrible and removed it it seems like that's breaking some promises about backward compatibility within the 8 series also. If it actually is unstable are we just masking it because it's part of core stable release? Don't we have the abandoned modules user that sits around on Drupal.org for abandoned modules? Yeah we do but those models are marked like completely insecure. Technically we could do that but it would have the same problem like everyone who thought they didn't install part of core is not going to get an alert. I was also going to add that you can move something into Contrib and then leave it in the composer so that it's still being required and added into it but it's being brought into the Contrib space so that other people can maintain it, maybe speed up the development of something like the forum module so that people who are interested can add to it. I think you're trying to ruin our finale. I'm sorry. Great suggestion. I also would be careful about putting a module in Contrib and doing something like attaching it to the abandoned maintainer user account because I do still think that if you try to remove something at least within a major release there is still an inherent contract that we've made with people that are using that module that we have to pay attention to and really say well screw you this is not abandoned. We already have the experimental package so we could create a workflow of moving things into an abandoned thing where it's not actually removed but it's basically a deprecated module and let people know that okay on this minor release this is now here but now we're going to be moving it into the Contrib space and still keep it a part of the core composer like we were saying before but I'm still allow for people to be notified that it's being moved out of here. Yeah I think that would essentially be the workflow regardless of what form it actually takes it would be to like deprecate the module at some point although that would be another conversation it's like moving something out is it really deprecated or is it just moved right so like with deprecation there's like there's an implication that something that was replaced or will no longer be functioning and basically going into the trash like with a deprecated API or something like that deprecation is the wrong term for the same philosophy but it's an easy way to actually sort of manage that release like because we can deprecate functions and APIs and things like that we might like tag the modules as deprecated or maybe there's some others tagging some status for that that would be slightly different okay so we compiled kind of a list of going through the maintainers file and just finding everything that currently is listed as not having a maintainer these were recent updates that were made to the maintainers file because we basically went through and looked at everything that was in there and actually contacted people that were listed as the maintainers of these things and were like are you still maintaining this at all or are you interested in it and if not remove you from the maintainers file if you look on Drupal.org there's actually a page now that lists sort of like the emeriti maintainers or things like that so that we can remove people from the file that's actually in Drupal Core but you can see like this is the current state of things and this was the current state of things even when people's names were actually still there so these modules are definitely getting less attention although I think we have a couple in there that's kind of unclear whether or not they're just rubbed into something else like the asset library API I think is probably one of those cases but things like aggregator, the band module, color module tracker probably both core themes, the node module even now has no listed maintainer although that's probably just going to be like well everybody has to maintain it because it's not getting ripped out anytime soon but you know it's something to consider like actually go and ask people whether or not they're interested in continuing to have their name attached to this thing as being responsible for it a lot of people weren't actually doing it and wanted to drop out for whatever reasons can you use my... so this was just a list of modules that are in core right now that do not officially have a maintainer for them does not mean that you're going to cut this module from core we're just making the point of all the things that are listed in core are supposed to have a maintainer someone that's giving them attention and right now these are all the components that are in core that officially do not have anyone listed as giving them attention which we would see as a problem because again you have stuff that's sitting there that will stagnate because no one's giving it attention okay so yeah we sort of took that previous list as a possible starting point and clearly yes a lot of those things are critical you know even if there's nominally not a maintainer there's no way we're going to remove the database drivers or you know the node module or the authentication system you know those are essential to Drupal's function but we you know took a sort of broad swath of you know modules that didn't have mostly didn't have a maintainer or it wasn't clear what their use case was in core and decided we're just going to put this up as kind of a discussion list and sort of you know talk about are any of these things things that people in the room would say yes we should definitely go ahead and remove and then so hopefully this will spark a little conversation and then we'll come back to discussing some you know possible ideas about going forward how it could improve to add one to the list which was the not entirely sure it's still in there but the REST basic auth module that just seems like a security bug to me you would be shocked how many even finance related APIs use basic auth I wouldn't be surprised yeah it's insecure but it's also usually the first thing people try to get their site their REST API working so it's really useful for developers I agree we should have some way to flag it as not suitable for production so another thing that I'm not sure if you looked into or like vendor packages or javascript libraries frontend libraries that may also be on the discussion list I can't name it off the top of my head but have you looked into those things and have you found any that what's the process for doing that and how that will affect users yeah I'm not sure the frontend libraries are sort of a little more of a new frontier I mean clearly we swapped out CK editor so there is a willingness to upgrade those have you looked at how many are reported as being in use we will come to that there's not great numbers on that there is some data that you can look at and see what you think about the data but it's definitely a fuzzy topic and good Daniels here now we can really start to fight so one of the things we wanted to throw on here was just a really rough idea of maintenance burden for these modules and these slides are posted so you don't have to try to copy this year all down the PDFs on the session already but basically what I did was just buy some filters and say okay well let's look at issues that were created in basically the Drupal and currently assigned to Drupal 7, 8 or 9 and they were created since Drupal 8 was opened and their bugs are tasks and their at least normal severity and the statuses were reasonable to suggest that they either were legitimate and were fixed or were legitimate and not yet fixed just again to give us an idea of how much activity basically the core maintainers had to deal with around these different modules this is a totally rough metric but just want to give us some idea how these different modules compare and then let's just dive into this list and one of the things is I'm not sure for a lot of these I didn't even know what they did and so that's partly why I put them on the list and like if I don't have any idea what this module does possibly we should just remove it right and so the actions module provides tasks that's really great right so how many people here think they're using the actions module in on a Drupal 8 site yeah well okay a couple people so I was the same way I was like I don't know what this does I'm not using it and if you enable the module it exposes configuration for actions plugins but there's really no obvious way to use that in core and then as I started asking around I discovered that actually the actions API is used to provide views bulk operations in Drupal 8 core which I didn't even know was a thing so this actually turns out to be really useful but no one knows that it's what it is or what it does but if you go to like the content overview page and there's operations like unpublish these nodes that's actually using this API so does action module provide the plugin API I've always thought that actions are part of core and so that module just provides a little way you could configure some of them and then use them because the VBO thing is part of system module right so that's part of the actions API actions just the UI then like the web page like the forum UI it basically just provides the UI to configure some of these and you know we saw like the maintenance burden it wasn't too high from this either you know we spent some time upgrading it from Drupal 8 but it isn't a big thing so probably this is not a great one to remove from core because we wouldn't actually want to lose that bulk operations functionality what's sort of funny though is rules module uses its entirely owned set of plugins so there's you know I had thought in Drupal 7 I think rules module would use the core actions also and in Drupal 8 that seems no longer to be true so but no one thinks that it's in use aggregator module how many people turn on aggregator module for Drupal 8 site and actually pull in feeds using actions and aggregator modules no that's great so you know there's probably like four or five people in the room using aggregator so but you know is this something that should be in cores or a big use case for aggregating RSS feeds into your site content I'm not sure this was a little surprise this one actually seemed to have the highest maintenance burden the largest number of issues against it since the Drupal 8 cycle started and it may be you know there's a lot of fiddly bits of parsing XML that were in there I'm just thinking if we just get everything out of the core then again we have to have lots of plugins you know installed to the core there's gonna be some you know compatibility issues some conflicts always some modules gonna be in the dev version and you know behind the core versions and it's like then we are ending up our Drupal 8 modules is gonna be like Drupal 7 for Drupal 7 we always to to get something done we use these plugins that plugins and always I always you know face so many services so I was happy that the Drupal 8 comes so many are in the core and you don't need to install so many plugins you know they are also against the performance yeah I think that's definitely an important consideration because with the bundling of core you get a consistency of releases and stability at least a coordination of features and development for those things as opposed to more of a wild west that we get when things are maintained by different people in your slide says maintenance burden 3 could you say a couple of words about that scale yeah that was how many pages of issues I found so it's a very you know rough metric but sort of range from 1 to 3 of the ones I looked at so kind of piggybacking off of what she was talking about with the sort of like mentality that core or that contributes versus the highly structured maintainer structure that we have with core we can do a multiple package core as well yeah that's something that's very common in like on the github side of things where you've got a one big modelistic organization and then smaller packages within that and each one of those packages could have their own developer and those you know those maintainers could be considered like on a core maintainership but in a separate repository a separate package yep good idea we will come back to that history module how many people use history module one maybe two people even know what history module does but yeah so this is I feel like a narrow use case it puts that little red flag next to content you haven't read yet when you're logged in great for Drupal.org does that need to be in core I'm not sure it did have a very low maintenance burden though that one I'd even put it 0.5 because there were very few issues against it it's also a very small module statistics module anyone use statistics wait you're using all these modules well I'm pretty sure the previous module depends on this module if you're using the previous module I think it depends on statistics doesn't it oh maybe that was with Drupal 7 but yeah so yeah I am using both though okay so more or less one person this you know statistics module shows you how often content is viewed basically this is like a built in version of Google analytics and or any other analytics thing that you want to use and why does Drupal need to be doing this itself you know and one of the arguments I would say against this is that basically you have to have a separate front controller and you have to do a actual bootstrap with Drupal and write to the database every time someone views a page even if they're authenticated and everything else is cached so to me you know okay as a checkbox I can understand I'm not even sure as a checkbox this needs to be there because people I don't see why people would use it I was just going to add that Drupal hosting providers blacklist this module and we'll tell you to remove it it's like one of their performance concerns okay there we go great yeah support for that argument okay so this one you know I think you could make a strong case that this should be gone in Drupal 9 does anyone okay agreement band module and people are shaking their head do you even know what band module does yeah use it one time okay anyone else using it no one's using it okay maybe one person using it so again you know most people would put IP addresses in their hd access file if they needed to ban someone really I mean with distributed denial of service attacks and things like that there's not an IP address that's a problem usually it's usually hundreds or thousands and you can't this strategy you know is kind of you know a 2001 strategy and not a 2017 strategy so you know and basically every time you want to ban someone you're still starting through the bootstrap process you're doing a database query you're finding the banned IPs okay then you short circuit the page request but again it's a it's not an efficient way to block someone from your website so not a high maintenance burden but still to me it doesn't seem like there's a great use for this in core I don't know if it's on anyone's checkbox that the CMS can block by IP address maybe very old security checklist and that's one of the things we feel like you know some of these things are basically being maintained because someone's 10 year old security checklist says can block by IP and that's the only reason the ban module is still in core shortcut module how many people create shortcuts sets for their users well that's like a good third of the room at least that's the most so far that's the most so far okay that's interesting to know I have to asterisk that with I have no idea whether my users are using them but we create them can I go back to the ban module for a second so in WordPress and but it's a plugin and what it does that this could be useful for is that if somebody is trying to come in with a username that doesn't exist or too many attempts or a different number of things that you could select as criteria it bans them immediately by IP within the CMS but then it offers you the option of taking that list and throwing it out into htaccess later there's definitely ways to do this and I'm not saying it's not a legitimate functionality just whether it needs to be in core whether it's a common demand that people want it in core I think that one has a pretty good use case for supporting some of those arguments we were making about enhancements to features maybe being able to pull out those IPs and to write them into an htaccess file is a cool thing to do if that's the kind of functionality you need but are the core developers going to spend time on that kind of feature when we're working on other things whereas if that's in contrived and somebody cares about it maybe somebody's actually going to work on that kind of thing oh wait sorry I left my notes there from the meetup where it said we should look at support burden which is why we have support burden numbers so this one actually had some of the higher support burden okay a lot of people are using it they're creating shortcuts that you guys aren't sure that anyone's actually using them to me a lot of these things almost feel like browser bookmarks you know is this again I would argue it's kind of marginal I'd actually like to see it move to contrived but we use it heavily we've got a staff of about two dozen editors that have very cyclical workflows and this allows them to create the workflow quick access to the workflow pieces that they need in a seasonal manner without involving dev without them having to know the menu system so yeah okay so definitely some more support for this one than anything else I also wanted to point out that the maintenance burden of their being more pages of issues could also just go to more people using that particular piece so if more people are using it then they're finding more bugs and they're putting those issues in so these things and we can debate how you would measure accurately either the maintenance burden and again the usage is not really accurate we're at a bit at a lost well so this sporadically left comment in their support burden versus usage graph how do we calculate that how do we determine it it's certainly an outstanding question for all these modules and I think if someone has ideas about how we could do that more accurately it would be helpful to gauge these things over time tracker module does anyone even know what tracker module does now it's a tab on your user profile that shows your most recent posts or on someone else's profile and a couple other things like that again yeah and a lot of SQL queries there wasn't a lot of issues around this being upgraded but why do we have this as a core module on a site like triple.org where there's maybe a lot of community content did anyone else use this on their sites see this as an important feature same one person I don't want to know what you're doing with your website where you're turning on every core module I think this is an important feature for community sites whether it should be in core I don't know I mean tracking activity or providing that to users is important for a bunch of community sites that I've built and maintain because users want that functionality right so I don't think we're saying any of these are bad modules or just should this be in core like is it enough of a use case of the core and you know doesn't seem and don't take me raising my hand as me using most of these modules is like me endorsing these have to be in core because I don't think that at all sure that's fine we're just trying to get a sense of if it's actually used by anyone I just think that sometimes a benefit of a module like this being in core is that and this might be a good example it could probably be much more efficient if the SQL that would normally bring the content and had a join add to it to bring in the rest of the data needed for this joins are really inexpensive as opposed to another query if it's a contributed module you're not likely going to have that happen I know that even though if it's a core module you might not have it happen either but at least there's the option there of somebody looking at core and saying well we can make this more efficient by changing this query yeah I don't I'd have to look at the code I don't think that's actually the case I think it's pretty there's no real assistance for this in the other parts of core to make it more efficient so okay we could maybe cut that one forum module so there's been issue to remove forum module open for four years so this is clearly on people's list of we love it we hate it it could be better we want it but we don't want it how many people use core forum module site we got like four maybe out of the room yeah small small percentage so a few people but again you know this I feel like forum module also missed an opportunity to delete so there were a lot of there's a push to try to convert a lot of the customized code in forum module to something more standard like views and if you look at the code that didn't happen people just did a minimal upgrade and basically walked away and said okay I don't want to invest the time and effort into doing this right and to me that's you know possibly one of the strongest arguments for moving like no one cares enough to do this right when it was upgraded droop late then probably doesn't belong in core anymore and it did you know have a couple pages of issues you know open since droop late started so it is causing some maintenance burden even if people don't didn't really do very much in terms of the upgrade color module I mean this is sort of an interesting one that you know only some themes support color module it's you know not clear that it's really a valuable feature for anyone who's like a professional developer but you know is this important for first time users is it important for the product to have the ability to recolor the theme out of the box to show that Drupal is flexible what do you guys think for me color module is kind of like overlay in Drupal 7 but they forgot to remove it by what they forgot to remove it so I mean color module as a product feature is there because of Bartek right so the ability for that product out of the box for somebody to install and be able to just change the colors around as a first time user decision maker and evaluator trying it out that's really why it's been kept in there it was there for the previous themes and previous releases it's been kept but it's also one of those modules where people just worked on updating it so it works in AAA and just walk away and as somebody who's actually implemented themes with color module I can tell you that everybody hates it and everybody thinks it's a terrible idea and says why the hell is that there can we get rid of it but having used it a couple times I don't actually like using it but I understand the value for it like if you're building a distribution or if you're creating public themes and things like that but there's so many features that it misses and there's so many limitations to how it works and how you can actually use it to override colors in your site that I think if it was just in contrib people would work on those features and make it work 10 times better than it currently does you talked about this idea for decision makers so I'm wondering whether this more belongs into the distribution space because the distribution space controls the entire product much better than it caught us so for example like lightning could provide that and then they also ship other themes so they could actually make it useful yeah I just wanted to say pretty much everything that you just said and I forgot to sit down but it's a I think that this is a very useful feature especially in that core download of people who go in, they start at the site it's just like the example content that Dries was showing on that with like the recipe I would put it in that category of useless to like 99% of people extremely useful to the 1% of the people who actually need it right right so I'm reminded of one of the keynotes a few years ago I think it was Drupalcon Portland the engineer, the designer and the dictator so from the engineer's point of view what are the criteria for something to be in core you know it has to be something flexible that can be used by lots of things and something sort of atomic that can be unit tested and so on and so forth but then the designer worries about the out of the box experience and how are we going to sell this and that's why we're getting sample content in a theme in core and these two points of view are I think really in conflict and so the developer might look at the color module and say well this is a use case that different themes are going to want to use so let's give them an API or a module that they can base it on and the designer is saying oh let's put in some good user interface and blah blah blah to this but I think you do have to keep those two points of view in mind as we go through this discussion with every module I feel that all this discussion is going on around about what Drupal actually is as a product when you install it out of the box but for a lot of us that use Drupal to build sites we never use it out of the box so I would be really happy to see Drupal move to more of a framework like software and completely drop all modules and just use composer require I mean you can handle a distribution using composer require whatever modules you need for every distribution and I won't use a lot of these modules they're confusing when you deliver a website to a client and they say I enable the color module it's not doing anything so I just feel that all of this can be handled better and contrive maybe have some not core maintained but like officially maintained modules that give the support to all the users that actually need it more of a framework like great I think you also just stole part of our conclusion yes small core so part of that is like I started as a hobbyist back in like 2007 2008 and a lot of people did start as a hobbyist and if as a hobbyist if I had to download and install composer which I didn't understand I still don't understand composer and do this do all that stuff it's very very difficult to get people in there and as I see Drupal moving into the enterprise space I see us almost forgetting the hobbyist and I think we can have both you know like all this enterprise stuff like configuration management and symphony and stuff like that that's great but the hobbyist can do that too but whoa like small core and have everything in contrive we need to develop some type of interface where a hobbyist can say like download the themes from within the user interface or I like there's an issue out there that says like during the Drupal install process have some vetted install profiles that will automatically down those and kind of figure out your composer dependencies for you and it will just kind of magically work so say if I have like a restaurant I can select a restaurant distribution or something like that and that would be completely cool yeah that's like distribution level but I remember you also Peter had that idea of like making Drupal.org actually do it yeah I mean there's a different few different ways to approach this I mean one thing we were also discussing is you know do you want essentially like a distribution builder on Drupal.org yeah in some cases you want a distribution in other cases you want to say I want these features please build me a custom distribution and basically record those decisions so I can get the updates going forward on that and have Drupal.org run composer package it you know make it available for the download so someone who's more of a hobbyist avoids needing to understand some of those intricacies out of the gate yeah yeah I think that would be a great idea because downloading and installing Drupal right now and you see that and you're like what is this thank you just a touch up on what he was saying I think the composer module for Drupal 7 had a UI where you could just like update dependencies and it would work and they would not need to use command lines so something could be developed so you know users that are not so technical can still have like a download a module and have the advantages of having a composer enabled side without actually running composer yeah it's tricky though because if you're saying to set up such that works it's not installed securely so so book module this is actually people know what book module does and how many people install it a few some enthusiastically so to me this is actually one of the most overlooked modules in core and I say that as being the listed maintainers and I think it may be that the name alone is one of the reasons why this module is sort of possibly on the hit list yeah so you know I would I think we should basically remove this one from core but replace it with something better and with a better name so book module has a limitation it only handles nodes not other entity types and yeah the name is confusing and if you called it content hierarchy or structured content module or something else like that that actually explained what it did probably a lot of people would like to use it yeah I'm just going to give five thumbs up to that thing we actually talked on IRC about doing exactly that it just needs to be there to allow people to create hierarchical content but book is a terrible name so I was always under the impression that the one of the purposes of like the book module and the forum module was there to more or less test the apis for Drupal core specifically to make sure that these things were you know possible it didn't seem to like the development of eight didn't really seem to go that way where one of the two first things was book and forum and done in it like okay let's just get this code you know into the apis as quickly as possible versus like how can we redo this using Drupal 8's actual functionality so I really think that these things should be in core but you know rebuilds using you know things like views and plugins and all the things that you know core now has versus this sort of strict hard coding that's especially like the book module is full of just strict hard coding I mean I'm the one who did that port and part of the reason it looks that way is because we wanted to decouple it from the menu link hierarchy code which when I which I used I basically in Drupal 6 use the same back end for the book module as the menu link system which was great and we deployed it to Drupal at Oregon it handled you know 10,000 documentation pages that way with no problem and that you know but when we wanted to upgrade the menu system we had to do that basically a hack of you know splitting out that code and no one has found the time or energy to come back to it which is another reason I strongly think we should replace it rather than fixing it. Right and I do want to say that like I am using you know core book you know on Drupal 8's and I really think that the functionality is great you know that ability to do the hierarchy this was you know is really important in certain use cases. I'm just thinking about the maintenance burden for book and thinking about the migration of Drupal.org to Drupal 8 and Drupal 9 and I'm like oh my god well yeah Drupal.org is already they started they changed the documentation system and I'm not sure I love it but it's now using organic groups to provide the content hierarchy as opposed to book which I think lost some important functionality but people like the way it looks better I guess and it allowed them to designate maintainers for separate sections of the documentation which was the key reason they did it that way okay so getting close to the end of our hit list here tour module anyone use tour module people even know what tour module is okay good people know what it is do you know that there's only one tour in Drupal core and anyone know where to find it this is enabled by default in your sites and now Wim is excluded from answering this question and Daniel anyone else know yeah I think it was basically like added when right after tour module was added just to prove that it works and then no one made another one. Yeah I think two models is great in theory we should just leverage it like explain more pages with it and maybe see it as a maybe in addition to help module and all replacement I don't know yeah it's I mean it's really similar to help module and its functionality I guess but it's more user facing than I guess you could use it for the actual users I've heard of a few people writing custom tours for their sites to explain how the site works but yeah I don't feel like this one seems like it's a great idea not underutilized so again maybe does this need to be in core maybe not for Drupal 9 unless we get more tours actually written and take advantage of it and last RDF module people anyone use RDF module? A few? yeah so this was one of the really big features of Drupal 7 and you know I think it provides an important feature but you know it also has some problems and in particular one of the problems I know David has run into was if you enable it on an existing site it changes some of the markup and may basically break your existing theme work which is not really that friendly to people I mean that's not a reason to remove it but it's a caveat and the other thing I found is that is no longer really the recommended format for enhancing your search results so other engines like Google will use RDFA data to enhance the search results on their page because they get more information about what the data means but it's like the last option they recommend and they would rather have you using JSON-LD to describe the content on the page in a machine readable way so you know what's the future for this should we still be have this in Drupal 9 should we switch to JSON-LD anyone have opinions on this because this is again I think it's really important to get good search results for your site but I don't know if this is the right approach anymore I think it's something that should be definitely removed from core on the basis of it no longer being a best practice and not wanting to in core promote use of technologies that aren't best practice I don't think that necessarily an RDF implementation should stay in core but possibly a more generic API that allows for markup extensibility outside of core so to have contrived plugins that can then modify the markup in ways so that it's more future proof much more like the way that the layout engine for the experiments in Drupal 8 is there so that modules like like display suites and panels can have a back ends that's running their stuff without having to re-implement like half of core so doing something along those lines that provides that core API for contrived implements I think would be a better approach I think we need to keep that I don't know if anybody is familiar with schema.org or not so schema.org is using the RDF and it's highly recommended for the search engine optimization so I'm using since Drupal 7 the schema.org and RDF module and it's still in our for Drupal 8 site we're using that yeah I mean it works well and the search engines so use it and the schema.org is very interesting because it gives you a lot of ways to describe the data so you know I'm people are not using that because maybe they are not familiar with schema.org but it's if they're familiar they would say we keep it okay and someone asked earlier about usage if you go to this page on Drupal.org people recently tried to parse basically the update status callbacks and get some sense of how many people had enabled non-default modules in core and so there's some data there but you need to take that data with a big grain of salt and I'm not sure we want to base decisions on it because that data also includes callbacks from the test bots that are running tests on these modules so it's been suggested to me that the usage numbers for some of these lower range modules might reflect their test coverage completeness and then their actual usage in real life so basically we don't have good numbers either really a good sense of what the maintenance burden of these things is or how many people are really using them how many people need them out of the box in Drupal core. We should have the numbers of the amount of test bots that are being run so we should be able to figure out what the actual noise floor is and then cut that off so that we can... Yeah, in theory with enough effort we could... Actually you should have the test bots hard-code decided That would be easier, yeah Okay, so we've heard people suggest things like maybe we can split out these modules and then recompose the site or cut Drupal down to a framework I think a lot of people have come to the same conclusion about the core kind of thing I wrote a blog post about this that I put out last week discussing sort of pros and cons of small core in different ways to handle that and some other people have written some recent blog posts about it as well but this is a discussion we've had for a really long time small core is not a new thing people have wanted that for a long time and those advocates have never won out for a really important reason to be here where it's people who are more interested in Drupal as the framework and people who are more interested in Drupal as the product and the product has always won and it's won for a very good reason because Drupal needs to be something that people can download and use, as many people have already said here you started out as site builders, as newbies and if you had started with Drupal just being a framework and you downloaded it and you got a bunch of PHP code and you essentially have to do all the work to build it yourself from scratch that's something that really only a developer is looking for that's not something that someone's looking to just download and use and just click buttons and turn on features on and use them out of the box so the product has always won that discussion but I don't think that we need to leave it there I was thinking of different ways that we might be able to do both and so we're discussing more and more now things about using distributions and stuff like that so one of the ideas I had is well maybe we can do both so if you look at my blog post you'll see more details about what I was writing about but the idea I had was essentially can we get back to small core and have something that's really focused on just the APIs and let the developers who want to just work on those APIs work on that and iterate and innovate on those things and take all the modules and the themes and everything else put them into contrived but don't abandon them in contrived put them into contrived in a state that's essentially still maintained by the core development team so each module maintainer becomes that module maintainer in contrived and the core team has maintainer access to those modules and is still maintaining them the same way they probably would on the same schedule with core but have them separated so the module maintainers can innovate on them, add new features do different things that they want to do and then because we've got these new composer workflows now we could do something like build a distribution but I wouldn't just let anybody build a distribution we should have an official Drupal core distribution that is maintained by core development team so that we could essentially go to Drupal.org slash project slash Drupal get that page that everybody goes to and you can have a button that says download Drupal 8 and you can have a button that says download Drupal 8 core and core would just give you those APIs and the things that you need and then the download button for just Drupal 8 would essentially be a pre-packaged distribution that has the standard install profile the way it does now and Drupal.org which is packaging I think if we did something like that both sides would get what they want the site builders can still have what they want the product team gets what they want the people who care about small core and APIs get what they want and I think it frees up both sides to be more innovative because one of the things that I think is really a problem now is because the sort of like framework people maintain everything it's harder to actually get innovation on the product level so when product people are making decisions like UX decisions and modules we need to add and features and like why is Betatag and Path Auto not in core and things like that if that was being done in a distribution the product team has freer will to do the things that they want to do that makes sense so things like the out of box initiative that's being worked on with default content and a new theme and stuff like that the core API doesn't have to care about any of that because it will never be part of that download that will just be something that gets added to the distribution and is there to demo features and content for people who want that so if you just download core you don't even get that software because I've already heard complaints from people like you're now adding another thing it's going to have all of these files and all of this code and is that default content going to come with images and now that's going to be like in my build process having all this garbage that's in there and if we keep adding more and more and stuff that download that installation just gets bigger and bigger for things that maybe 90% of people don't even need that are there just for demos and stuff like that and I think the other advantage is if we can get to a small core that's actually accessible to people it opens up a lot more possibilities and interest for people building distributions that are particular to things like a community or publishing or things like that and those people who are maintaining those distributions can focus on just adding the things they want to build a Drupal product the way they want and not will I have to like try to figure out ways to get rid of all this stuff in core and modify and override stuff I don't need right like so imagine being able to just download a core and it doesn't have the themes in it right and you decide I don't need classing I don't need Bartek and I don't need 7 because I'm going to use Adminimal as the admin theme for this and I have a better version you know in contrib there's a better version of the toolbar module and a better version of the shortcut module and we can use those and package those as a distribution and those other things don't even show up there so we can see more of this landscape of like flavors of Drupal that people are building out and even have their own different frameworks in them and then see which things are working better and then maybe we start going that direction in the official distribution when something works on something and they find something better and then when things like path auto becomes stable in the distribution that can just be added to the composer file that just immediately starts getting pulled in you don't have to worry about how that gets added into core it just becomes part of the distribution and part of the product I just want to say we're running out of time so just a quick note there are sprints so come on Friday please evaluate this session this is node 1, 7, 5, 7, 3 so please give us feedback and we can continue talking for a couple more minutes but just wanted to respect people's time so as of last week or something we actually exposed the components we provided as like a packages package I wonder whether we could actually expose every core module as a package we would need to do that or want to do that to start experimenting with this I think that would solve a lot of this distribution or a small core thing actually that model would still retain everything but at least you could remove all the other things the other question I have is how does that removing of features work together with the stuff Dewey was talking about which is like the continuous upgrade path from DA to D9 and you can just do things because you are removing features you can't provide like an update path some smooth transition for that I mean well if those things are moved to contrib as the first step and are still only maintained by the same group of people you would essentially be moving its location you might still be able to have a minimal upgrade path at least for a time but at some point you would have to figure out like an alternate solution those are doubles in the detail and that kind of implementation I just wanted to say that unless I am mistaken I have heard Dries say everything you just said back in Denver at a core conversation so the big difference between now and then is that now with Composer we can do that without you know and still have the versions and semantic versioning and all that stuff all of the groundwork has been laid now so this is actually much more of a possibility now than it was then so I think this is a great idea moving forward Thanks everyone for your comments and thanks for coming there are 992,000 all of these so like you were in the prior I'm excited when you mentioned that how do you like it's it's it's a yeah there just becomes a it sounds like it's always like it's always like you have a storage model you have the way it has download that I mean if you if you did your own composer workflow you would essentially just have your first dependency in there whatever that core distribution is is and then you're on the page yourself. But then it's like you literally have to do some research and then you're in the class. But it's like you already have to do all the research. And then you're like, yeah, you can't do anything. But like definitely, I would do the stuff. I was actually going to ask if you can come up with any fun stuff. I always start with the math. It's amazing. It's big issues cases like the testing framework and stuff. Well actually, I'm going to try and do something. I'll copy the paper. Thanks guys. Well, right you run a manual or use a plugin. But you can expect it always differently. It's all situational. Okay. I was in a district just like now. I was like, who could I be? It's a family thing to make. But I didn't use any of those. That thing, I don't know if I really need to use that. Actually this one is actually possibly reusable for my husband and he can do it. But again, I don't know if I'm actually If I needed to, like, if I need to try anything, I'd probably need to do a quick strike. I should have, like, one or something else. Well, I don't think so.