 All right, so this is the core Q&A session, which is very casual, as you may, if you've been to these before. It's an opportunity to ask us questions about anything that's on your mind, so relative to Drupal core. Before we get started, maybe we can go do quick intros, so you know who the different people are here on stage. Maybe Gabor, let's start with Gabor and then go this way. Sure, so I'm the Drupal 6 maintainer. I committed three patches to Drupal 8, I think, in the past few years. I work as a lead of the multilingual initiative and also do a little bit of Drupal 8 marketing, so I ignited the Drupal 8 page on Drupal.org, for example. I'm the final catchball, catch on Drupal.org. Work for a technical consultant on the Drupal 8 launch maintainer. Hi, I'm Alex Pot, Alex Pot on Twitter. I work for Chapter 3. I'm a Drupal 8 maintainer and I'm also the maintainer of the configuration management system, yeah, sorry. If you shouldn't mind my chat, I'm a freelancer and I'm the maintainer of the field API. I'm Moe Meleers, I'm working at Aquia, worked on Spark and things within Spark and now working on Drupal 8 performance. It's funny you say Leers. Yeah. English, if I, your name. Because otherwise people can't pronounce it. What is your name actually? Leers, Leers, Wim Leers, or Wim Leers. So I'm Jess, I'm extra, I'm on Drupal.org. I worked on the views in Drupal core initiative, the core contribution mentoring program and I now also work at Aquia doing a lot of, my title is Code and Community Strategist. I do a lot of sort of release management, code review and so forth with the goal of getting Drupal 8 released. My name is Dries. So just to get it going here, as you may remember from my keynote, I solicited feedback from everybody in the community asking me questions about anything they want really and some of these questions I didn't actually get to in the keynote but I related to Drupal 8 core. So to kick it off I'm gonna ask our panel here a few of those questions because I think they're relevant not just to me but to ask from, you know, to them as well. And then after that we'll flip it around and obviously you guys can go to the mic and ask, you know, whatever question you want. So let's start with the first question. And so that question was, is there any lessons learned from the Drupal 8 release cycle so far? And obviously we're not done yet but we are three years or more into it and there may be some lessons learned here. So I don't know if anyone on the panel wants to jump in here. All right, I'll start. For me, one of the top lessons that I've learned during the Drupal 8 cycle is don't quit your job until Dries because then you might end up working all your time on core. But more seriously it's the fact that changing core is taking longer and longer. And that's because we're trying to do more, we're trying to build a more full-featured Drupal that serves the needs of all of our users and developers. So core is professionalizing and it's taking longer and we've got to change our community to react to that because we can't just rely on the intrinsic motivations of developers to contribute back because just putting a patch on Drupal.org isn't enough anymore. We've got to take it through, we've got to make sure it's well tested, we've got to make sure it fits in with the rest of the designs for the system. And there's a lot more work than just having a good idea and putting it up on Drupal.org. And so how are we going to help that happen in the future is one of the key challenges that going forward, we're going to need to change for me. Awesome, any others? It's probably kind of connected for me. I guess it would have been the importance of building a team around subsystems. Like it's very, very hard to maintain and to grow a subsystem. Like if there is only one or two developers like working on it in the long run, one of the differences between the D7 cycle and the D8 cycle was that like in the D7 cycle when the initial, after the initial field API patch got committed, there was basically two developers polishing it. Me and Barry Jaspen back then, then it was like mostly me for the end of the cycle and it was like kind of really hard because, well, if you write a patch, who will understand and review it? And the big difference in the D8 cycle is that like we have been like six, has been six or five or seven people like being able to work on the entity field component and that makes like a big difference because, well, you can work as a team. You can, when someone leaves, the other can move forward too and reviewing each other's works and moving together in the same direction makes things immensely easier. But like having five or six people stick around for the current duration of a Drupal development cycle like two or three years, it's kind of, yeah, how do we do that? Gabor has some thoughts. Yeah, so continuing that thought of these two thoughts, what I think we found in Drupal 8 that we didn't do before is that we need to communicate what we do better with the rest of the community interested in what's going on. So we started these Q&As, we started this week and then this month in Drupal Core and we started putting out information about what's coming up so that people know what's going on and where can they help and that helped involving more people and pointing out what are our priorities and what we need help with. And I think we've been improved on that a lot in this cycle. Yeah, and I'll tag on to that as well. Like people ask me whether I think the notion of initiatives worked because that's something that we introduced in the Drupal 8 cycle, didn't exist before Drupal 8. And so my reaction to that is that it did work. Like I think it really helped on a number of fronts like communicating sort of a roadmap for Drupal even though it's not like a roadmap that most people know it did communicate sort of the key areas of work. Whether it's mobile and Spark and CMI and all of the other initiatives that we had. And I do think it aligns people or rallied people into contributing to these buckets of work if you will. But where we also can learn from Drupal 8 is that I think the initiatives that have been successful are the ones where there was a leader that can rally the troops and provide that level of communication. And the initiatives that haven't been that successful we were sometimes missing that component. That doesn't mean that the person that was heading up the initiative isn't a great person. It just meant that we need to think about how can we make sure that sort of the initiative leadership is well rounded. So that we have technical strength but also people that are good at communicating and people that are good at project managing and all of these check boxes need to be checked. For me if we decide to do the initiatives again I would try and think hard about how to be a recruit maybe not one person but a small team of people that can sort of run with these initiatives. Because it's a lot to ask from one person often. All right maybe we should move on to the second question. Unless other people, all right. So the second question is what some of the things you would like to that you would like to see changed personally in Drupal 8. Sorry, hold on. All right, I'm gonna jump to the third question. Sorry. So a lot of people asking about how do you, how do you best prepare for Drupal 8? Like, you know, we're talking about Drupal 8. How do you prepare your site? How do you prepare your skill set maybe? And so any suggestions or thoughts from the core team here? So if you're doing site building you should consider at this point like exploratory site building which you play not just testing but if you're prepared to drop all of your data and rebuild your site again you can build sites that way and just react to API changes until there's an upgrade path. I think a lot of people are like, when can I start using it? Or they ask when it's gonna be out and when it's gonna be like a release candidate. And what they mean is when can I start using it? And you can start using it now if you're competent and if you're prepared to kind of very honestly confront the extra work that you'll need to do. So I'd encourage people to start looking at that like do it carefully and be aware of the risks and the fact that we will break your data but if you can just install it each time then it will run fine. Anyone else? I think it would indeed be very valuable if site builders start testing now especially if you can try to do those things that you very typically very often do in Drupal 7 today because maybe some things work much better maybe some things work a little bit in an unexpected way. But now is still time to report those things because maybe we can still address those things or take them into account. A particular variant of this is if you have a Drupal 6 site that you're looking at according to our new release cycle and end of life probably six months after the release of 8.0.0 I would highly recommend that you try to build out your Drupal 6 site in Drupal 8 see what functionality you have see what functionality you need to wait for to contribute for because a lot of functionality that was reliant on contributing modules is now available from Drupal Core. So try to build out your Drupal 6 site as much as you can and then test the migration path that's actually available in Drupal Core now. It doesn't have a user interface yet and it's not completely supported yet but it's mostly there. So what you can do is you can use for example Drush to migrate your content from your existing Drupal 6 site which can stay in production and keep running right up until whenever you actually do develop in Drupal 8 just test migrating that into a new Drupal 8 site that you've prototyped and see how far you can get and see what's missing. That's a really great way to plan resources and say okay this thing that we did in Drupal 6 we can do it in this different way but we really need something like this contributed module in Drupal 8 and so maybe we're going to look into we're going to follow the development of that module we're going to try to support or participate in the development of that module that's what I would recommend. Any other thoughts? By the way before Alex starts to answer like maybe after this answer we're going to start taking questions from the audience so if you guys have questions feel free to start lining up at the mic and then we'll switch over. And obviously there's just a few really obvious things if you're a PHP developer it's time to start thinking about object orientation if you visit there's a site called PHP the right way we follow a lot of the same common practices that are outlined there. If you're a Thema it's time to be thinking about twig and having a look at how that works there's a big change that's going to happen on the theme layer called the consensus banana series of patches if you want to check that out and see what's going on there. Just a minute, one of them actually two minutes ago. So is Classy's in core? So yeah we have a new base team in core called Classy so if... Did I miss something? I just committed it from here. While Gabba was entering I just committed it. But I did commit it just before I took the mic so. So if you're a Thema there's a whole new way of thinking about how you base your theme. If you don't want any of Core's HTML or Classy's then you just don't base your theme on Classy. So you can have that clean dream markup you've always been looking for. Not yet. Well, in the future. So basically we'll get the classes and then when we remove the classes they might be there. But if you do this and you see the classes it's because they've had to have it all come together. You can start not using Classy now but please don't be disappointed when you still see lots of classes because they haven't actually been removed yet but they will by the time you get there so just pretend that they're not there. The theme layer isn't going to be frozen until closer to the first release candidate so. And one more group that I think is quite interesting from the DA perspective is the content strategist. We've now got a full featured entity API in Core which means that when you're modeling your sites just think in terms of entities and your developers and themas will be able to take that and model that without going, oh should this be a node or not? Everything is an entity. And then when it's an entity you're gonna get a whole load of good stuff that I was really about to tell you about. No I wanted to actually point out developer things. So there's some great speakers doing talks around how to use tools that you will use in Drupal 8 in your Drupal 7 projects. So you are to do Drupal 7 projects. It's totally possible to integrate composer, a PHP unit, a lot of other tools and you can get to learn them one by one instead of the whole thing at once and then apply that knowledge to Drupal 8 if you want. I personally know that FGM, Frederick Moran has a talk on that. I'm not sure if she did that talk here but it's certainly recorded and available on the internet how to use some of the Drupal 8 tools on Drupal 7. Also if you're a contributed module author or if there's a contributed module that you depend on for your site and you're not the author you should come to our module upgrade lab this afternoon which will help you port either your very own module or a module that you care about to Drupal 8 we'll show you some tools that are available to do that. This is a really great strategy if you're worried about some contrib after Drupal 8.0.0 is released is to start that we have a beta now so now is a good time to start porting it. You shouldn't expect though that you can port it once and walk away. You will need to update your port again at some points probably before a release candidate but now is the good time to start that. We'll show you some tools and the more contrib we can get done by the time 8.0.0 ships the more the earlier that new sites will be able to build on Drupal 8.0 using all of the stuff that was available for you in Drupal 7.0. So that's this afternoon at 1.0 p.m. Awesome. Just one tiny tidbit to take onto that. So developers indeed porting your module or modules you care about or that you depend on heavily porting those is very useful and I think the best way to start learning to do APIs because instead of being overwhelmed by the many things that are new that have changed you can begin in those areas that you are already familiar with and then you can build upon that. So starting with the things you already know learning about those changes makes it easier to then learn the rest as well I think. Great, thank you very much. So at this point I'd like to see if there's any questions from people in the room here because if you have a question feel free to best to ask it in the mics everybody can hear it and so it's also recorded. And please introduce yourself real quick. That's always helpful. Okay, my name is Christian. I'm from Berlin, the company mostly does or my company does mostly does medium sized e-government projects. I have a somewhat less serious question and a somewhat more serious question. The less serious one is the one I actually asked the exact same panel last year in Prague. If you were supposed to bet money on the release date. Last year you kind of skipped that question. Maybe this year. My answer was so good. So you stuck with that? I don't remember your answer. I'll let other people. So the crickets again? I'll keep it again so maybe other people don't remember. Maybe give us your serious question and we can think a little bit about that question as we move on. Well there's a somewhat more serious question is that this is really low. Right now very often we would use features or I would use features to, I don't know, export some view, export some content type, something like that. And more often than not us or the client would see something that he wants to change and so I would simply jump in and use a little hook to change a little thing. So usually the module files will not be very long, like five or six, seven hooks and that's it. So maybe it's like less than a thousand months of code. What I've seen now with symphony seems really intimidating to me and it seems like, oh my God, I want to change something small and I will have to go through some really crazy stuff to actually do that. Would you, what would you think about that fear that's being intimidated? Will I still be able to simply jump in? Yesterday somebody, I can't remember who but was kind of prospecting a future where there will be no more modules and will just be PHP components and a symphony and it seemed really scary. So a lot of little small tweaks that you would do in like a 200 line module were things like hook form order or hook entity view order or something like that and those have fundamentally not changed compared to Drupal 7. You can still go in and you can change small things in a form and you can still go in and you can change views and feel for or add a new field format and stuff like that and like it might be like instead of like instead of adding a new format and it's in a hook, you add it in a plugin but those plugins are much easier to write once you've done one. So for those kinds of small tweaks I, depending on what the tweak is some of them, you won't even see that much difference but some of them will make a lot more sense. For some of the small tweaks that are actually really, really complicated and relied on side effects and things like that which like doing weird things in a hook in it some of that is gonna be much harder but those are usually things that people shouldn't have been doing or only doing because there was the only way to do things. So it's gonna be a bit of both but it's not like suddenly you have to go in and like write six classes you don't you can still do little orders in hooks and you can also like quite simple plugins and switch things to use them and everything's in that one file. So it depends on what you wanna do but I wouldn't, don't panic. And will it probably stay like that for the foresee future or is there, will you kind of abandon the whole hook? No, no, no, no, no, not in Drupal 8. I don't, in Drupal 9 there are inconsistencies in the way that you do certain things in Drupal 8 that we need to resolve but they're not gonna be resolved before Drupal 8 releases. So when you do do certain things it will be more complicated and you have to write event list and that's something we're gonna have to sort out for the next one. But replacing the whole system is not gonna happen before release. Like if you write a hook implementation now it's still gonna work unless you're a bit unlucky and we take it that particular one away. Okay. It's kind of a requirement. Well, in the issues I've been involved with like we've been very careful about not removing any integration point, extension point, like hooks, like because that's what we do in Drupal. I mean we do things and we always with the thought in mind that yeah, but some people will want something different slightly different or completely different. So like any time there was a major or semi-major refactoring, like one of the question requirements was we had those extension points earlier. How do we preserve them? Or how do we leave them in place or find a new shape for them? Or maybe make them easier? So like we definitely try to keep those extension points in place. And one of the efforts was like making it easier to just swap out like big implementations like make it easier to have a completely different entity storage or make it easier to like to swap out entire parts of the system. That's very much what the service container and object orientation it was about. So if anything, you should be able to swap out much more things than in the seven. That might not be always easy to do or easy to find how to do it. But like I think the hooks that were in place in the seven are mostly still there in one way or the other. So here's a personal testimonial. So I've been very freaked out of the complexity of some of those Drupal 8 things. And I told Dries that Drupal 8 is on the wrong way. And he was like, yeah, well, so he's like taking this input and then thinks about it. And then sometime later on, I was paid to work on Drupal Core modules to work on things as part of Spark. And then as part of my free time, I was working on Drupal 8 modules for multilingual and I built a Drupal 8 distro for multilingual. So I used a lot of those things. And what I found is that there are very clear patterns that repeat. So they are not the same patterns that there were in seven, but they are patterns. So once you learn some of those patterns, you can apply them across a lot of things. So they are just different patterns. There's no reason to be afraid. So I totally came around to this now. So from my point of view, I mean, a lot of things changed. And because we switched to object oriented programming and design patterns, the code is more verbose. And it looks like, wow, there's so much code, but there is not necessarily a direct correlation between the number of lines of code and complexity. I think that's very important because I can give you, say, an academic white paper that is 12 pages, which will take you two or three weeks to fully understand. So I can give you more of a book that is easy to read and you can read very fast through it. So I think a lot of people assume that more lines of code means it's more complex, but object oriented as a whole, not just in Drupal is more lines of code, but it also translates to more component based architectures and easier to maintain if it's well architected and designed. So I think it's easy for people to get afraid, I guess. But hopefully time will prove and show that a number of things actually get easier, even though it's more modules or more files and more lines of code. And just to add another anecdote to that, Jennifer Hochten is updating her Drupal 7 book to Drupal 8. And she's the type of developer who has voiced exactly the same concerns as you when she started the process of updating her book. She's like, everything's more complex. How am I gonna get scripts for this? But what she's found as through writing the book is that actually, we're more consistent. Things that were info hooks are now all plugins and once you get used to the plugin system, it's like, wow, this thing that was just completely different before is now looking the same. I know how to do it. I got all the logic in one place and maintaining the book for her and maintaining all the code in the book that she's written and she's written tests for it all and she's like, wow, this is better. And she's been pleasantly surprised. The other thing I'll quickly add, sorry, is that in Drupal 7 and before, we were very much like we would use hooks, right? And so what's the words? It was by convention. Like a lot of things were by convention. And so you have to know the hooks and if you implement the hook, your function will be called and in Drupal 8, we use more declarative constructs or you actually specifically have to say, I want this to happen, which is more code, but it's also helpful because it's less magical in a way. And so that is a little bit of a mind shift that we made from seven to eight. But in many cases, I think it's actually very useful. I think Drupal 8 in general is more strict and because it is more strict, there is more of a capacity, but the strictness also helps you find problems. Much easier than in Drupal 7 or before because there is less dark magic, less unstructured arrays of things and that is going to be tremendously helpful and it's already helping a lot in finding subtle errors because the subtle errors pop up immediately. Whereas in Drupal 7, it was such a pain to find them. And she said it well actually in a presentation. This week she said Drupal 7 has an array PI. Which we've actually made a proper API instead of an array PI. So is there, yeah, do you have another question? No, thank you, first of all. Maybe that answers your question. Thank you. So this first question was any bets on release date? I don't know, I'm not ready to answer that personally, but maybe anyone else wants to take a crack at it. So I will repeat like a qualified version of what I said in Prague, which is that, well, but I will add that in a way I am and a lot of us are betting money on Drupal 8's release date. Being successful and soon, it's my full-time job. It's a couple other people up here, it's a full-time job also. And we as an ecosystem, we are betting money on it, right? We're betting money on it every day. So I don't need to bet $10,000 that someone gives me and gamble with it. I'm already making a strategic investment, is maybe a better way of phrasing it. But the thing that I didn't want to do then and is not as scary now, but I still don't think that it's not good to, for someone up here who's worked on Drupal 8 a lot to throw out a date, and then a company overhears that and makes business decisions based on that date, and then it turns out to be wrong because the amount of work is different. That's not smart. It's not good for business. What businesses probably want to know is I think more what Nat was saying earlier, which is when should I start thinking about my 2015, 2016 projects being in Drupal 8? And if you have a long, if you have a project that has a long timeframe, one of these multi-year projects that's gonna require a lot of pre-architecture, think about doing it in Drupal 8. If you have the resources and the scale to do investigative category development now, as to when it's actually going to be released, let's answer the how and when it will be released. So right now we've just released the first beta release of Drupal 8. There are going to be numerous additional beta releases as we add in support for an upgrade path, as we resolve outstanding critical issues as we, the forward port, a number of security fixes from Drupal 7 to Drupal 8 so that people who are running betas don't have publicly disclosed vulnerabilities on their sites. There are 100, something like 115, 116 critical bugs outstanding and all of those bugs need to be resolved before we can release Drupal 8. We fix something like 10 critical bugs a week a lot of the time but we also discover additional ones in that process. So it's a constant narrowing of the funnel. It's not like we're, we introduce some regressions but a lot of it is more just uncovering smaller related parts of the previous big problem that we had defining what the scope of work to be done is better. If you want to keep track of that you can go to groups.drupal.org slash core slash updates every two or three weeks we put out something that gives you sort of like a weekly tracker of how that progress is going. So if you have a gambling type and you want to start betting on it, I'm not going to make a statement but go ahead and follow that and then maybe you can make a prediction. All right let's take another question. Oh hi, I'm Chris Amano from Nectar we're a web development firm in Massachusetts. We mostly do, we do a lot of partnering with agencies, design firms, ad firms. And my question about D8. My role in the company is largely often defining the sort of broad architectural parameters of a CMS. So it's sort of content strategy but a little more than that too. And so my question is as far as it relates to D8 how will D8 impact our agency partners or end customers, direct clients from an architecture standpoint if at all? Should it be, should clients care aside from the fact that they're gonna have to pay more money to upgrade and to stay secure in the long term from a site architecture and visioning perspective does D8 matter to clients? Well I think it makes a lot of things easier. Like we put a lot of emphasis, I mean I'll take your first crack at the answer. Sorry. You know some of the initiatives are not mobile for example and so out of the box we have responsive design for both the front end and the back end. We have web services deeply integrated into the platform. These kinds of things are very relevant I believe for the agencies that increasingly more need to build these great mobile experiences in addition to traditional or more traditional desktop experiences. Can I meet a little more specifics? Yes please. Conventionally we think in terms of content types and views as interpreters of Drupal for clients that just wanna see their content in various places. Does that dialogue change much? Like is there a shift that we should, cause there's a little bit of client education that goes into every Drupal build project and we have to do a little bit of, here's what a content type is, it's you know, everybody has their way of describing that to non-technical folks. Does that change and how? So there's been a lot of changes under the hood to these systems but conceptually the concepts are the same. Drupal is still very much Drupal. I mean we have entities, we have fields on entities. We have made the thing better and like the things that worked on some part of the system but not on the other part of the system are like much more unified. Like every entity type can be natively translatable. That's a huge change. Every entity type can be natively revisionable. Every fields in the entities are manipulated the same way with the same set of tools like widgets for matters, validators, stuff like that. So the system should be, it's still very much Drupal with the same concepts you know from Drupal 7. More unified. Great. Yeah, what we get to entities and views is you have more of them. Also fields, a lot more of them. So we think those are the key strength of Drupal and we wanted to apply it even more broadly. So custom blocks, menu items, all those things are entities, even admin pages are views. So you can customize admin pages for clients without needing to replace your existing admin page just so you can use views. So it's a lot more flexible in all of those areas and because Drupal already has all these flexibility built in, then a lot of the modules that you will use will build on this flexibility and will be themselves more flexible so you don't need to do a lot of magic to work around them. Great, thank you guys. Just one more thing, it's, as I was saying when we were talking about one of the key things that for different people Drupal offers is that not everything needs to be a content type anymore. We need to kind of branch our thinking out and think about entity types and if it's not content, if it doesn't have to have its own unique URL that you go to, it's a lot easier to do that. We have in call, we have the block content module where you can put different bits of content in blocks and put that around, that's not a node. That's a different type of content entity that doesn't have a URL in the same way that obviously a node does. So it's about trying to draw back from making everything a content type into saying actually what are the things that my site has, which ones of these would map nicely into the node entity and which ones don't and if they don't then it's worthwhile exploring where do they fit. That's kind of getting to the essence of my question which is do we want to steer the conversation away from the term content type in architecting site, summer content strategy perspective. Yeah, yeah. Because not everything is content. Right, right, cool. Yeah, go for it. So I work for a subcontractor of a government project in Norway which does digital learning and we have been happily living on D6 for a long time and we're really happy about seeing what happens to D8 really and thank you for that. But we are moving everything out on the cloud and doing most stuff restful. So I attended the headless Drupal buff yesterday and what we wonder of course is D9. What are or are there any plans for decoupling actually the backend and the good stuff and getting APIs to getting the core stuff exposed and doing headless stuff, that's my question. Yeah, so we haven't really talked about D9 to be honest but I will say that it would make a lot of sense for us to focus more on decoupling and more decoupled architecture. So I would say it's very likely that that will be an ongoing goal and maybe even for 8.1 and minor releases in the 8th cycle because that's where things almost have to go, right? So and we've taken a lot of steps in Drupal 8th to get much, much closer to that already. So I think you can expect to see more along that path. In D8? In D8? It's actually huge architectural change, really. I understood it, the theme layer is really closely knitted so you won't get all the stuff like forms and whatever country it does. Some of these things may have to happen in Contribute Modules, in 8, I think. We're having a great time. But we are already at the point that the theme layer does not have to be initialized to respond to a rest request, right? So we have moved already in decoupling our bootstrap from the theme layer. This is John Albin. Yeah, I just wanted to say that exactly what Alex Pott said. But in addition to that, we're already, just yesterday I saw somebody, Rupal, had created a super lightweight component library API, which is for adding web components, having Drupal being able to populate those web components and then that certainly helps with decoupling the front end and the back end. So there's definitely a lot of work already happening at this Drupalcon 4 in the Contribute Space for that. And it would make sense to move some of these things over to core, you know, whenever we were in Drupal 8.1, maybe 9, we'll have to figure that out. More questions? Yes, hello, I'm Nuls van de Malen from Gogorilla. We make the Greenpeace Greenwire website, a social platform for Greenpeace. I have a question about the documentation of Drupal 8, mostly. Will there be a priority and something like a cookbook or a book with examples that makes all the stuff a little bit easier to read and to learn? Or where can I find it if it's already there? So on Drupal.org, there's already a Drupal 8 API section that has some of the APIs pretty well fleshed out. So for example, all the YAML-based things, if you need to do routing or menus, type tabs, sections, whatever, that's very well fleshed out. The Entities section is also pretty well detailed with concrete examples of what you would do in certain cases. There's other areas where we just made so many changes that we still need to get there. And then, Alex already mentioned Jennifer Hodgson's already writing her book for Drupal 8 development. So there's already those in the pipeline. I don't know when it's related to release, but not next week, certainly, because we'll still change a few things. So they will not put that imprint yet. I think you can expect there to be a variety of books on Drupal 8. Maybe not under the day, Drupal 8 is released, but shortly after, I think, you'll start to see books coming out. I think for Drupal 7, there must be at least 50 books or something by now. I don't see any reason why we wouldn't see that with Drupal 8. Yeah, but I think it could be a little bit better to have it also on the homepage and just, you know, available and visible. Absolutely agree that we need to have Drupal 8 documentation available, easily discoverable. The Drupal 8.0 page is actually linked directly off of the front page of Drupal.org, and from there, you can get to this API documentation that Gabor describes. However, as he said, some parts of it are dumb, some parts that are very stale or refer to like 2012 versions of the API. If anyone, we need help with documentation. We need people who will look and maybe ask a few questions of developers who know things about documentation and then turn around and help flesh out and finish that documentation. That's something that we need. I'm hoping there's, I think that there's a spring going on on Friday where people would be working on documentation for Drupal 8. The best thing to do is look for something that's wrong. I know in the configuration system, we need a lot of help. There's some great features of the configuration API that are very important to people who are thinking about how they're going to develop and deploy the configuration that really aren't documented in a comprehensive way yet, and we could definitely use help with that. All right, thank you. Thank you. Next question. For me, it's a bit high. My name is Rene Van As. I'm from Le Moon Hoon, a station here in Amsterdam, a Drupal agency. I asked a question just Tuesday at the Q&A at your cloud funding. I'm still here as well, that keeping the team together and keeping the velocity going is a big problem. So I had a follow-up question for you. So I don't know if it's really for core, but we all have to. It's relevant to many of us, really. You talked about tracking agencies and end users and contributors in maybe with an idea. With that tracking in place, I'll read it because, what tracking in place with current entities within the Drupal community within the Drupal, currently can be assigned to start working on the scalable funding system that supports the event. Well, this isn't going to work. I'm just talking about how come, can you work within the community? Can you find a responsible for starting an initiative to get funding off the ground? Like the initiatives you talked about, technical within Drupal, I think there should be initiative for funding and how to set a fund, how to create an organization to enable us as a developer to apply for funding. Do you have an idea about that? I want to use large-scale trouble which combines businesses, but that's the thing I'm wondering about. How can we get that to be an initiative? Sure, so we do some of it with the large-scale Drupal initiative, which I can talk a little bit more about if you want. The Drupal Association will likely also help a little bit with funding, connecting people that are willing to donate and connecting them to those that are looking for donations. I think sort of a matchmaking role is probably something that the Drupal Association can do and most likely will do at some point. Okay, but as I understood during the session on Tuesday, a lot of people face administrative, financial burden or actually find funds or find businesses interested. So what we discussed was you actually need a company or an organization to not only combine the network, but also facilitate. So that's effectively what I'm trying to do with the large-scale Drupal initiative, so people can pay a fee to join the program, starting at $8,000 so that it can go up. And as part of that, you join a community of other organizations that are interested in contributing to Drupal and making Drupal better. And some of the money goes to the organization of large-scale Drupal and paying for these administrative costs and the fundraising costs and the likes. But what's left is designed to go back to Drupal itself and to help fund the kinds of projects that the members of the large-scale Drupal initiative wanna fix. They sort of get together and they say, well, here's my challenges and here's my challenges and here's my challenges and we compare them and look for overlap between these challenges. And so we fund it through large-scale Drupal. We have funded a number of things. For example, there's quite a few media companies in the large-scale Drupal initiative and they wanted to have, they wanted to see improvements to the way they do publishing and specifically around workflows. And so that actually has funded work in the contributed module space to give them better editing workflow tools and some of these things went back into, I think it's called Workbench, the Workbench module. So we're doing these kinds of things as part of an Acquia initiative, but it is open to every company to join. Yeah, I know it's an Acquia initiative, so I think it's important to not only get it from the business wise, but also promote people in the community, promote to them how they can use this Drupal large, so large-strupal association and how they can give attention to their problems and their needs for funding. Yeah, and it doesn't have to be the only solution. Like I definitely encourage others to start their own initiatives. Maybe there's a need for a small Drupal initiative or some things like that. So definitely encourage people to self-organize, to start these. Maybe the future, this is where the Drupal association could play a more prominent role as well in trying to be a center for fundraising and help sort of take money from organizations and distribute it somehow to all sorts of different initiatives in Drupal. The reason I talked, in my keynote I presented an alternative model, right, which is in exchange for actually contributing, you get something in return versus you contribute and then we'll do something. And the reason I propose that is because one of the lessons learned with a large-scale Drupal and having an organization that does fundraising is that it's very hard. And I think a lot of people underestimate how much work it is. Like we literally have lots of people trying to raise money for large-scale Drupal with some success. But it's very expensive frankly to run that initiative because we need salespeople to go and raise the money. And like it's not something like you create a little organization and you say, but that's the same thing the developers encounter when they want to fund it. They encounter exactly the same problems. That's what I noticed this week. So it's not the magic bullets right now. Maybe it will be, but it takes time to build that fundraising muscle, if you will. Yeah. And that's not some, we've been doing this for, I think it's almost three years now, if not longer. And so after three years and a lot of hard work with dedicated people on the large-scale Drupal initiative, we have been able to grown it to respectable size, but it's not at a stage where it's the solution to sort of the problem that we have. So just to give you a sense, if we were to start alternative mechanisms today, it will probably take years for them to mature. And I definitely encourage you to talk to Michael Myers. It's actually in the back right there. And so Michael is heading up the large-scale Drupal initiative. And so if you want to tap his brain, I will. I definitely encourage you to. And so that's why I proposed what I proposed in my keynote because I think it's easier and we can do it faster. I think it's going to be a combination of both. Yes. And I fully agree. I don't think there's one magic bullet. I think we need different kinds of initiatives all the way from kid tip on the one hand, where people raise small amounts of money, hundreds of dollars a week to this incentive-based program on D.O. Where we give people more visibility and more rewards for contributing to providing a mechanism for organizations to donate as well. Because not everybody wants to contribute by giving time. For some organizations, it's easier to contribute by giving money, right? And so we also need to sort of allow for that. And so we need to start building at all of these things to keep up with the growth of the project. Thank you. And just to add to that, I think we also need to get better saying what we need money for. Like for myself, I spend a lot of time saying, hey, I need a job to help me work on Drupal 8. But there were other people, there were other funding needs, throughout the Drupal 8 release cycle, we've had several different things happen. We've had the views in core chip-in that raised only $10,000 for one of the... 13. 13,000, sorry, $13,000 for the biggest contributor module to move into Drupal 8. That's not enough money to migrate views into core. And so we need to get a better way of saying, here are our targets, here's what we need money for. And then fundraising for it and using all of the different routes that we have. We have LSD, which is targeted at large Drupal users. We have no way for all of the hundreds of smaller agencies of like 10 to 20 people to help us do that. We always assume that those people will in their spare time contribute time to fixing the problems. But maybe they don't have that time. Maybe they have a couple of thousand dollars that they put into a bucket altogether. And so with the multitude of efforts, then that will be one way to get the money, but we need to be clear on what we're fundraising for. And that's another change that we need to make. Because at the moment, it's very, very peaceful. No one knows why we need money. We say we need money, but who knows why? I mean, I know why we need money to pay for people to organize the initiatives because it's really hard to get someone to volunteer their time every week to check in with a whole team of people to organize over a couple of years that the amount of work that it takes to get something done in Drupal Court. But we're not saying that to anyone. So yeah, we need to get better at that. In addition to that, we should also fish in a bigger pool for the nations because it's always the same, like 50 or so companies that people go through to raise money. And that's where we, and so people often say, oh, Wikipedia uses fundraising and donations very effectively, and they do, right? They raise millions, but it's because the people that go to Wikipedia are the end users. And in our case, our community has this extra layer in between where the Drupal contributors, they work for the Drupal Shops and the Drupal Shops built websites for the end users. And we almost never raise money from the end users. And so that's a big difference from Wikipedia where they can go straight to the end users and as a result, there's this massive pool of people to tap into. And so somehow we're kind of stuck going to the Drupal Shops, which is a relatively small set of organizations today. Well, it's a large set of organizations, but the ones you can actually get to is relatively small, I would say. And just to add to that, this is where I'm really excited about the ideas of marking out which agencies and which end users are contributing best back to Drupal because then we can get like a virtuous cycle where people are looking for agencies to do work for them. They can pick them based on their efforts to sustain the Drupal community because if you're making a bet on Drupal, you'll probably want your site to last five, six years. You wanna know that that agency that you've used to build you the site is invested in that future. You don't want just a free rider. You don't want George or very much. All right, great. Let's move on to another question maybe. Hi, Matt Smith from Lingo Tech. And first of all, thank you for doing the Q and A. This is one of my favorite parts of coming to DrupalCon is listening and hearing these issues being discussed. So appreciate that. My question is traditionally upgrading from D6 to D7, D7 to D8, it's been really painful and kind of isolated kind of a new product each time. Have you considered a more continuous model so that upgrades are just smaller and people can just move forward and Drupal is Drupal and they're not really thinking about the version as much? So in terms of developing contributive modules, once Drupal 7 was released, about two months later Drupal 8 was released and we immediately started making Drupal 7 core batches. When Drupal 8 is released, Drupal 9 will not be open and we'll release 8.1 and then 8.2 and then somewhere between like 8.2 and 8.4 or 5, we will open Drupal 9 but before we get there, there will be refactoring done to Drupal 8. Like things that can be done in Drupal 8 will be done. Like if someone's got time to do it and it's possible to do it without completely breaking everything, we will do an absolutely best effort to do it and replace like the old, old, cruffy things that we've done and then when Drupal 9 opens, then you just rip out the old, cruffy stuff. So if you've got a Drupal 8 module where you've kept up to date with 8.4, that might still work. I mean, it might not work when Drupal 9 is out but it should work like the first two or three months probably. What the scope of changes will be in Drupal 9, no one really knows. I think something like the entity in field APIs is probably not gonna change that much. The database there has not changed that much since Drupal 7. That's like, Drupal 7.8 is not that much different. So some of these things are getting locked down. There are other things like the random inform system that are probably gonna be revisited and change quite a lot because they've fundamentally not changed that much since Drupal 6. So I don't think there will be an end to large API breaks because you do have to do that sometimes. Otherwise you really get stuck in some very bad places. But the scope of those changes from the major release should be smaller and there will be longer periods where you can incrementally introduce new things and allow modules to get up to date in a much like more structured way. And then when we do break things it's the only reason why we'll break this and this and this and this and those things and other things will be left and then you get that out and then you incrementally improve again and do that. So I'm not sure. I don't think it's possible to start on Drupal 8.4 ever. It doesn't feel like that to me. I know some people would like that but it's gonna be more like that than it has been and we can progressively get better and better at doing this. The more things we get to like how we'd like the architecture then we can make changes under the hood without breaking everyone's stuff. So the answer to your question is yes. Good. And we have for context for what Nat was saying that we did decide at the beginning of this year to adopt a new release cycle model. So it's sort of similar. We sort of based our original brainstorming on what Ubuntu does. And so these 8.18.2 that Nat is talking about are six month releases, regular scheduled six month releases. And after several of those we have a long-term support release that will be supported for many years. First with bug fixes and then once Drupal 9 is released it will receive security fixes still after that. So thank you. All right one more question and then I think we're out of time. Well the first impression I guess about the funding that was discussed earlier I guess I'm making the same observation that a lot of people do that the same company that is easily willing to spend a five figure number on some Microsoft certification is giving a hard time for a three digit number support for a local Drupal camp. So maybe that could change at some point. I have no idea how but the money is there for software to support. Sadly not always on Drupal. The question that I have is a bit vague. It's about tools. I tried to work with Eclipse some years ago and it never worked out so we split up and I'm back to using somewhat of a text editor. My impression is that PHP Storm becomes somewhat of a soft requirement. Any thoughts about that? I still mostly use Emacs but I have started sort of tasting the forbidden fruit of an IDE in the form of PHP Storm. There are still developers who don't use it. It's not a requirement but in Drupal it does. 16 years of Emacs in Drupal it is making me use an IDE. So it does, it makes your life a little more sane. Maybe let's go from Gabor to here and they can tell you what their favorite tool is that they work in and then we'll have to wrap it up because we literally have one minute left so let's just quickly go left to right or just know what you're developing. Yeah, I adopted PHP Storm. I still use Vim but one day I'm probably gonna install an IDE but I'm holding out as long as I possibly, possibly, possibly can. What will you do when the time comes when PHP Storm starts to rip us off because we depend on them? That's partly why I'm holding out. It's like if I can't do it easily then I can complain about it and once I'm using an IDE I won't notice anymore. So it's like, and I would like other people who wanna hold out to be able to do that. So I use PHP Storm but I've had some really good conversations with a funny member of chapter three who loves his Vim and it's about, you just need to learn how to set it up. Like there's some great plugins for Vim that will give you a lot of the same features that you can find in PHP Storm. If you know how to set up C tags you get a load of code completion that you have in PHP Storm. It's just that it's more hard to teach people to set it up. Well really shortly like PHP Storm too because like it's like the click and install solution that makes just working with a large OO code base like really easy and navigate between the classes and implementations and overrides and stuff like that. It's, yeah it's really great. I continue to use text editors, plain text editors until four or five months ago but now PHP Storm. I use mail. I don't get to code anymore or not much and when I do it's usually VI to be honest. So, but I don't think I'm a reference. So all right, awesome. I think we're out of time. Thanks for all the questions. Thanks to all the panelists here as well. Thanks for making the time.