 good morning everyone I was a conference so far so I'll be here talking for a little bit about the directions for a core it's very much meant to be a discussion so I don't have a whole lot of slides I do have a few slides but after a slight I hope we can have a you know a very what's the right words a very sorry productive for sure but hopefully entertaining discussion about this topic but before we start would be useful for me to get a sense of how many people consider themselves to be core developers alright so a good chunk how many Drupal developers I guess everybody no surprise so here we go so the thing I wanted to talk about is something which we have talked about a lot and then somehow we stopped talking about it and so now I want to talk about it again any guesses no guesses said it again it's much more interesting so what I wanted to talk about is if we want to talk about performance we still can but I would like to talk about some of the possible directions for Drupal core like you know it's a big core small core you know packaged core or you know lieutenant core model how many people are familiar with this discussion all right almost all people so I'm gonna I'm gonna like try and summarize kind of the the different viewpoints and share my own viewpoint and then hopefully talk about it more so I think that what most users want end users and almost no core developers they want a bigger core and so if you look at Drupal 6 and Drupal 7 Drupal 7 got you know has gotten much bigger than Drupal 6 obviously we added a whole bunch of stuff and possibly you know in the view of these people the users Drupal 8 could even be bigger than Drupal 7 right and so some people suggest adding things like drafts and inline editing and media and you know all of these new things which are working on so naturally core tends to get bigger and bigger over time and that's kind of the big core position there is you know advantages and disadvantages to that you know some of the pros are we have you know much better out of the box functionality so for people that just come to Drupal and they download Drupal they can install it and all of a sudden they have something useful to work with versus something which they need to add you know like 20 modules on top of another advantage is more on the logistic sites of things which is there is only one repository there is one issue Q you know it's all centralized right the way we the way we work on this some of the negatives are complexity of core growth you know for some people that's considered a negative especially the developers the current core developers I would say they don't necessarily like to work on some of these other things you know they're they're used to working on their subsystems and if new subsystems come in it's not always something that they're passionate about and so arguably we would need to attract core developers that are passionate about these new subsystems but you know these are some of the arguments that I've heard against it on the other side what a lot of the distribution authors want and you know a chunk of the core developers as well as is kind of the small core model and the reason they want this is you know especially in Drupal 6 and in Drupal 7 it has gotten much better but in Drupal 6 if you wanted to build a distribution and you wanted to overwrite or change some of the behavior of core you needed to do a lot of work to undo the things that core did in Drupal 7 I think that has improved a lot and I think in Drupal 8 if we if we do what we want to do with symphony in the other initiatives I think it should you know should be easier for people to undo things and that's primarily why these people I think wanted to have the small core stuff so here's another view of that where you know basically in this world Drupal is pretty much a framework exposing APIs and then the different distributions they just add contributed modules on top of a basic framework there's advantages and disadvantages to this as well we have better separation between product and framework which is is healthy to have these abstractions and separations we still have only one team right it's it's one team one one issue queue one kid repository it would be a smaller code base and so the theme could be responsible for less and arguably we would be able to iterate faster on a smaller code base there's some negatives of course you know distributions there's a lot of distributions I really believe we'll have you know thousands of distributions over time and hopefully hundreds of really good ones we already have several I think we already have like a hundred plus if not more well with in this model there is a real risk that these distribution authors would need to reinvent pieces or that they you know they don't get synergies as much as they would from a bigger core you know one of the biggest problems right now in Drupal is all of the choice like people knew to Drupal it's like oh there's 10,000 modules all I want is built an image gallery which you know how do I do this you know which of the modules do I use so it's not easy for users to you know to deal with that choice and it's often through our companies right the development shops that we help the help you know users make make those choices now in the case of distributions it might be slightly different because you would think and users would download the distribution so we would need to figure out how we help users with all of that choice I think another con is if we are honest with ourselves then you know Drupal simply doesn't compete with some of the other frameworks we're not up there in terms of you know quality and the reason Drupal wins today is because we have this unique combination between framework and product it's not because we have the best possible framework in the world and then the you know the final point here is I'm not even sure I would like to be a framework because in my mind while frameworks are great they're really useful for building bespoke websites they're really useful for building I mean there's just fewer websites and I would like to do I would like us to do things which matter you know really think big really trying you know get to you know 15% of all the websites in the world and I think you don't you simply can't get there with a framework approach you need the product slash framework approach in my mind so there is disadvantages then the third model is kind of the packaging model or the lieutenant model there's probably different flavors of this as well but it's a model where core Drupal is maintained by a number of maintainers and then we pull in contribut modules through like a make file a drush make file or or some other mechanism but effectively each of those contribut modules would be maintained by their maintainers and they would have you know obviously authority over these modules right and so it's like the virtual core team grows pros and cons to that as well you know we Drupal itself would be more of a distribution I guess it would be more useful out of the box which would be a positive for end users you know future versions if we apply this model future versions of Drupal they they would ship with key contribut modules ready to go like we would need to align our release schedules you know so if you release core well maybe views should also be ready at the same time before we can release core that obviously wouldn't be easy to do but it would be very helpful for end users the other advantage is because more people would have authority to commit things we wouldn't get blocked on core committers as much there's more people that could commit to their their pieces of the project than the cons obviously you know if we have 20 more modules that we are pulling in then there's 20 more places on D2O that we would need to track a lot of issue queues a lot of people to deal with a lot of back and forth probably so it definitely makes you know working together a little bit more difficult as well it can also be an issue relative to security releases like if you would need to do a release all of a sudden we need to make sure we can you know we can pull in all of the latest versions of these modules and make sure they're all well tested and secure one other disadvantage is that it becomes a little bit harder to main maintain consistency you know because different people have slightly different views on how things should look or work and I think one of the things we're good at in core is you know applying rules and making sure things are nice and clean like if you think about some of the top contributed projects historically some people have preferred much more object oriented approach and other people not and like so we'll get more inconsistencies across core Drupal most likely and I think you know it may be difficult for people that consider them you know generalists in core to keep up so I think there will be more separation in terms of specialties so that's kind of as you know the three different models big core small core lieutenant core I think that's sort of the terminology that we've been using before we jump to the conversation piece I like to maybe share my vision and my vision can change over time and it has changed over time but this is my current thinking so I really believe and I've set us in the keynote as well that the core of Drupal should have all of the infrastructure that people expect in a website and that goes from the developer experience in my mind we need to have all the right APIs things like web services I think these belong in core because they're they're gonna be infrastructure in the future things like configuration management I think these are all great examples of things which make up the infrastructure for building you know pretty much every website and so that means adding those things to core that means a bigger core the same thing applies in my mind for building websites you know the tools that sidebuilders needs I think again things like date module which so many people use things like you know pat auto module which almost everybody use I think honestly they probably belong in core and you know lastly I think it also applies to content authors or you know usability in general like people really as I talked about in my keynote people really have come to expect things like inline editing wheezy week you know all of these things they're their infrastructure nowadays maybe not 10 years ago remember when we hated JavaScript and when we hated wheezy week I think we still have some of that stuff going on and you know maybe it's time to let go what doesn't belong in core are all the things which you know only a small portion of all the websites need or the things which are very specific to let's say you know particular industries that are not you know general tools and features so I think the way to get there is to is to you know possibly go with some sort of hybrid model where we do need to add more stuff to core but then you know for certain things which you know we may want to use the lieutenant model and pull in some of the bigger modules instead of putting them in course of things like views and media module I think maybe good examples of things which we want to leave outside of the core but at the same time things like you know date module and you know some of the smaller modules I guess maybe over time they should become part of core so we get the advantages so I think I guess what I'm trying to say is I think we can carefully craft a model where we can look at the pros and the cons and try to get as many of the positives and try to eliminate as many of the negatives I don't think there's a single rule which we can apply but I think we can look at these things on a on a case per case basis more over very recently and this is huge actually you know we did make some changes to you know the way distributions can be built on dito dough we can actually now build distributions on dito dough and so that actually enables us to to try and do the packaging thing and so you know one of the things I would like to try and do is and I've created a project base page for this it's called Phoenix and I really like an experiment with this model a little bit in Drupal 7 and so my goal is to you know maintain a distribution of Drupal called Phoenix and to pull in some of the best authoring experience tools so it's kind of in my mind it's kind of like a press flow for usability and just to learn you know learn how to use these Drush make files and all of these things with the goal though to kind of like build a prototype of what Drupal 8 could look like in terms of authoring experience so we have a functional working prototype and then hopefully and hence the name Phoenix we can figure out a way to move some of these things into Drupal 8 core as well so let's build it for 7 then move it into a Drupal 8 core so so I want to try and apply that vision to a Drupal 7 distribution to see how it works and how well it would work so that's basically my little overview I think we have about 40 minutes left or you know 30 minutes left so we have a lot of time for discussion I think it's worthy a discussion as I said in the beginning it's something that we talked a lot about in the the last three you know two to three years if not longer and I felt it's been like sleeping what's the you know what's the expression it's been like sleeping for a while and so I don't feel like we've ever resolved this thing and I feel it would be good to try and get to closure on this and figure out a strategy I don't expect us to figure it out today but I do think we should continue to have the debate because it's kind of these things which keep lingering around forever so with that I would like to invite everybody to you know to ask questions and to take you have to come to the mic because they're they're recording the session and they're going to share the session so I want to thank you for inadvertently bringing up the chief problem with the small core discussion which is that it means two different things and people keep confusing them and I think without realizing it you've done that here as well which is there's the question of how much functionality lives in core how many lines of code are in core how many modules are in core and by in core I mean in the dupal dot tar dot GZ file that you download separate from that is the question of architecturally how dependent are those modules in core you know every module that ships with core that you cannot disable is architecturally a liability the fact that it ships in that tar ball is completely separate from the fact that core doesn't work without it and you know one of the reasons why I never got into the small core debates when that was still raging was people kept confusing that and anytime someone said small core someone say oh so we're about modules and it's a completely separate question I absolutely agree that we need to have better separation between frameworky type functionality and application type functionality you know your previous slide you had some modules that were in the core part of the block diagram and some that were not the fact that those modules are in core at the architecture architectural and code level need to be completely incidental at that point which ones we ship in the default distribution that happens to be triple dot tar dot GZ is a completely separate question and should be answered separately I think we need to be careful to treat those as separate questions because we confuse them for three years and that's why nothing ever happened with it good point and that was Larry by the way for the recording and maybe mentioned your name so if people listen to the recording they know we was talking hi I'm Evan Larry actually kind of hit on what I was going to say that for me I don't think that the small core versus large core thing I don't think that those two things are mutually exclusive as a developer what I really care about isn't how much stuff is in core when I download it it's how much stuff gets loaded on every request so how much stuff get loaded yeah how much stuff gets actually loaded on every request so I don't care if core has a whole lot of things if if core is configurable enough that I can either remove those things completely or just disable them or if if you know bootstrap has been I guess reorganized enough which though you know the whisky initiative and the CMI initiative are both going pretty good ways to making that possible if those things that aren't able just only get loaded on the requests where they're needed and I don't really care so much anymore so that's we're talking about performance after all but you're right though but it's not I mean like most bigger Drupal sites of like a hundred modules installed right so I'm not sure I mean I think it's a great point but it also feels like a separate discussion I would I would say hi I'm Kerry Gordon and Larry of course pretty much hit on everything almost everything I have to say but I just want to spend a bit and a couple things I believe that you're actually almost on both sides of this issue in terms of what's in the tire ball and what isn't I mean I that that was the essence of my question is why does why do all these things have to be in the tire ball when we have so many great mechanisms for bringing them in on demand I mean I'm assuming that everyone who loads Drupal is on the internet so so I sort of feel that way also I think that we really get caught up a lot in semantics we use things like framework as a shortcut or shorthand for a lot of other things I think we really have to be mindful of that because it's a slippery slope I mean we're not going to be symphony we we don't want to be symphony all right fair point was there a question in that no just a comment right you don't have to have a question it's good to share your view point I wasn't sure if there was a question for me so this is so much is oh yeah so I'm CA Jackson case so this was so much in the ad that I actually have submitted my opinion on this as a core issue yesterday can you open can you open Drupal org node one four nine two nine one six for me on the projector could you say that number again because one four nine one four nine two nine one six two nine one six yep oh let's scroll down just a little bit we're getting there yep this one yep scroll down a little so awesome so what's in here and all is that all I think it's a great idea it's a sign to me even was this after midnight or before amazingly was at 5 p.m. all right very funny anything else you wanted to add all right this is John Alvin Wilkins I'm the jubilee mobile initiative lead and I missed a bunch of the intro to this because I was talking to Luke rublesky and trying to pick his brain as long as as possible while he was here the question that I asked him was you know given the importance of mobile in as far as they're going to be more mobile users and desktop users in just a couple of years and and also given that Drupal 8 is going to be really sometime next year fingers crossed and Drupal 9 would be a good like 2016 away I asked him what are the important features that a CMS should have which diamond in a little bit because he hadn't thought about it but the first two things out of his mouth before he sort of punted is that asked me later we're flexible rendering and optimizations which I optimizations meaning friend and performance all the assets of stuff in an additional in addition HTML HTML optimization could you sort of talk about what you think are the super critical things that as a community we should all work together because there's all these initiatives that are out there but it's not like there are assigned people to do all that work already right let's see it's a couple of things you know the initiatives are what's the right word the initiatives are like strategic initiatives things that we need to work on and what the initiatives that the initiative structure provides in my mind is you know some visibility for the outside world to you know what we're focused on you know what some of the big new things will be in the next version of Drupal and we assigned an initiative leads to you know to delegate you know leadership and authority in a way right at the same time it's you know two things it's not the initiative lead doing all the work the initiative lead is a leader that rallies a lot of other people I think that's one common misunderstanding you know when they see your picture John up on the on the screen in on the keynote sometimes people say oh you know John is taking care of all the work which is not the case and it shouldn't be the case right and so people should get involved with these initiatives at the same time a second point would be there's a lot of other things which are not official initiatives and we need to work on these things as well right I could make a performance initiative I could make some of these other initiatives but I don't think we have to because I think we all know and understand they're important and I think we work on them and well I would like to point out that the front end performance actually I you know when I was talking about the Drupal a mobile initiative and what it should include I absolutely wanted that inside the initiative scope all right because of how important I felt it was and I also know that flexible rendering is part of the web services and the blocks everywhere initiatives so I was somewhat slightly validated by his by his Luke's response but I'm hoping that that everyone here recognizes that those those are the couple things that that Luke thought were really important for a CMS and I would love for everybody to help build those features that are part of initiatives right and I could see a front end performance being an initiative because it's it's bigger it's a good chunk of work that involves many different things right and I think it also it also communicates a focus right so I think you know it's worthy to talk about that so right Peter hey this is Peter Willanen three questions so to me your last lieutenant model essentially is small core plus a default distribution is a really technically any difference is there is there a technical difference between what you call the tenant model and really just saying we're having small core and we're having a default distribution so it's a good question depending on what definition you apply you know I think I don't know that answers our question but I think what I want like to do and this is why it's very much a discussion because I haven't finalized my thinking is I think there's a timing element here as well like you know what do we want to do in Drupal 8 and what do you want to do in Drupal 9 I think Drupal 8 we're already doing so much right now with these initiatives and you know I'd like to launch a few more initiatives as I mentioned which really means adding more to core the lieutenant model I think is interesting but you know I'm not overly excited to implement that right away given again all the stuff we're already doing so in my mind maybe that's more of a thing which is on the table for us to talk about and to start planning but maybe we don't implement that until you know after Drupal 8 or until you know Drupal 8 is pretty close you know I don't know what the exact timing is but I don't want to like you know change things midway of a development cycle necessarily so I don't know it doesn't necessarily address your question I think but I did want to give that perspective especially because I don't necessarily have the answer to your question okay different topic in terms of initiative leads have you thought about reframing those because I feel like there's a real problem in terminology and in you know person power that the you know the initiative lead should really be called something like you know technical architects or something and they need a project manager you know speaking for myself I wouldn't even take on the role that you're offering right now as part as a you know initiative lead because I'm not great at rounding up people and managing their work and getting them to contribute patches and I feel like you know we've currently we've put those two responsibilities all on a single person and and those people aren't should really have us like a project manager that works with them and they should it should be really clear that they're not supposed to be necessarily writing the code and so I hope you know I'd encourage you to look at sort of changing the framing of this and recruiting sort of project managers for those initiatives I think it's a good point I think we've discussed terminology in the past and maybe there's better words to describe what they are so that people have better expectations of what they're doing at the same time I can also see us instead of having one initiative you know lead having it you know like a small team of you know two or three people that head up the initiative where one could provide the technical leadership one could provide the project management or the coordination and you know in some cases maybe a third person would head up the usability piece of the initiative so I think evolving our thoughts and the way we approach these things based on what we've learned is a is a very good idea so and a last quick question I've seen in line editing as a emphasis a couple times from you and I was just wondering where that came from because I don't remember hearing about it or hearing any finding that that was something the Drupal was really lacking so in line editing is kind of a bigger word for improving the the altering experience partly through in line editing but also more drag and drop like the ability to drag elements on the page so it's really much more I mean that in my mind is all in line editing where it came from is frankly you know looking at competitors they all have it and if you look at when Drupal loses against you know other CMS's that's often a reason why because we don't have it and we don't even have it as contribute modules right I guess I've heard that about more about layouts and actually heard the opposite that people are frustrated by our competitors where they're forced to edit like the text in line you know so they would they want a you know sort of coherent full page to author but you know they want to do the drag and drop for layouts so I can really comment on that specific example but morning trees what's your name my name is Mike Wacker and I had a question about the 99% more specifically that 99% we never hear back obviously we can have module usage usage statistics was kind of give us an idea of which modules might be in core and which might be contribute is there any way we can kind of enhance that data collection like maybe we know what the average number of roles the site uses or maybe if like a core module can be split into like several parts we kind of measure which parts are being used which parts aren't being used so that when we have these discussions they're just being a grand philosophical discussion from the one person in here we kind of have more data from the 99% which we can use to drive our decision-making right I think it's a great idea frankly I'm a bit of a data geek myself and I think we have a lot of data I don't think we really use the data well right now I mean we do some stuff with the data but we could do much more like you know statistical analysis to see what modules are being used together I mean we could through just statistics we could almost automatically define distributions based on actual you know usage patterns of modules so that's one thing and the other thing is what you said like getting more data 2D2D would be helpful you know on a much smaller level so but I think you know it as always it takes somebody to step up and sort of rally the troops and you know to work on it but I would I mean I think the Drupal community in general is very very data driven like whenever we have data we tend to make decisions faster I mean much faster because we don't need to build consensus because we just have the data so anything along those lines is really super helpful I'm Jess XJM and my question is so the problem with the lieutenant model model for Colger Cardinals I think there's kind of there's two things that could be problematic one is just in terms of the sheer number of lines of code and the question of consistency across the different like lieutenants domains but then the other question is how much it is just our tools and our workflow now how much of that is just focused around the core queue and could we how much could we do to make that model that model possible using the tools that we don't have yet right well do you have suggestions no I I'm asking it's a good question I don't necessarily the answers but that's I mean these are the questions I think when I say I'm not ready to implement this right now these are the kind of questions I think we need to sort through right we need to have a good idea of what we want to do and how we want to change things and like there's another element is it's much more political I think there's a real risk to get you know a lot more political as well which is something that I don't like I you know I wouldn't like to work in a highly political environment but you know imagine we pull in a module the maintainer goes you know missing an action or whatever what do we do like you know do I fire that person I mean and I mean it's very some of these dynamics are very hard so there's a social aspects in addition to just the tools and I think what you were getting to is you know some of the social aspects maybe we can solve two technical solutions but there will be a lot of social things left Angie I'm Angela Byron or web chick on juba.org and I just wanted to touch on a few different things that have come up I mean I guess the first thing is it be cool if he could try to stay on topic a little bit like and because I know the semantics are important of this debate but I think a lot more important is that like we're at a crossroads right now it feels like it where you know core evolves too slowly to be useful to people and so we depend on all these contributed projects but then if you take someone new to Drupal and you say oh Drupal is great because there's 16,000 modules you just have to pick the three of them that don't suck yay I mean it's not that actually is terrible I mean it's it makes Drupal extremely hard to use it makes it you know it really hurts us especially when you know you look at the trends of you know the the content areas of the victims of Drupal are saying have a much louder voice than the IT departments and what you know things get chosen and even if you get out of companies hobbyists do the same thing they download WordPress they download Drupal and they download whatever and they try them all and they say that one does what I want in five seconds I'm gonna use that one so we have a real problem with getting new people into the community because of this issue so the thing that's interesting about the lieutenant model is that what I hear I mean I'm in the ground with all of these folks who work on core and you know what I hear a lot of frustration around is I hear a lot of frustration about bike sheds I hear a lot of awesome code it's it's it can be soul sucking especially if you're working on something that it feels like no one else cares about either because they can't find the thing you're working on or because you don't have a process for you know coming to core office hours and talking about it or that kind of thing so it's an interesting direction for us to think about but I agree that the social impacts of that are really important because right now we have one team that has a really widespread in terms of you know what we do we have accessibilities expertise we have usability expertise documentation translation core developers all these different subsistence maintenance and a lot of crossover that happens there and I think that's what makes Drupal so strong and so you know deciding where that line falls of where you know we do put whizzy wig and core actually but we don't put views in core maybe I don't know I think discussing those kinds of nuances are really important and then two other things is someone suggested pms for Drupal 8 initiative leads we actually have done that and we should give a shout out to Melissa Anderson Shannon vets and Chris Strahl and they have spent a great deal of time working with the initiatives trying to combat some of these issues like how do I get people into my issues how do I you know evangelize what I'm doing how do I make it clear to them that you know I'm not the only person working on this and we're still figuring this out right initiatives were brand new last year we're still figuring all the processes but I just want to make clear that it is a larger team that's helping to support them and I think that's everything oh and if you're interested in Drupal that org improvements you can come to my talk later this afternoon balsets thank you I am Frank Kerry one of the concerns for me I think maybe others is the release cycle time for core I think we're bringing we're trying to bring it down but it'd be interesting if we could bring it down even further things are with mobile going on things are moving even more quickly than they were a few years ago so for me that's one of the major concerns I'm wondering you know in the new model is that a priority of trying to get that down or is a kind of 18 months that's been put out there so it's a real worry of me as well and I agree I would like to figure out ways to reduce the release cycle time as well so a couple of things first of all we've loosened up some of the rules in terms of backport policy what that gives us is that we can do a little bit more innovation within a stable branch that I mean that's a small win but obviously doesn't address the fundamental issue I think I think this is a big topic and I think it's something that where I would be open to make bigger changes probably not in eight because we've already I mean we've already developed on eight for a year so it's kind of hard to make changes now but you know say in Drupal 9 you know we could try just like we experiment with initiatives we could experiment with a different strategy around backwards compatibility for example and I don't have the answers by the way I'm just I'm just saying like I would be open to have that conversation and I would be willing to to make a decision there and you know one possible model would be I think it's Ubuntu or sorry it's Python so what they do is they maintain backwards compatibility for one release right and so it gives us I'm not saying that's the right approach but just something for us to think about what that gives us is some backwards compatibility so if you install Drupal 9 all of the Drupal 8 modules would still work Drupal 7 modules wouldn't work and then that gives module maintainers one full release cycle to upgrade to the new APIs because then the old APIs will be deprecated it puts a lot more work on the core developers again so that's that's the real I mean that's a downside and it's a big one because you know they're already super busy and they don't necessarily want to take on that work I mean they can't but imagine a world where we would be able to maintain backwards compatibility for one release cycle we may be able to shorten the release cycle length as well and because and we would be able to because we wouldn't break all of the contributed modules every six months or every year so I think there is you know it's always going to be a give and take but I think there may be experiments which we could do and again I don't think we can do them right now because you know we can go and say we're going to maintain backwards compatibility because then we would need to go back in history and you know write this huge compatibility layer for all of the changes we've already made which is going to be impossible at this point but again big conversation I think we need to have that conversation and I think we you know maybe we keep everything as it is maybe we don't but it is a big fear of mine because I think our ability to innovate is critical and shortening the release cycle will allow us to go faster because people will be more in sense you know more incentive to contribute because they don't need to like you know wait two years for they can actually use their own contributions so I think there's real reasons to do it the the hard part is the implementation so I mean what a model more I guess that you brought up a boon to you know where you kind of have a Linux kernel and additional pieces on top of that like in my mind you'd have almost like a core core right and it one it's less to work on it you can iterate on it faster and we already have this kind of model where Drupal a major Drupal version gets done then contrib picks up at that point effectively or maybe suit soon towards the end of it but like for feature feature freezes what December so it seems to like if all the focus even for like usability and stuff like that or before we get to usability it's like focusing on the core bits like we're doing whiskey and such early on in the life cycle call that complete at some point and then work on the more product deep pieces as like a separate you know separate phase even yeah it's a good point all right so we have 15 minutes left so I'm gonna limit you guys to one question a person because there is people in line for like 30 minutes that okay that's fine I'm Andrew Jewish I guess I wanted to kind of sparkle that I think this really is a it's a social problem it's that I don't really think it's relevant how much code we download the problem is who maintains it and speaking as someone that worked really hard to get a couple of modules pushed in the core so I could never ever look at them again and then totally abandoned core I'm guilty of that but and I think a lot of people it's like you kind of work on something and you're really sort of passionate about it and you want to get it into core because you want everyone to use it and then you're so burned out by the time that happens that you know it's kind of like see on the other side and so I think I think that's kind of the aspect is then now that's foisted on everyone else and then they're responsible for it and I think it's that's the important part of discussion more than what code is downloaded and executed by PHP because it's easier to get a faster computer it's harder to get a bigger development community I agree we're very well said I think as we get bigger by nature we'll get slower in terms of how we work together so we need to read keep keep making changes to the way we work it's often it's too painful to get something in core sometimes for the right reasons sometimes it just because we kept adding rules and rules and rules and sometimes I feel like we have way too many small little rules like sometimes I feel we're way too strict when it comes to coding conventions for example like other things which we could do is is like sometimes issues get sidetracked by coding conventions all the way in the beginning so you know one idea would be to have like architectural discussions first and then you know get sign of on the architecture and then only then allow people to comment on the smaller bits and pieces these are things which we could enable by making some changes to project module so but you know streamlining the way we work trying to put more focus on the right process I guess will help to some extent so part of the social problems I think we can engineer solutions for but obviously not all of them right I'm James Gelland I'm necklindle on Drupal.org actually a lot of us said was the discussion that just came out but I'll add to it a little bit but also on top of Angie's talk right before that from one to two Sam's having a boff discussing get workflows and what we can do with get and how that can so it's kind of similar to her talk and it's in the boff area so if you're interested in that that's another thing so a long time ago Drupal 5 I kind of decided I was gonna help with core and you know did some patches and it totally burned me out and I walked away from it until just now recently and what brought me back is that we have actually already moved to somewhat of a lieutenant model we have initiative leads or lie lieutenants so we're already kind of moving that direction we're just figuring out where we are and how to do that and I think it's It's been really huge to have that because it's allowed me to become part of that architectural process of designing things and help with the patch, but also a big problem with, and this came up in, I can't remember which core conversation it was, but somebody mentioned that if they wanted to change comment module, they couldn't just make a patch and put it out there and have it happen. You have to get some, you have to get a group behind you to get some sort of momentum to get that patch through the whole process of the issue queue because it is daunting. And when in the initiative you have that group, you have somebody, a group that you can build consensus with and when you get to the issue queue, you have something that you can discuss and people that are there with you working on that, and that's been really huge, at least for me, and I think that's something we can learn from. Great. Thank you. So, I'm Chris Vanderwater, Eclipse GC. I'm the Blocks and Layouts Everywhere initiative owner. I like John Blocked in a little late, and what I got was, let's build an install profile where we can play with user interface stuff to see where core might should go. Do you have some notion of where you'd like to start? Like is there maybe an existing install profile that you'd like to maybe just steal and start working from? Not yet. I do need to do some research, but I would like to, for Phoenix, right? Or? Just in general. Just in general. No. Not really. Okay. I mean, it's something that I want to, you know. So it's ridiculously new, but Panopoli has been also really impressive and given kind of where Drupalate's going, it might be a good place to at least look at. And then I'll just, I'll make one comment about initiative owners and walk away here. But I've been telling everybody that I work with, you know, don't worry about what is going to happen once we hit the issue queue. It's my job to take care of that. That's why I'm the initiative owner. You know, just work hard on this stuff and I'll go to bat for you. And I think like that's really, I think that's the message that we want to be sending as initiative owners. Like we all know that there's going to be some architecture debate and there are going to be some bike sheds and things like that, but really like when I accepted the position of initiative owner, it was, it was, I'm willing to take those things on in order to have people come behind me and, you know, really build awesome stuff and go to bat for that awesome stuff. So I think like, yeah, as much as initiative owners need project managers and as much as initiative owners need people coming in and helping them work, you know, we might be able to garner an awful lot of support by saying, you don't need to worry about the core process for getting this in. That's my job. Just get on board and help me build it. And I think we could all probably benefit from that. So, great comments. Okay, short on manless or a natrack, just to get back to the small core, big core debate, I'd rather just have a smarter core because right now I need to use a feed parser for something. And then I have to load all of aggregator module and it adds a bunch of stuff I don't want. I just want that feed parser. So what I want to see for core is to separate the APIs and the actual back end stuff from the front end stuff better so that you have that division and then I can take the feed parser, I can add my own sort of front end to that and work on that same for like pole module and all these other sort of controversial modules in core because they have useful bits. It's just you don't necessarily want the whole package when you just want that one little component. And I think that's where we're headed with symphony and the auto loaders and stuff. But I just, you know, that's what I want from core. Excellent, cool. So by the way, I need to do this. How many people know Ksertan? Very few people, but what you should know is that he offered the shared hosting server on which I ran, you know, Drop.org and Drupal.org. And he's also a user too on DDoDo. And he's been gone for a while. But what I just heard is that he's back. Also he was a core, he was also a core committer so I suppose of you know. Yeah, I'm Neil Hastings at Indie Tech Cook on Drupal.org. I'm pretty active in the contrib space but I'm trying to get into core development for a while and everyone knows the barrier is in there. What Chris said earlier, that's awesome. Not having, not someone like me having to worry about that entire political process about getting a major change in. I feel like I can actually make a difference instead of, I feel like I have to spend hours at night away from my family fighting in an issues queue. That's different when I was originally coming up here to talk about. I did have ideas around making the kind of more efficiency around the core process as far as the sub-modules, the STUB systems are concerned. When we, as we're starting to decouple these systems in aid which is working great, we can start moving these to sub-repositories in Git and have the initiative owners or the sub-system owners have commit access to there so we're not held up on two or three people on one project. It's actually a pretty common model. Many open source projects use something like that. We know Symphony uses the whole Git components. So I'm wondering your thoughts on that and I wanted two questions starting with a sub-question. With the rumors of GitHub offering Drupal free hosting, I'm wondering why we turned that down. That's the two. Okay, thank you. All right, so I didn't know about the rumors. So the first question was about giving more commit access, right? So in my mind, it's never really been about the commit access. You know, I'm happy to pull in bigger patches, bigger changes, but I still think it's valuable that there is relatively few people that can act as the gatekeepers for the code. But at the same time, like not everything needs to get to me as a micro patch. Like I would be happy, you know, Greg is at the mic, but I would be happy to pull like, you know, a 300K patch from Greg. And the commit only takes, you know, 30 seconds. So, you know, and the GitHub thing, you know, I'm gonna table that question if that's okay. I don't know the details there, but I'm sure some other people do. Greg Dunlap, I'm a hay rocker on the internet. So I, you know, a lot of these talks, you know, especially as core grows and a lot of the frustrations that I hear from people that have been here and in discussions like Randy Faye did one on governance yesterday that was touching on these issues are really about how we scale as a community as Drupal gets bigger. And, you know, a lot of our frustrations that I see in the core community, like things like I don't wanna maintain features that I don't use are really about the fact that we don't have enough core people to maintain them. But if we grow the number of core people to a point where we have, you know, 2,000, 3,000 core people, that introduces its own set of problems too. And, you know, that's part of the problem with bike sheds right now is that we have so many people with disparate interests that talk about things. And so I'm just sort of wondering what your thoughts are about not necessarily, well, maybe from a technical or a social aspect from how we scale the community to grow to 5,000, 10,000 developers, you know, the initiative leads were obviously part of that because I always view this as just being basically project managers. But more, if you're interested, if you've talked about more formalized structure, I mean the commit access is part of that too. Any ideas or thoughts that you're thinking about exploring about that right now? Yeah, so I think we do need to scale the core team. I really do. You know, I think what's happening, if you look at comparable projects, as they get bigger, as we get bigger, I think we are formalizing more things. We're institutionalizing the way we work. In most other open source projects that also meant more people because the complexity increases at the same time. And that's a challenge, right? So you need more people that can work in a more complex environment, which is kind of at odds with each other. It's just like a growing company really in a lot of ways. Yeah, so you need to put in place more processes, more structure, but ultimately what happens in, or what happened in other open source projects is there's also people that started to work full time on just core because the complexity became too much for casual hobbyists to get involved in. And so if you look at Linux, for example, the kernel is pretty much maintained by people that are paid by various organizations, IBM, Red Hat, and others to build, to develop the core of the Linux kernel. And so if we want to scale Drupal by a factor of them, I think what we do need to do is we need to encourage the Drupal shops, all of them, or many of them, to put people to work on core full time. And we need to encourage them to do so because it's the only, I think, truly scalable way. It's the only approach which, in the long term, I'm not talking about tomorrow, but I'm talking about a world five to 10 years from now where the world is much more complex. It's the only way to keep up with the pace of the web. We need to move faster, so. Have you looked at sort of the opposite model is more like the Mozilla Foundation where they've got that non-profit that funds the development? Have you ever thought about taking the DA in that direction or? I have, actually. And I think there's ways to, and I'm working on an initiative to try and get the larger end users of Drupal to put money into a pool, if you will, and sort of some sort of funds which we can then use to fix important issues in Drupal core. So, whether that will work or not. It's, and I'll be. If any of you big corporations are in this room, go talk to trees after this. It's code names. Thanks a lot. It's code, I mean, I'll be talking about this more, but the code name is large scale Drupal, which is summarized as LSD. Hi, I'm Shannon Asvatos on the intertubes. I just had a question about Phoenix. I hope I'm not getting too off topic and if I am, then table it. But I was just wondering who's working on that and where can we read some more about it? Right, so it's, nobody's working on it right now. But I hope to work on this myself with the help of a number of people at Acquia as well as anyone else that wants to get involved. And think of it as an experiment. What I would like to do there is maybe identify the top five or top 10 user improvements, user authoring experience improvements and try and add them on top of Drupal 7, right? With the idea, again, to show all of you and the rest of the world what Drupal 8 or Drupal 7 could look like in terms of usability for people that enter content. I don't want to make it giant. I just want to make it a relatively small distribution with just showcase, just to showcase a handful or a dozen of really great improvements. Such that we can hopefully, hopefully people will rally around them and say, actually this needs to be in core. And I think it's a different way of doing things. Like if you look at Drupal 7 and D7 UX, we sort of started out with, here is a screenshot. And it was hard to convince people that it would actually make things better. But it did, even though there's still people skeptical. You know, the reason Drupal 7 has grown so fast is because things like overlay, frankly, these kinds of usability things. But one of the things that worked really well in my mind was the vertical tabs stuff. Like there was a module for 7 or there was a prototype and all of a sudden I felt like people could see the value. They got excited because they could play with it. And so Phoenix in my mind is just an experimental playground to play with some of these things and make it easy for people to see what we could do. And then obviously to go to the regular community process as whether we think this makes sense to be included in core or whether this belongs in a Contribute Module. So I hope to be working on this with like three, four people. They may be working on this full time for a while. And then hopefully people from the community. And I think if we're successful, I think people all around may start from Phoenix when they need to build a website that needs to be used by people that spend several hours a day entering content just like people would start with PressFlow when they needed to build a website that needed to scale. So that's a little bit division. And again, it's experimental but I think it could work well. So we have time for maybe, if we go fast, maybe three questions. If not, I'll have to cut it off. Okay, hi, I'm Lucas. I was one of the two people that didn't raise their hand when you asked if I'm a Drupal developer because in fact I'm a Symphony II developer and I wanna just bring a little bit of an outside perspective or how we do things. So we have, as Fabian explained yesterday, we have the components and then we have a full stack framework. And so for components, some of them have other developers that are sort of nodding off the pull requests even though Fabian in the end is a person that merges them. But on the full stack framework, we actually pull in a lot of third party dependencies like aesthetic for asset management, monologue for logging, doctrine for annotations and ORM and all that stuff. And so when we do a release, we have the standard distribution where we basically take the latest stable versions of all of these. It also includes some bundles which is our lingo for modules. And then we put that together and that's then the next version that we put out. So it's similar, I guess, for the lieutenant with a small core approach. And I think for us that so far has worked well but also we are still very young so we can't say that this is a mature model that has worked for decades either. Great, thank you. I think we can always learn from other projects, right? So we should. I'm John O. Schuster and I was intrigued by an earlier comment about the need for better data about what parts of Drupal are used in websites. I'm willing to put my shoulder to that wheel a bit if there's anybody who would like to join me in a discussion on that topic, catch me after the meeting. And I assume it's a real needry, so if anybody wants to take that on with me I'd be happy to put my shoulder to that wheel. Great, thank you. One more question. It's about the initiatives. I have some minor comments to do. Currently the initiatives are getting some mergers into AppStream Core and but I'm asking me myself if are they really following the way that Core is developing? I mean, I know that initiatives are one of the exploring approaches to help development following the Nintendo model which gives more flexibility but in my opinion they should also try to follow the Drupal Core usual way of development. I mean, for example, they are not really using the issue queue for communication. For example, the recently mergers from one of the initiatives, they don't really have the readable look history. So for people that are not really involved with the initiatives it's pretty hard to actually follow the development of Drupal if they are not inside the initiatives. If I think it would be great if they can rework a little the history before Merge because it's pretty hard for people outside initiatives actually to follow the development of all development. I think these are valid points. I think initiatives are new. We've never really done this before. I think in many ways we're still in the sort of formation stage. Each of the initiatives are run slightly different and I think we're learning what works and what doesn't work and I feel like people are starting to standardize a little bit more than maybe in the beginning on one approach which has proven to work. Communication is a big issue which we talk about a lot. We understand we need to provide better visibility into the progress of each of these initiatives with the goal to get more people in so they can help. So cool. So I thought this went great. There was a lot of people asking questions which is awesome. As always I think it's great that we spend time talking about these things and I wanted to reassure you guys that I'm very much open to discuss these things and as always I think I'm also open to making changes. I think that's the only way for us to be successful. At the same time I think, although it may sound like we have big issues in front of us and we do, I think we should also remember that we have made a lot of changes already and that we are doing extremely well. One of the great things about us core developers is we're always critical. We're always unhappy in a way, right? It's like we released Drupal 7, we have a big party, actually, 350 parties all around the world and the next day we're grumpy again because it could have been better, you know? And in many ways that's great and we should foster that at the same time. I think Drupal Const and other events are great opportunities to also recognize all of the success that we have and the fact that we're doing many things right. So if you're in the audience and you're starting to freak out because of all of the issues that we need to solve, take a step back once in a while and realize that things are actually going extremely well despite the fact that we all want to make things better as well. So with that, I would like to say thank you for participating and attending and hope to see you around. Thank you. Thank you.