 Good afternoon everybody. So originally this was going to be a Q&A with me, but we've expanded the scope. And so I have Angie here. Angie is a co-committer on Drupal 7 and Drupal 8. We have Jess, Miribo, it's pronounced. Jess is working on the views initiative. We have Shannon. Shannon is a project manager. She's been helping to coordinate all of the Drupal 8 initiatives. We have John Albin. John is responsible for the Drupal 8 mobile initiative. We have Gabor all the way from Europe. And Gabor, what's the time? Gabor? It's very early. Yeah, it's 5.47. 5.47? Thank you. Did I tell you that to be a core initiative lead, you need to have some real sense of commitment? But Gabor works on the multilingual stuff in Drupal 8. We have Greg. Greg Dunlap. And Greg is working on the configuration management stuff. And then we have you guys. And we have Chris. Chris van der Water. It's actually a Dutch last name, so I need to work on my mispronunciation. So it's actually proper English. Chris is responsible for the blocks initiative and also for the plug-in stuff. And then last but not least, we have the almighty Larry Garfields all the way from Chicago, I think. And Larry is responsible for what was Whiskey. And so that includes Symphony, but also the web services things and stuff like that. So what we're going to do is just basically not present anything, but just kind of open the floor for Q&A so we can answer your questions. Before we do that, I'd just like to talk for like one minute. I've already presented sort of an update on the work that we're doing. I just wanted to sort of share my feelings a little bit. And overall I feel very excited about Drupal 8. I think we've added some really amazing features. And I truly believe that Drupal 8 will be a game changer for many reasons. I think we've added great new features for almost every target audience. Like we have some great new things for developers with Symphony and some of the architectural changes. We have some great things for site builders with views in core and some of the other things we've done. And we've also added some really, really cool improvements for end users, people that actually write content and manage content in Drupal. Things with some of the Spark stuff and some of the user experience improvements. So overall I feel really good about all of the new features that we've added. At the same time we have a lot of work left to be done. There's a lot of things that we've started that we need to really polish. Like some of the APIs and we've definitely introduced some complexity that we need to try to remove or streamline. So it's easier to develop for. So that's kind of how I feel and that happens to be in line with I think the phase that we're at in the development cycle. We're about to hit the feature-free date meaning we're going to switch to polish instead of adding new features. So I would say we have at least six months or almost six months of polish time. There's Moosh. It's okay. I'm going to move the mic around. So that's all I was going to say anyway. So we're just going to do questions. Any questions? There has to be some questions. Yep. It's a great question. I could answer it but like to offer the mic to anyone that wants to answer. Or Mark even. Okay. I don't know Larry. Do you have an opinion? I think a lot of things are related to. Yeah. Larry never has an opinion about anything. And I actually want to correct you on one thing Dries. I'm actually in Miami at the moment at a different conference. So I'm kind of double dipping conferences at the moment. All right. Awesome. Did you hear the question? Yeah. So I think as Mark said, number of languages is not itself a metric of difficulty of learning. You know, Drupal is still a PHP framework. But in Drupal 7, we were using approaches and techniques and concepts that no one would be exposed to unless they're using Drupal. In Drupal 8, we are not entirely but largely switching over to techniques and concepts and styles that people are more likely to have been exposed to. So someone fresh out of college is going to have an easier time understanding objects and, you know, an observer pattern that they're going to understand a render API. No one is going to understand a render API who hasn't worked with it because there's nothing else like it out there. Whereas from a learnability perspective, a lot of the new stuff in the core system, in whiskey, in scotch, is mundane from a larger software standpoint. I've heard Mark correctly. It's kind of hard in the back of the room. You're saying it's not a question of, oh, it's harder than procedural as much as it is. Make sure that the stuff you're doing makes sense in context is consistent and clean, and I think I see him nodding. I agree entirely, and a lot of what we're going to be doing over the next four, five, six months is now that we've got all these new tools in place, let's flesh them out, take them to their logical conclusion, and clean up a lot of the fact that we do have two systems inside each other right now, and cleaning that up is going to be a major task for the next couple of months. I think actually when we get right down to it, the learnability of Drupal 8 will be better than Drupal 7, especially if we document it correctly. If I could jump in on that for just a second. I don't know how much of digging through the code you've done thus far, but in terms of the OO components that sit there, there's been a very high level of documentation going on in the vast majority of patches. It's not uncommon for me to open up a patch in a section that I know nothing about and not have any problems with just reading it these days, and a lot of that stuff is OO, and full disclosure, I wasn't doing PHP OO until November of 2011, and that was writing the plugin system. There are a lot of us, myself especially, who have come along and are doing OO for the first time here in Drupal 8, and I'm very happy with it being primarily a procedural programmer for this. And if I could address annotations quickly, I'd encourage you to really give it a try before you ask me to remove it. That's another thing that's not specific. A note about annotations. I think annotations by themselves are a very defensible thing. I think they're going to be a big DX win. The way we're using them is crazy, though. And I think what you saw, I agree with what you saw, it almost looks like, I mean, it starts to look like code. Okay, annotations are... So the concept of annotations is a way to add metadata to classes or functions in PHP. It's a supported feature in languages like Java and a similar thing in Python. And if you look at the dates around it, by using, if you see the at param in a doc block, it's basically custom at things. And you can say PHP unit uses these, and so you can have a method on a class that's at test. And then PHP parses those, because parsing the doc block is actually a supported thing in the language. So that's not too much of a hack, but then you have to look through that doc block, get all those and figure out which ones are annotations, and then apply that metadata. To add some sort of discoverability to your existing classes and functions. Some people think, I mean, are really just of the opinion that this is a total hack and we shouldn't do it because you're parsing comments. Who cares? It doesn't matter. PHP is an incredibly inflexible language. We need to take the expressiveness we can get. But when it starts looking like code, I agree, that's crazy. And we need to maybe reevaluate how we're using them. Yeah, and just to like throw out an official position on that, I'm not opposed to rethinking exactly how we're using them, but I am opposed to removing it. Currently, it's basically just like anything you would have ever done in an info hook, but it's singular for an individual implementation and it's sitting in a class. I will say that I think that there are definitely trade-offs in Drupal 8. I think that some things, there are hopefully fewer Drupalisms, although we've introduced a few additional Drupalisms in Drupal 8, but we're hopefully moving in the direction of reducing things that are specific to Drupal overall. In the case of annotation specifically and also for the DX in general, one thing that Drupal 8 is doing that's really positive is that we use our patterns consistently. Maybe we need to reduce the number of new patterns we've introduced or sort of streamline it, but when you learn something, you are learning it for all of core. When you look at an annotation on a View plugin, like if you have a Views handler, you read that, you learn that pattern, and then you'll see that same pattern on an entity type. The info hook for the entity type, the info hook for the View plugin is the same thing it's there on the annotation. There's a lot of instances where it may be that we're introducing new patterns that people have to learn, but at least they're used more consistently throughout the code base probably than in previous versions of Drupal. Like Mark pointed out, we are just getting to the point where we're going to stop focusing on adding new features to core and instead we're really trying to improve the developer experience, clean up performance, do refactoring, and so that if that's a concern you have, come in the core issue queue and try to help out with those issues because that's something we're going to be starting to do within the next couple of weeks. Drupal.org slash community dash initiatives slash Drupal dash core. That's for the core initiatives that has bi-weekly updates and issues you can work on and stuff. If you're concerned about that, check out the page. I'd like to quickly echo that as well. This is probably a good time if you're interested in core development to start dabbling around with Drupal 8. Maybe if you have some contributed modules, I know it's early and things may change during the polish phase, if you will, but we very much hope to get people to upgrade their modules and to give us feedback on what you like, what you don't like in terms of APIs and we will still make changes to our APIs at this stage. So it's a good time to give us that feedback and suggest alternative approaches that are less complex or more in any other questions. Jonathan. So I know we're compiling PHP and I'm putting that in the files directory. And if you've got a multi-head setup with lots of Apache servers, then you have to share your files directory. And if you're running PHP from an NFS share, is that going to be a performance problem? That's a good question. You probably don't have to have a shared file system. Every head could have its own copy, probably. That actually adds a little bit more overhead because you have to compile it for every web node. But I don't know. I think it depends on how it is used and how frequently it is invalidated. Mark your... Oh, for every, okay. So yeah, it gets... But people don't enable modules all the time in production. Okay. So there's a question from Twitter. Are you worried about how fast major version releases affect the enterprise community? Yeah, since they're the... Almost always the slowest to adopt. And that's... If you have questions, you can ask them via hashtag IOHECL. Nice work. And that is a question from Dominic Santangelo. I'd like to answer that question. I think anybody who thinks the core release cycle is too fast is insane. We have a three-year release cycle in modern development times. It's like a decade or 20 years. It's crazy. We need to be releasing faster, not slower. It actually depends on what you talk to, in my opinion. So I kind of agree and I disagree. Like if you talk to the actual users of Drupal, some of them are afraid of three-year release cycles. They don't like to have those fast cycles. But then if you talk to developers, they definitely like short cycles because they want to use the latest and the greatest. Yes. Nobody has to upgrade either. Right. I think it's a tough question. Part of the challenge here is at Drupal's release cycle to break more than any other product. And if you look at, you know, a Linux distribution or WordPress or Joomla or a Symphony or Cake or Ruby on Rails, their version-to-version API breakage, even if they have it, it's substantially less than ours, whereas we basically release a brand-new platform every three years. We used to release a reasonable upgrade with some API breaks every couple of months. Then some time around Drupal 6, well, first it was Drupal 4.7 with form API where we changed everything. And then after Drupal 6, Drupal 7 became a massive game-changing release and Drupal 8 is a massive game-changing release. Those take three years and break a lot of APIs. And we can argue whether those are necessary or not. I think they are. But we may want to ask the question, you know, do we... Good question. We want to force ourselves to break fewer APIs so we have more free release. One of the nice things about a lot of the changes that are happening in Drupal 8 now is that because we've decoupled so much stuff and we made it so much more modular, it will actually be a lot easier to make changes that are less invasive going forward from here and to build backwards compatibility on top of it when we want to, which I think is really important to having a faster release cycle. Because Astri says a lot of people are scared of fast release cycles because of the changes and the upgrades that they have to perform. But I still think for a lot of reasons and not just for new developers, stuff like that, but I also think that in terms of our core community, we put a lot of pressure on ourselves in each release because we only release every three years. And so there's a lot of pressure to get stuff done exactly right and that's where a lot of our conflict and the issues and stuff like that comes from as well. So it's not just... there are a lot of things in terms of our culture and how we work together and all that stuff that are influenced by release cycles. Yeah, I think that that's a really, really valid point because there's an awful lot of conflict that I think wouldn't happen if we knew that in six months we could change it if we were wrong. Can I make a quick comment on that too? Because it sounds like this person is worried about enterprise community lagging behind when we have a release because it's too soon. And I think there's a lot of different stakeholders that are impacted and interested in these releases and you can't make everyone happy. That's number one, like the Drupal shop owners want something that they can build off of for a few years and not have to completely retrain their entire team and do all this other stuff. Enterprise communities want something stable but developers and end users, we want functionality and we want improvements and we want things to advance. So there's no way that you're going to satisfy everyone unless really the community makes an effort to make the upgrade path and the path to improvement a lot better and that means Drupal letters, that means documentation, that means people really getting more involved in the training aspect of things which will make advancement a lot easier to do if we all can do it in a faster, more easier, less, oh my god, I have to relearn Drupal kind of way. So I think if this is going to be successful and we're going to have faster release cycles that don't piss everyone off and make it really, really hard we have to really focus on the training development and moving forward into the next phase aspect of this community which I think is sorely lacking. So that's my comment. I've already started to look at some other ways and I think there's a couple of interesting ways to do it. I think the right time to have that conversation is when we're about to start the Drupal 9 development cycle. I just, I mean I don't want to basically have that conversation now because you have to be really focused on Drupal 8 in my opinion but what I do want to say is that I'm open to making changes and I'd like to organize a big discussion with all of the stakeholders and see what trade-offs we're willing to make. So, Mark? I think one thing we can do in the Drupal 8 cycle and a big part of this is deprecating instead of breaking and so if we're changing an API in Drupal 8 we say we may move some procedural function or procedural functions functionality to a class we can keep the function and have it pass through to the new API and market is deprecated and so none of course should use it. We still have all the functionality there but we don't immediately break contrived on day one and I think the more we do that the easier it will be to have major upgrades. That's a good point. All right, so let's see if there's some other questions because we can talk about this for an hour and I just want to make sure we were able to cover a few different things. Marie? So, considering the volume of the changes that have been made or that's being made to Drupal 8 for example, using Core, you know, I'm thrilled to have it in Core but considering the amount of translation that needs to be done I'm quite concerned that the timing of string freeze if we don't have it early enough I mean it's difficult but if you don't have it early enough the chances are many languages wouldn't be ready for the initial release and I'm just wondering if there's any strategy or work around for that. All right, anyone has a good answer? It pretends to be frozen. That sounds like a question for Gabor. Gabor, did you hear the question? No, I didn't hear it. I'll try to summarize the question. So, Marie expressed a concern about the timing of the string freeze and he's worried that there's not enough time for people to translate Drupal 8 specifically because we've added so many things to Drupal 8 like views which is adding a lot of strings and so he's worried about the timing of the string freeze. Yeah, so I think there's two things that help with that. First is anytime there is a tagged release of Drupal 8 even if it's just like some kind of beta or alpha or something then it will be available on localizeDrupal.org already right away. So it can be started to be translated it's not necessarily frozen strings but people can start translating stuff. And the second is localizeDrupal.org is built to share translations with projects so all the translations from views will automatically be applicable to Drupal 8 and people will not need to manually copy them over. So whatever is already translated will be there right away and it will speed up the process of translating Drupal 8. All right, other questions? Any Twitter questions? Trying to find a good one here. Yeah, one not written by Dave. Yeah, he's got a lot of good questions. How about this, what's one thing that you didn't get to do in D8 that you want to do in D9 and that's from Dave Hall? Interesting, isn't Dave in the room? Who wants to go first? So one of the things that we aren't doing in Drupal 8 that I'd like to do in Drupal 9, to be honest I haven't really thought about Drupal 9 yet. But I feel like right now it looks like one, we won't be able to do all of the symphonification that we may have hoped to do and that we may end up with a Drupal 8 which is mostly converted but not fully converted. Similarly around the authoring experience stuff that we're doing, I think we have a much bigger vision of things that we could do. For example, one of the things which we've designed and prototyped actually is a responsive layout builder. I'm not sure if you guys have seen that but it effectively allowed people to build responsive layouts without having to be a designer, without having to write CSS. I haven't seen anything like that in any other platform and I think it would have been something that would allow us to leapfrog the competition but it doesn't look like we'll be able to get it done. Just two examples but I think what it comes down to is a list of things versus one big thing. I don't know if you guys have any... To build on what Dries was just saying, the responsive layout builder is a big thing that I really wish we could have gotten into core but we have some interdependencies on different initiatives and the blocks and layouts initiative work that happens and we just... I don't think we're going to have enough time to get it done but I'm still very hopeful that it'll be part of Contrib because I do feel like it would be really useful for people who are non-designers to build layouts. There's also a possibility of... Those are familiar with the responsive images problem. We could make a solution that auto-configured responsive images as long as Drupal knows about the layouts and where the breakpoints are. All that could be auto-configured and responsive images are very difficult to configure right now and the only way you could solve it is with a responsive layout builder. I'll be really quick because I know everyone has other important things to say but one of my own personal wishes for Drupal 9 is actually more funding so that it's not just a volunteer-driven effort but people actually have time and resources to invest on a regular basis. I think that that would really, really revolutionize this entire release process because you wouldn't be basically saying, please, X person, put your entire life on hold. Don't have a personal life so that you can do this bit because you're blocking 20 other things and that would be awesome. I guess over the last year or so we've seen some interesting crowdfunding models especially for independent game development, things like Kickstarter. The Drupal community, because it's so large and global, if someone had a Kickstarter campaign, for example, to put views in core, how much money would have been raised? I actually can address this. First of all, it's very difficult to do a project like that on Kickstarter. I do a lot of fundraising for my initiative and part of Kickstarter is that you actually have to deliver something and you have to do it in a specific time period so it's not really appropriate for us to do stuff on Kickstarter and there's every possibility that our thing would be canceled. However, I will say that Fusing Core did put up a chip-in. I mean, Jess can address this more and they did raise some money. I did the same thing for CMI. It was a very, very small fraction of what I needed and in historically those crowdfunding efforts while they may not have the inherent marketing that a starter has just because of their name have all fallen vastly short and historically, I mean, that has not been a very positive model for us from the funding perspective. I can talk more too about how Fusing Core was funded just briefly. We put up a chip-in. We raised about $13,000 which is an amazing sum of money. Some part of that went to funding sprints and so forth. Some part of that went to fund part of my time but the rest of what made views possible and probably a much bigger chunk of the total amount of money came from individual companies sponsoring developers. We have four people on the team, myself, Tim Plunkett, Damien Lee and Daniel Vayner and the other three people, not me, work for Drupal Shops. I work for Drupal Shops out too, yay. I started Acquia next month. Anyway, so Tim, Damien and Daniel all had part of their time funded from the shop that they work for and like a significant portion, we're talking like 40% to 50% of their time was contributed by that organization which is amazing. That's ZivTech, New Digital Partnership and AirdFish by the way. So those guys made views in Core possible. And then My Time, so the first third of My Time by the Chippin, Acquia funded the next two months and then I have a third sponsor that I, they still haven't let me tell people who they are but I do have a third large open source company that's sponsoring My Time up through February 18th. So that model has worked very well for views. We were able to do a heck of a lot in a very short amount of time and so it, I mean it's definitely not possible for every shop that, yeah, there's like a certain minimum size to make such a huge financial commitment but I think that committing a developer regularly is one of the biggest things any organization can do for funding initiatives so. Yeah, if I could hop in on that for just a second. I mean like Commerce Guys donated a ridiculous amount of My Time to the Blocks Initiative. I mean there have literally been weeks where I've had 40 hours a week to work on it especially coming up to and shortly after like Munich and things like that. So yeah, but you know this is the exact same sort of stuff that was happening in views like Jess was just talking about and when a company steps up and actually puts one of their developers out there to do it, you know, that's when things really start happening unless you know you can go and you can fundraise like Greg did. If I could go back to the question that was originally asked for a second here instead of jumping off on fundraising for a minute because that's more of a retrospective like what would we do different going forward sort of questions. Wait, before you start, can I pimp the people who gave me money? Not totally. This seems like the time to do that, right? There were six companies that donated $5,000 or more to CMI. There were Acquia, Riot Games, Dennis Publishing in the UK, Bluehost, Web Enabled, and Pantheon Systems. So, please. I got to work full-time on CMI for seven months because of that, which was amazing. That is freaking amazing. I'll chime in. Just to comment, just to tag on on what people said, you know, like I interview a lot of people and there's a certain set of people that just come into the interview process and they say, I'm interested in working for you, but I like to work this many hours a week on Drupal. And, you know, it may be worth trying with some companies. I think some companies are actually very open to it if you actually ask for it and the right time to ask for it could be during the interview process, to be honest, because... So, just that tip, I guess, for developers. And the other thing I'll say is that most web development companies, most professional services companies, their employees have a little bit of bench time. Like, it's rare that you have 100% or more utilization in your company. And so, what happens with the bench time? I don't know, but it's usually, you know, some companies give the bench time back to the community, so to speak. So, another thing that some companies do is actually add a little extra charge to their invoices. And that extra money is used to effectively have their developers contribute back some of the things that they've developed for the customers. And sometimes it's a line item on the invoice and if the customer doesn't want it, it's taken off, you know, of the proposal. But often I think if you explain the values of open source, if you explain the values of contributing back to the project, you know, a lot of customers do get it. So, that's another way to make sure that you're able to give back. So, Chris? Yeah. So, I just wanted to hop on the responsive Layout Builder train here for a moment. I mean, that should be obviously my one big regret here. We just, we didn't have the bandwidth to get that far. Although, I'm hoping to be able to demo here in the next two weeks that Sam and I have basically gotten to everything but that, which that in and of itself is a really huge topic, the everything that goes with really putting that Layout Builder in the right place and putting all the infrastructure around it to make it work appropriately from a user interface perspective. But I think, you know, looking forward, we have to figure out how to get that in-contrib as quickly as possible during the ADEC site mine because we've worked very hard to get all of the underlying architecture like that possible. Layouts, like, I mean, in the previous session, I talked about this but, you know, we got blocks in, we got layouts in, we've got displays in. I'm hoping to have context and conditions in before next week is out. So, you know, there's like all the groundwork is laid. It's a matter of putting together a user interface that we can all agree on. And I spent an awful lot of time during this cycle actually discussing user interface with a number of people, especially boy on summers. And that's a really, really dense topic when it comes to what it is that the blocks and layouts initiative was trying to do. And there aren't any really fantastic answers in there, but when it comes to really, like, laying out the page and putting blocks in it, the concept of the Layout Builder, the responsive Layout Builder is a really, really good one. We need to chase that and get it available as quickly as possible. All right, so we'll take another question in a second, but let me quickly bounce back the question to you guys. I mean, having looked at Drupal 8, is there anything that you guys think is really missing? Anything that comes to mind? Yeah? The one thing that I'd really like to see in the next major release of Drupal and Drupal 9, that we always want to do, and nothing has really had activity around it yet, is some better tools for data migration into our core. This would make upgrading easier since, you know, upgrading a Drupal site often involves re-architecting anyway. It would also allow people to migrate from other solutions to Drupal, things like that. That's something that I think would be a really big one for Drupal. It's one of the things that people are concerned about most often when we do surveys about Drupal, so that's something I personally would like to see for Drupal 8. I'd like to see better media management and Drupal 8 would be really good. Integrated as part of the content authoring would be a really great addition to that, to be able to manage all your images, videos, all that kind of stuff. Oh, what a surprise. Mark Sanabam has an opinion. Well, I was just going to say that it would be nice to have PHP unit for unit tested, because surely Greg, your classes are not actually unit tested, are they? Mark and I were actually talking about whether or not we'd be able to do some of that in 8, just a little bit of go by the way. Can we? We should finish. Anyone else have a question over here? Just to add to the layout, I guess if we'll take the smallest bit for basic website build, views already there and WYSIWYG is coming in, but I think, but I guess what's really missing, just to complete this band, those web forms. We're going to have web forms inside Drupal, then I guess for a basic website there's not going to be need for module extension from beginning, so I guess it would make adoption of Drupal way faster than we saw adoption of Drupal server. I just wanted to ask because I haven't kept up with what's happening in Spark and that I've been doing accessibility testing with Mike. What is happening with that? I'm sorry, can you talk into the microphone more directly? We can't hear you at all. Sorry. I haven't kept up. I've been doing some accessibility testing, but I haven't really kept up with what was happening on the Spark side. Are we going to have inline editing in Drupal later? What's happening there? Just for a small update. Sorry. Yeah, so Spark is an initiative to put a bunch of authoring experience improvements. We started prototyping in Drupal 7 just before Munich and then just after putting those into core. We managed to get the responsive toolbar. In Drupal 7, when you look at your toolbar on an iPhone and responsive theme, it takes up roughly three quarters of your available screen size because it's just like this. The new toolbar is really great. It can seamlessly switch back and forth between horizontal and vertical orientation based on the width of the screen. It also has icons, so when you scroll down to a small screen size, it just shows the icons and hides the text. We worked with Everett Zufeldt. He was the former accessibility maintainer. He's an actual blind Drupal user and a developer. We worked with him on it at Drupal Camp Toronto in November and he said that this toolbar was the single best implementation of an accessible drawer based toolbar that he had ever witnessed. From now on, when people are asking him questions about how to make these types of things accessible, he's going to be like download Drupal 8 because we got it figured out. Jesse Beach has been instrumental in getting that whole stuff done. She has a spark in general. In-place editing is the second feature that we added. That is also fully accessible. It's keyboard-accessible and we added aria, you know, live region type of things, so it'll explain where you are on the page and it's editable, this. It's very svelte in streamlines and stuff like that. I think people have a hard time with accessibility that sometimes because they try and make it so when you click in the page instantly, it's editable. People get annoyed as hell by that. We have a little flag at the top that's toggle on or off edit mode. That's how we make that accessible. That's done. We did a bunch of work just generally with the mobile and layout initiatives that goes forward. We didn't, unfortunately, get to the big responsive layout UI and the nice drag and drop blocks UI that we were hoping to get to. We had to kind of pivot there. We're really trying to push hard on the authoring experience in Drupal because it's a huge, it's a place where people will try Drupal for a second and say, this is awful and then they'll leave and then they'll go use WordPress or something that's really nice and easy to use right out of the box and they'll use that on wall because I can't do this one thing, I guess I'll go back to Drupal now and then they find Drupal again and then they love it because they figure out it's so flexible and awesome. I'm kind of like, wouldn't it be great if people could just have that impression of Drupal right away and so instead of having to leave Drupal and go do some other framework that's not as powerful, they just see it and they fall in love with the user interface as much as they fall in love with the code and so that's what we're trying to do in Spark. Yep, so yeah, that was great. So, you know, AQUI is always funding like all of us to work on this and the team has been very focused on Drupal 8 and so we let the Drupal 7 stuff just kind of you know, because we had very limited time to try and get Drupal 8 in order and so it was just kind of stagnant and hanging there and Radio France actually approached us and said, you know, we love what you're doing with Spark, this authoring experience is really improved, we need it today and so they actually funded a nod, a theater or be a dollar who's been involved in Spark for a long time and they funded him to actually crank on the inline editing and WYSIWYG capabilities in the Drupal 7 version. So now you can download the inline editing and the WYSIWYG functionality from Spark in Drupal 7, use it today and it's just as good as the one in Drupal 8 and hopefully we'll continue to get better and if you're interested in funding further development on Drupal 7, Dries posted a link to his contact form in his blog post so apparently he wants you to talk to him. Yay, thank you. Thank you for Radio France. Great, Kim, I bring the mic. Thank you. One of the really exciting things I think is all of the composer support like basically pulling in all of these external libraries and I'm just wondering if there's how this is going to affect like contrived development so you know obviously there's a lot of contrived modules that integrate with external APIs and libraries and yeah just how is there just going to be support for hooking into that kind of global composer thing? Great question. Was stating that with symphony and the composer stuff specifically in core this question is how is that going to affect contributed module development and how will we deal with those things in contrived? How does symphony and composer affect modular development without the question? Yes. So it depends on the module really. For modules that dealt with the core routing pipeline in some form that API has changed considerably and you have more power than you're used to the API is very different so that will be a non-trivial task to pour that module however you should be able to do it in a way that lets you vet and test your code a lot better because because of the way things are broken up and because it's all done using injected OO you should be able to do actual real unit tests on your modules now for a lot of them which is something that previously just physically wasn't possible to do so that should actually help. For other parts of the system say I maintain a text filter module symphony has pretty much no impact on that whatsoever that API has been ported over to plugins which is separate and Chris is cheering that and I am too because core used to have about eight or nine different ways that you could extend things and provide new implementations of things now with plugins and core once we are done converting things there should be only one so I think there will be in a large sense a large hump get over for contrib modules but once you get over that hump the it should be a lot easier to learn the whole system than learn how to learn each individual piece Hey Larry I think Kim was actually asking a different question which was like will composer have any effect on like say the way distributions are packaged or is that kind of more what you were or pulling in external libraries that can be used with a module so say the feeds module could automatically grab simple pie or something like that ok entirely different question you're right right so composer it's not going to have as big an impact as I wish it would because at least as of today we are not actually using composer for core aside from a way to keep things updated easily there is a drush plugin for composer that you can use now in triple seven as well that lets you download additional libraries through drush so if your module depends on a drush library your module depends on a third party library you can specify that with a composer.json file and use this drush command to download everything and set it up that works now in triple seven I would really like it if we switched over to just saying you know what we're not going to put anything any of these third party libraries in repository everything is going to be composer you want new libraries find modules are defined with composer files I don't know that's going to happen there is an open issue right now to use composer.json files for module dependencies you've got about a week to get it in I think so I'm not hopeful for that which is unfortunately ten ten days we've got ten days to get that in so I don't really have hope for that at the moment but if that's your thing and you can drive home in the next ten days I will love you for it that's a really good segue to this question there's a question from Kathy it's probably our last question but it's a really good one what do you need during the next two weeks can we can we address that in just a second because I really wanted to tack on to what Larry was saying before we run down that last question rabbit trail okay quickly alright 30 seconds the plugin system was designed so that it could have been included in the plugin system and we would still really like to see it done that way those of us who developed the plugin system but that being said if you use a plugin based approach we're working to get the annotated discovery mechanism pushed up into the component portion that we want to see out in composer so ultimately if you use a plugin based approach it's at least a little bit more within grasp I don't know it's not necessarily feasible yet but I think the general point of what I'm trying to say is we're sort of moving that direction whether it ever actually manifest or not is completely up for debate did a previous question I guess which was why do you need help with in the next 10 days and I guess we go around quickly from initiative lead to initiative lead and maybe mention the one thing or the one two things that you need help with so we always need javascript developers to help improve this in Drupal 8 additionally we need people to clean up Drupal cores CSS to make it leaner use less specificity therefore we're going to have smaller download sizes for all of the themes that we build for all of our client sites does someone else want to go while Jess looks at our cue me? oh god what do I need in the next two weeks I need people to check back to the Drupal initiatives update page a lot and come to the sprint on Saturday even if you're not in Sydney please please please join us there's a lot of good to be done so come do stuff we'll send you in the right direction just get involved so I just needed to check on the status of an issue because I've been here in Australia for like a week now and it's been wonderful and I haven't looked at Drupal.org at all so views is in really good shape for feature freeze we have like one fairly small feature but that would be good for a lot of it's useful so our last feature here that we were going to try again is to add an HTTP response code area handler so you could make a view return a 403 or a 404 or whatever and right now it had one of the points of feedback we got was right now it has the list of every single response code possible so you probably don't want I'm a teapot not in that list but that's like the last feature that's view specific there were a few things from other initiatives we were hoping to happen but most of our work now is going to be integrating with core APIs converting views like I said the really big thing I would say to help with is we need help getting core issue counts down to our issue thresholds because those block new features from being added so we have 10 days left for our cute little feature for views that would be very useful I think for a lot of sites so right now there's 19 critical bugs, 25 critical tasks, 108 major tasks 104 major bugs all of those things that are over 100 for the majors and 15 for the criticals block views from adding our last nice feature any other feature from being added so that's what I would ask everyone to help work on I need people to come to the sprint tomorrow which is Saturday and not Friday and people who are watching this remotely help work on those issues do whatever you can to help us get those issues back down to thresholds so that our technical debt is reasonable to add these new features in and that's across all of core so Jess took mine please help us fix bugs I also I haven't been in the spark you very much for the same reason I've been enjoying myself not being on Drupal at work but spark we're currently undergoing this project to unify in place editing because right now we have contextual links we have local tasks blah blah blah blah and it's kind of a mess so we have an issue which I can get the URL and well I'll have it at the sprint tomorrow an issue where we're trying to streamline all of that so taking the overlay from taking over everything and instead only firing it on contextual links where it makes sense to have the extra background there minimizing the look of it so it's not so overwhelming minimizing the form so when you click into contextual links to say I want to configure the block title you only see the block title in the form and not the whole thing that's undergoing usability sort of it's in a place with the usability team it'd be great to have some people in there commenting on the usability especially if you are like a content author or this kind of or a site builder type of person so we actually need help from non-technical people to kind of give opinions on this because we're sort of at a deadlock in terms of like what we believe and what the UX team people from the UX team believe on that otherwise spark just generally needs help from javascript people a lot of front end stuff lots of stuff to do there helping out with twig would actually be great that's going to be a huge component to helping front end developers we can definitely find you stuff to do but we have a tag in the issue called spark so you just look at that list and sort of by priority that's our hit list the rest team has one more feature that would be really nice to get in right now we depend on Drupal's usual authentication the cookie based authentication for your rest request and it would be nice to get basic or digest authentication in so that you could make a authentication request at the same time as your rest request yeah so we actually have a whole website for the initiative drupal8multilingworld.org and we have a focus we have a focus issues tab on the site you go there and it lists visually all the issues that are need review or needs patch or are to be committed etc and those are the focus issues that we want to work on in the upcoming two weeks and it's always up to date and live so you can check that out and see very visually what we need help on that's it Chris so I am working very hard to get context plugins in and I think that's likely to happen tomorrow my big outstanding thing that just has to go in before the 18th is conditions and I've got the API pretty well in order and I'm working to file some user interface follow-ups to that but if people could just kind of hop in the conditions stuff that's node one seven four three six eight six make sure I don't transpose those numbers so yeah that would be if you could message me the two issues for the context plugin one and the condition plugin one I'll try to get people to look at them at the sprint tomorrow I cannot hear you I'll tell you later great Greg and then Larry I mean for the next 10 days I'm in pretty good shape for feature freeze I think people should help Chris Chris Gabor and Chris with their stuff because they have a lot more stuff for feature freeze than I do but going forward I'm going to need after that there's still a lot of conversion of Drupal core to happen to CMI we just added a new multilingual metadata system to CMI and we're going to have to add that all for core and write it all so that I'm going to need a lot of help with that and if you want to get involved in the issue queue the tag that we use for issues is configuration space system and you know if you're and if you're scared about getting involved with core you go to just as core mentoring hours twice a week because they're awesome thank you for that beautiful segue we're also holding a training tomorrow for to teach people who've never maybe never contributed to Drupal before how to get set up with the Drupal development environment how to use the various tools the community has like the issues and so forth and concurrently with that we're also holding a core mentoring sprint so there's actually three separate things going on tomorrow in these two rooms and this core mentoring sprint what it is is we find current real tasks in the core queue and we say okay this critical issue here is 100 comments long and the issue summary doesn't really describe what's going on so what you can do is read that whole issue take an hour or two read the whole issue do some research understand the problem and then write a good clear issue summary things like writing tests for some of these bugs so we can actually help you find something to work on and not just like say oh this is your job go work on it but there'll be mentors there who will help you through the process so yeah if you want to get involved tomorrow come here we'll meet for the core mentoring sprint meeting in this very room tomorrow and then we'll be going over next door to the centennial room for the larger sprint 9 a.m. thank you and one quick thing to add on that like one of the things we like to do is we like to commit patches from people that have never contributed to core and like make it you know make it make it a first tomorrow so yes it is our favorite we'll we'll commit your patches live on stage so alright Larry you have anything that you need to most help with yeah there's still a number of open issues for whiskey this point not all of them are features but I think the two biggest feature related pieces are the entity reference handling for the rest module which I think is kind of critical and I said you know Lynn's got a pretty good layout of what the problem space there is and the kind of help she needs it's not code help at the moment it's design help figure out okay what is the right way forward here and the other major feature related piece is getting us to the point that we can be doing partial page rendering and HTTP based caching that's huge if we can pull it off and really really disappointing if we can't because that's you know a lot of what the company built is building towards that and it's the site but still you know so close to get so far so that's really a big area of focus once we pass the feature deadline as Greg said there's still a lot of conversion work to do once we see where the dust settles and what's the equivalent of a page callback is in the new model between whiskey and we're going to need an army of people to convert all of the old page callbacks to that new system and we want to be able to get that done so we can take out the old routing system and you know eliminate that duplication so that's something we need a lot of people working on it and it's also a great way to get your practice in for Drupal 8 and for porting contrib modules to it I'd like to off hand refer to this as it's nearly time to port Drupal to Drupal 8 and that is phase one for making for getting yourself up to speed on the APIs and for getting your contrib modules ready so that's going to be the next big step is trying to crowdsource that process of porting Drupal to Drupal 8 now that we've got all these new systems in place all right thank you Larry so we're out of time but as you can see we need a lot of help don't be afraid to get involved we can help you get involved I promise you you'll love it most of the time it's actually a very fun thing to do so before we wrap up I'd like to give a big thank you and hopefully a round of applause for all of the people here up front because they're making huge sacrifices to make this happen like they're giving up nights, weekends, time away from friends and family and significant others to really build Drupal 8 which you know all of you all of us and many more benefit from so if you're at the coach print tomorrow bring them some ice cream milkshakes whatever it takes to keep them going because the next 10 days are probably going to be a little crazy for some of the people here so Petticoala for me his name was Charlie and then it's 10pm Friday until 6am Saturday do it yeah if you are in New York City it starts at 5pm and goes until 1am also party on so that's Friday and then if you're in Chicago 4pm until midnight Friday and then 3pm in Denver 2pm in Los Angeles you get the idea so anyway if you're in the North American region it's going to be Friday not Saturday so just be aware of the times and please if you're here go tell a friend to join no matter where they are please, thank you because you don't need to have registered for Drupal Con in order to participate in this print so bring as many friends as you have seriously great, alright thank you everyone enjoy the rest of the conference there's not that much left but have fun happy coding ciao