 Wow, there's a lot of people in here. How is everyone's Drupalcon so far? It's five! Don't ask me to exhibit enthusiasm at five. There's two more premium seats in the front. Yeah. If somebody's looking for it. Extra leg room? They have extra leg room. They have power. And there's a table. Like, it still is like. Of course, you will have to pay us $300 apiece in order to sit on it. Although you may become an initiative lead if you sit there, so. Also, if there is an emergency, we're going to ask you to open that door. Yeah, there are. There's like seats, boom, boom, boom, boom, boom. So you don't have to. There's more in there. We very rarely bite, only in special circumstances. Only when we're booked. And we got about two minutes. Although, a lot of people here. So we get a few slides, but our intention here is to talk through them pretty quickly. Hopefully not too quickly. And then leave lots of time for talky bits at this. Because the idea is this is a core conversation. And so we'd love to get your thoughts and ideas on everything that we talk about. The other thing I want to stress is what we're going to present here is just a proposal about making proposals, meta. And so none of this is set in stone. This is just some conversations that Gabor and I have been having with various folks like core committers and UX maintainers and these sorts of people just to try and get some things addressed. OK, shall we hit it? So this is the potential in Drupal 8 and how to realize it. And we've been thinking about how to frame this conversation. And we should stay on the line. So this is NG Byron. And I am Gabor Hoichi. And both of us work in the office of the CTO with Dries at Acquia. And both of our work in the Drupal community predates that several years. So we've been working on all kinds of crazy things. And I think we are both very passionate about making stuff happen in Drupal and both the hard way and the even harder way. Because we still need to figure out the easy way. So that's why we are here today. And this is a core conversation once again. So we'll present some stuff. And then we should talk. And then I'll put back the mic once we don't need two of the mics anymore. So the first thing that we wanted to talk about is Drupal 8. There's finally new possibilities that were never there before. So if you've been involved in Drupal 8's development, we spent four and a half years working on a new thing. And there was two totally divergent code phases in Drupal 7 and Drupal 8. And what you worked on in Drupal 8 was not possible to reuse in Drupal 7. And there were a lot of those problems there. But what we worked out instead now is now you can make big changes in Drupal 8. How? Oh. So Drupal 8 adopted semantic versioning, which the simplest way to explain is now our version numbers make sense and our version numbers allow to make changes that we used to not allow culturally before. So basically the semantic versioning number scheme that Drupal adopted means that the first number in our version number 8 will change if we need to make backwards incompatible API changes in Drupal. However, most things are possible to do without making those backwards incompatible API changes. So we can still introduce new APIs and introduce new features by incrementing the second version number. And we can make fixes by incrementing the third version number, the patch version number. So this is major, minor, and patch. I think it may be confusing at first because in the minor versions we can actually introduce huge changes. But it's a minor version. So huge changes in terms of user experience, but it was still called a minor version. That's how semantic versioning calls it. It's not something we made up. It's how semantic versioning calls it. And the other thing that we adopted is scheduled releases. So we now have new minor releases about twice a year. And then we stopped supporting the previous one. So what you see there is we are in the middle of approaching the middle of May and we are not supporting Drupal 8.0 anymore. So if you have a Drupal 8.0 site, you're not gonna get updates to that anymore. However, we now have 8.1 and we support 8.1 until there's an 8.2, et cetera. So we have timed releases and we actually made our 8.1 the first time release on the date scheduled, first time in history. Woo-hoo! So it's certainly possible to do. So Drupal 8.0 has a lot more potential in there than previous versions because we now culturally accepted this that we now are gonna make big changes that are backwards compatible still. Yeah, so what does it help with? So for one thing, it's predictable in terms of what you work on, what can you get into new versions? Like there's rules to what's possible to do. It's also predictable in terms of any new versions coming out. So if you work on something and it's committed to core, then you could be sure that it's gonna be released at X time and it's not like maybe in two years or three years or four years or some time. That's not a problem anymore. Also, there are improvements coming every six months. So if you're a user, you can expect that Drupal is gonna improve in several ways twice a year. And we hope this incentivizes contribution a lot because now if you do something, you don't need to wait four years for your customers to use it and you don't need to wait four years for other companies to contribute to what you worked on and fix issues there and build on that as well. So it incentivizes you to work on core issues instead of just going into your own corner and figure out something one off for your customers. And it's also backwards compatible, so it's easy to adopt these new changes. You can hop on the new version and start using it. Yeah, the only other thing I'd add there is, is even though the releases come out every six months, they get committed basically every day. So if you're launching a Drupal 8 site till after October, there's no reason you would use 8.1 right now at all. Just use the 8.2 dev branch essentially and you can get these improvements as they filter in and test them actively as it's being developed. So that by the time 8.2 ships, you know it has everything that you need in it. Yeah, so the question is what to even change like what we wanna do when the new releases. So now we have all this possibility, what do we use it for? And there are two ways that we're looking at this. There's one way is the top-down things is like we should do this that come from decisions that are made for by-committers, for example. So we wanted to have a migrate user interface so that people can actually get off of Drupal 6 that we don't support anymore. So that was the top-down goal that we communicated in all kinds of posts and events and we'd rally people behind. And there's all kinds of other things like front-end testing or blocks and layouts that came from survey results, configuration management, media, workflow, et cetera. So these come from aggregated information that we see in the community and these that we believe our users have. And then there's always all kinds of great things that come up from people, from their own initiative, from their own needs, from solving their own pains. Stuff like Tweak, this was not something that was planned top-down, came as a grassroots idea and then grew out very huge and very successful. And a lot of other things like the admin style guide, picture support, the current work to make contact forms better as a basic web form solution in core, et cetera. So these all come from the community and that's very valuable. And both of them are very useful for making changes in Drupal Core. So, Angie created a page. Like six days ago. Six days ago called Drupal.org slash core slash roadmap. Ooh, that's the big word. So, so Drupal, so we used to part ourselves for years of not having a roadmap. But once we kind of want to say what to focus on, we want to have plans. We want to have budgets. We want to have teams. It's kind of hard to say we don't have a roadmap. Um. Tell you what, you pay us lots of money to work for an unknown period of time on something with unmanageable scope for no payback whatsoever on an unknown timeline. Like would you sign up for that? Probably not, which is why Aquia tends to be the only suckers who sign up for that. So we want to like diversify this and let lots of people do things. And that's kind of the point of the talk. Yeah, no. So, so we set up this page to have a place to figure out what are these things. So like we just had two slides. I told you about things, but a week from now there's going to be sprints here. People are going to decide on new initiatives they want to work on. We're going to make plans for some of the initiatives and you want to track what's available and what you can work on and what you can join. So this page is for you. So you can go there and see what's going on and what's to say to stuff different initiatives. That's the goal. But you might ask, how do we actually do that, right? How do we get changes on there? How do we not kill ourselves while we're getting changes into core? How do we actually make the most use out of the six month release cycle that we have? Because I heard from so and so that it is awful working on core and I never want to touch it with a 10 foot pole. For example, you may have heard of some of these pain points. And this is just a sampling of pain points from Drupal 7 and 8. We have a lot of bike shedding, which means a lot of like nitpicking insignificant details that don't actually matter in the long scheme of things, particularly for user facing changes. People tend to just be like, yeah, whatever if you want to make say a queue API, but if you want to change the color of the button on the node form, people have a lot of opinions about that. A lot of developers have a lot of opinions about that, even though designers are saying, but blue anyway. Even if you work really hard on something, even if you talk to people at the right times and all this kind of thing, it might still get rejected. So you could do months and months and months of work and at the end go like, ah, yeah, thanks, but no thanks. I decided to do a different direction for that, which that is scary as hell to anyone who wants to try and make something happen in core. People often get the wrong feedback at the wrong time, so you're looking for like directional or architectural feedback on your idea and instead you get like your white space and it just really is demoralizing. When we don't validate our ideas until after, they've already shipped and often after it's too late to do anything about them. We spend months and months and months going around and around on a patch in the queue, which is great for the four people who know about that issue. But when the rest of the community gets to actually try that thing, isn't till it's committed. And often if that issue got to 300 comments, everyone just walks away like very frustrated and they don't ever go back and iterate on that thing. And then after it's shipped, we're a bunch more locked down on what we can do. And then we had a lot of workflow problems, so some people went the giant core patch route, which has that pros and cons and that it's visible to the core contributors, but it is really hard to find just random issues in the queue if you don't know what's what. Sandboxes, which are great in that they're isolated, you can work a lot faster there, but they have really obscure URLs. And again, you don't get the visibility from the core committers and they might come in at the last minute and be like, what are you doing even? And there's a lot of sync up there. Doing stuff in contrib is great because people can use it right away. It's got a nice URL, but then the risk is it might stay in contrib because it never quite makes all the gauntlets that are required to get into core. And then doing things in core itself is awesome in that you get the peer review aspects, but it's very slow, and so it can be frustrating to work in there. So when we want to talk about things that we want to do to the process to improve upon those pain points, we want to do what other people do and iterate quickly and cheaply on ideas. We don't want to build big cathedrals in a patch in the issue queue. We want to get things out as quickly and cheaply as possible so that we know what's going on what. We want clear sign off points to avoid wasting time. If I'm going to be told no about my idea, I want to know that like when it's three sentences long, not after I've written a core patch and gotten the white space standards and it picked and everything, I don't want to find out my ideas bad at that point. That's really awful for people's morale. We don't want surprises, right? We don't want like the entity system maintainer not to be looped into the fact that you rewrote the entity system, right? That's not fun either. So we want to make sure that the right people know what's going on at the right time. We want to make sure committers are involved so they know what's going on because they can say no to everything. So it'd be good if they said no right away. We want to reduce barriers to entry for new ideas and also we want that clear visibility into priorities because a huge problem we had for the last six months is we did communicate some priorities but it kind of happened once at groups.drup.org core posts. So if you know that, you channel, you would have seen it probably. If you were there that week, but there was never like this central resource to find that kind of stuff. I wanted to talk briefly about what other people do when they improve products. So this is this book, The Lean Startup which everyone in the Aquia leadership team had to read. And to be honest, the author is really, he thinks highly of himself. Let's put it that way. However, it has some really good parts in it. And one of them is this thing which is basically, it's this loop that you go around where you build something, you measure it, and then you learn from what you measured. And you try and go around that loop as quickly as possible and as cheaply as possible. He has a lot of examples in the book, but the one that sticks with me is Dropbox. Like people have probably heard of Dropbox maybe. So their first version was a video and they totally MacGyvered this video. Like they had no working code, nothing, but they like shot this video like with all these like faking that things were actually happening that they wanted to do. And they just put up the video and an email signup box, that's it. And then within like a week, they had like a million signups or whatever. And that validated that their idea had promise. They were all turn around and go to a VC and say, please give us $70 billion or whatever. And they were like, sure. So that, but so instead of spending 18 months writing this thing and hoping that it had promise, they validated the idea right at the beginning. So they knew that people would think it was valuable. So trying to find cool hacks like that where we can do less work, find out that we're in a good direction and then invest the time and resources. So this is kind of what Gabor, Yoroi, Boyan and I have come up with sort of incorporating some of that lean UX methodology, but then also taking into consideration that we're a community, people flitted in and out. We wanna maintain the volunteerism aspect of Drupal. And it goes from an idea, which generates a plan to a prototype, which generates a spec to building a thing, then you ship the thing in something called an experimental module, which I'll talk about in a second. And then you refine it a few times and then when you feel good about it again, then you go through all the core gates, like documentation, usability, accessibility, all those kinds of things. And then it goes into core as a stable module where it kind of goes into just like, we just basically maintain it at that point. We don't make radical changes anymore. So I wanna emphasize that this is just a proposal. Like this is just our ideas and it might look more fleshed out than it actually is, but these are just, I wanna kind of stimulate the conversation, so we had something to talk about. So the idea is from idea to prototype, and idea is just a few sentences. If we use lean UX here, it would be a hypothesis. We say we think that improving media support in Drupal would be a good thing to do and we will know this because whatever reason, that kind of thing. The idea is formulate your use case around an actual user. So say content authors will benefit from this because they will now be able to just click a button to add an existing media thing as opposed to opening a page and grabbing a URL and pasting that into a thing and this kind of stuff. And then you also talk about how you're gonna validate that idea that it actually works. You can get sign up for rejection on your idea right away before you've done any work. You just say, this is my idea and we go, awesome, or maybe in contrib, or whatever. But at this point you haven't invested a lot so that's a great time to get a yes or no answer. And then in order to get to the next phase, then you formulate a plan. And a plan will have things like what are the goals, what are the milestones that you wanna break that out into because we wanna kind of force people to think about that. This thing has to happen first, second, third, maybe target some release milestones for it, maybe not, but the idea is we don't want just big bullet points content workflow. That's what we're gonna have is just like what does that even mean? So it's about breaking it out and so people understand what that means, what's gonna happen and what order, so that people can look at that and say, oh, I can totally help with that thing. And that sort of stuff, so. Here's a plan template. It's kind of in beta version that Jess came up with. So it's got some of the fields, including sign offs and some other things that would be the kind of thing that you'd fill out. And I think the content workflow initiative's done this as a starting point. One thing I just wanna throw in here, this is from Yoroi's presentation earlier, but when we talk about these minimum viable products that we wanna be churning out every six months, ideally they would not be just a layer of API things that are really great if you happen to use that thing as a developer. That ideally would be something that goes up this entire pyramid because oftentimes we add APIs and then we don't actually do anything, we don't go up the pyramid at all. Like we have this great revision system in Drupal 8 that allows you to differentiate the active revision from other revisions, so you can ideally do drafts and stuff, but there's no UI for it because we just never got around to that. So ideally we would go down this slice of the pyramid and we would be putting out MVPs that also have a user facing component because we know that content authors and site builders are sort of a more important audience there. So just something to think about. When we go from prototype to build, we wanna prototype iteratively as cheaply as possible and talking like I drew this on a napkin, took a picture of it with my phone and uploaded it to the issue queue. Start there. Validate the prototype with really users so you can actually sit down with people and show them maybe walk through the thing. Once the validation occurs and people are satisfied with that, then the prototype becomes a spec and we stop talking about it until it ships. No more bike shitting at this phase. Yay! So here's some example of prototypes. People do paper prototypes. Purely HTML, JavaScript, CSS, fine. We don't do core patches at this stage because core patches have a whole lot of overhead on them. The idea is simple, manageable as possible. You can do core patches. There's nothing wrong with that I'm just saying. Idea is really cheap. Doesn't have to integrate with Drupal. This is a really scary looking slide. This is a, I'm trying to lay out our core governance process which is, you know, it's a thing. We just have a problem though where people didn't know who to talk to and then oftentimes people would be surprised or people would feel lost. We actually have a structure around this now which is kind of new in Drupal 8. So we have initiative coordinators, subsystem maintainers, topic maintainers, and committers. So this is existing as already exists? Yes. It's not a proposal. Correct. It exists currently. And then within committers and all these things you have different sort of buckets in there. So committers are product managers, framework managers, release managers, topic maintainers like testing performance documentation and so on and so forth like that. These are some of the people you may need to involve in your thing and we can work with you to help you figure out for your particular idea who needs to sign off on that but in general, if you're proposing a typo fix you don't need to talk to anybody. You just do your typo fix. If you're talking about radically changing say the node edit form which is a very user facing form that almost everyone uses then you're probably gonna have to talk to a lot of people. You're probably gonna have to talk to a committer, probably gonna have to talk to the usability maintainer, the node system maintainer, this kind of thing. So based on that. But the idea with the governance stuff is you now have a map so you know what the community looks like and you know who to talk to about your proposed changes. Let me go to build it and then we go to ship it. Now we turn that prototype into a core patch. However, we bypass either most or I would argue for all but I would probably get stabbed. So maybe just most core gates are bypassed. We don't nitpick white space, okay. We don't necessarily like slap you on the head if you don't have all the things documented and that kind of stuff. The goal is to get something workable in core as quickly as possible so that it has the visibility and people can use it but we clearly mark that thing as experimental because we know it's not ready yet. And so the benefit of this as opposed to doing something in contrib is in order to do something in tribb there needs to be visibility. So you need to know the URL to get to the page because Drupalador search sucks. So you can't actually find the views module. You have to know it's project slash views. And then if we're targeting this stuff for core it makes sense to put it in core anyway. And then people who want to be on the bleeding edge know one particular section of the modules page to check things off of and it's really nice that way. And then we open up the bike shedding on the design again after shipping it because now lots more people have tried it. We get a lot of feedback on that and we can do this even in point releases which is great. Why experimental modules over contrib or other things? The pros are that it's already in core so you don't need to go out and download a thing. It's clearly marked that it's going to be less stable so we can bend the rules that we normally have for core modules with those. You can use a familiar core process. You get to benefit from things like peer review that kind of thing. It's easy for end users to find it because it's all in one place and because they're experimental it allows us to iterate quickly. The cons are you still can't commit directly if you start a contrib module you can commit whatever you want. You do need reviewers for that thing. That's why we emphasize initiative teams as opposed to lone wolves trying to get things done. It's always best to team up with at least one other person. System wide changes are not really possible. Like it's hard to affect the entire system with just a module. And then there's risk of lingering technical debt. We did put an accessibility improvement module in a point O called inline form errors and that's just kind of set there because people kind of burnt out during the process of that and haven't ever got back to it. So there's pros and cons but in general I'm really excited about this because it allows us to keep all of our existing tools and workflows that we benefit from while also giving us the visibility and things like that that we need. And then finally this last bit. So after we've gone around that loop a few times and we feel good about this now we move it to a proper core module and here is where we make sure that every bit of that is unit tested. We make sure that all the documentation gates past the accessibility, usability, all that kind of stuff. And then we move it into core stable. At this point, the only way to make radical changes to this again is to just go through the whole loop again from scratch which is fine. We can always make a better blah, blah, blah module as an experimental module and keep going. But the idea is that that's now locked down. Improvements are no longer possible and enjoy because now you have a stable, awesome core module that does really neat stuff. Okay, so in summary, what the process, whatever it is that we come up with is intended to do is to get sign off or rejection early on in the process before you've done a whole bunch of work. We want to validate that direction with real world users before we write a bunch of code. And we want to base that on data versus just arguing with each other a lot. We want to make it cheaper, faster, easier, et cetera to improve core all around. And this experimental module paradigm lets us do that. And we do want to jump through the right hoops because we have hoops in core for reasons, security, all kinds of things. But the idea is let's jump through the right hoops at the right time. And then somewhere down the line, profit. So, hooray. Yeah, so what do you think? So we have a few prepared bullet point. These are just ideas for structuring the conversation but really we're just looking for feedback, yay, nay, horror, whatever you got for us. I'm very happy that you're thinking about this because I do think that it's been one of the sore points of development for core. But even going to the very first stage where the ideas are being discussed, I'm worried that that will get bogged down. 10 different people will have 10 different ideas and nothing will really get resolved and no particular direction will ever get chosen. And it will just sort of fester that way. Sorry, I'm trying to find that slide. There it is. You're saying right at the idea stage it could get bogged down. So the nice thing that the governance process gives us is we now have people defined with roles to be able to say whether or not things are a good idea. So even if there are heated opinions about a thing, at the end of the day a committer makes a call here. And if it's a frameworky feature then a framework manager will make the call. If it's a user facing feature then a product manager will make the call. But we have a clearly defined, and what they're gonna wanna do is they're gonna wanna let the discussion bake for a little while. Cause they're gonna wanna see what the opinions are of people. Cause sometimes people are kind of a pain in the ass but they have a good point and their feedback is still worth taking into consideration. And I think what you'd find is that, what we plan to do is set up some kind of a process like say a monthly or bi-weekly, I don't know yet, meeting where these ideas are gone through in a sequence and we validate them or invalidate them or whatever so that it's time-boxed to an extent. Because yeah, I agree with you. You don't wanna let things fester for 300 comments. That's just not a good say. So the idea is time-boxing this step and making sure there's clearly delineated decision makers for each phase of this process. Great, thank you. Yep. Also, the ideas would not come just out of the blue I think. So Drupal has some, I mean if we set high level goals for Drupal to achieve like if we wanna be API first, then if you have ideas that totally go against that then they will just not be compatible with what Drupal's goals are. So if we set some of those high level goals then a lot of those ideas will be objectively judgeable on that level. And then there's, it will be down to more of implementation details I guess in terms of how do you wanna get there? I think it would just be important to have a maintainer saying I'm sorry but no, rather than just letting it peter out and nothing ever being said. Yep. Yep. Question about the experimental module model. So I'm just thinking about like the suggestion Dries had and his keynote of wouldn't be great if you could place a block by just looking at the page and just sitting and thinking about how we would implement that like a minimum viable implementation bat would probably be great to have an experimental module. Once it works I'd just want that to be in the block module and how do you foresee as kind of iterating on these minimum viable things and then the then integrate is it gonna be possible to actually just do away with the experimental module and integrate the feature into other parts of the board? Yeah, that's a great question. We talked about this a little bit at whatever Drupal Connit was Barcelona maybe with catch and he had a great idea which was yeah so you might eventually get that experimental module to the point where it's like why would we even use the old crappy version of that? So his idea was copy and paste the old module into block underscore legacy module, put an update hook that automatically enables that module on any site that had block module enabled and then make the new block module the default for all new sites. And then promote it in the release notes as something that you can now turn on yourself. There's probably some implementation goofiness with that but in general the idea though is we wanna make it so that Drupal nine becomes just RMRF anything that's legacy and if they're intermixed it's really gonna be difficult to do that. There's some different things that are like we don't wanna get into a situation where we have a security problem and now we have to fix it at three places in the code so I don't know exactly but the idea though is we wanna make it really easy in Drupal nine when we can break BC to go ahead and do that without affecting much. So I guess yeah I was even thinking more of something that was experimental in terms of a UI or UX improvement. So it's not really a BC breaking change but it might be something you want to ship as experimental so people can try it and get that broader feedback. So do you see it as possible as like okay we're gonna overhaul or add a bunch of block UI features to the existing block market but this doesn't change the data model. It's not very candy API. Yeah I guess it would depend. Like we have to be careful with that because it will instantly invalidate all documentation and videos and everything else for Drupal eight to that point. So for something like blocks I would be a little hesitant. Like I'd rather have the like a fork you know where there's the old way and the new way but for something like you know but maybe we just are like the old block UI is honestly so terrible that everyone's gonna be fine with having out of date documentation. I think it'd be kind of a case by case thing. So there's a number of pages that I would be fine just changing it right in the module and not worry about it but block node anything that's like a major site building UI it's a little I don't know that's my personal view but other committers may disagree. Yeah there's not just an idea because in Drupal seven we have profile module that is not this hidden for you if you install Drupal seven new if you've upgraded from Drupal six then profile module is there for you to use but if you install new it's hidden. So we already did this in Drupal seven it's not a new idea and in this case we'll just like put in new shiny things into core and we'll need to figure out and I think on a case by case basis because there may be modules that extend the blocks page and provide new features and all kinds of other things that that may become incompatible and all those questions of how we define the API in terms of that. And on that note to Peter's question I'm XJN by the way I'm one of the Drupal eight release managers. We have this concept in core of disruption that we don't make disruptive changes in patch releases we make disruptive changes in minor releases carefully and conscientiously. So like whenever we talk about a big change the disrupt well any patch actually the potential disruption to all of the different use cases is something that the core committers take into account which is why being a core committer is hard and why we have so few of them compared to the breadth the contributor base because we want to make sure all those things. So we would make if we were making that change we would take really really carefully okay what are the impacts how many contrib modules APIs are completely broken if we completely relays the blocks. But we have the opportunity like Angie pointed out to do it iteratively over the course of minor releases. So we have an allowed changes page on Drupal.org that can you maybe pull this up? You have more experience but... I'm gonna mirror the screen then. All this screen typing and then we'll... Drupal.org slash core slash D eight hyphen allowed hyphen changes not that I type this URL every day. What was it I'm sorry? Drupal.org slash core slash D eight hyphen. Not T seven. Allowed hyphen changes. Just a little like throwback 2011, hey? Okay. So that's all the details. So this page goes into details about what types of changes we allow in past releases minor releases major releases as well as the beta and RC phases. And then there's a specific sub page of this under that will outline in excruciating detail whether or not your change to your markup in this in Bartek versus stable or whether this particular kind of method on this particular kind of interface and is disruptive or not and what we'll change to make about it. So it is painfully well-defined and it's so far it's working well. The problem is that it's again this is not something that you can just keep in your head unless you have to do it all the time. But it's useful and it's there as a reference. We can actually do these things. So I'm actually gonna make the point to forget who the first person who came up and made the point about at the idea phase the risk of bike shedding ideas and the fact that we need to be willing to say no in a timely fashion. We actually have an example of this in the Drupal community that's already starting to work well on the most bike sheddable possible topic which is coding standards. There is nothing more bike sheddable than coding standards. And the technical working group has I have usability maintainers contesting my assertion but the technical working group has implemented a process where on a timeframe they proposals get discussed for a little bit. They look over the proposals on like a monthly meeting and say, okay we think these proposals have enough to support to be weather for wider community discussion and then the discussions open for two weeks and then at the end of that time box they close it and they make a decision at that point. So there's I think two weeks to where you can say whatever you want and then they make a call and their call is either advanced to the next phase where it gets committer sign off and approval or they say no and the issue's closed forever and sorry your coding standard is not implemented. So that's the kind of thing that we could implement for these idea issues. We'd obviously need a process to find and surface them which is one of the pieces that's still missing like how do we get these plans into that idea phase without it being a lot of overhead. The technical working group is doing it through like they have just one issue queue that they have to worry about and all they have to do is make sure the issues come to that queue and they need about it. The corporators also meet on like a bi-weekly basis and also communicate synchronously 24 hours a day kind of but like that's the process that we would still need to develop. I'm curious do they use a separate project like a coding standards project? Yeah I was thinking of a separate like Drupal core ideas so it's like completely separate so it's very clear if it's in there don't work on it yet unless you want to take on the risk. There's benefits and cons I've got set but it's just like because otherwise I worried we'd have to come up with a tag and then that's like inscrutable to new people and I know. So anyway I was just curious how they did that. Cool. I say this looks fantastic. You want to pull up the mic? Oh yeah sure I'll. Sorry. No. So like I said I think it all looks great but have you got into thinking about how you might mitigate feature bloat? What's keeping a lot of these new things to come in? Yeah it's a good question yeah because what we could end up with is great. Now core ships with 37 experimental modules and none of them have been touched in two years. So one thing I was thinking of is in that plan issue one of the headings if it isn't already which you would know Jess but is what are the steps required to get this to a stable state? So that could be issues like finish off unit testing or whatever it is plus a milestone deadline for that. So for something like migrate UI we might want to give that to like eight five or something because that's a really critical piece of infrastructure or maybe we just don't give it a milestone and all we say even though this is kind of eh like it needs to be there so we're just gonna but a new feature like say the accessibility module that currently isn't being maintained we could set a deadline of eight two for that and we could say look if no one comes to improve this by eight two then I'm sorry it's gonna go and contrib and that's fine like it's still usable by people there's no implications for upgrade paths because it's got the same name and everything but it would allow for us to reduce scope of core to just the feature set that we want. The idea though is like we're not gonna open experimental modules for any hair brain idea anyone has like it's gotta go through an approval process that's the idea and the only things we're going to put into core most likely are gonna be things that have some kind of data to back up that these would be good core features that 60 to 80% of our site users are gonna want or are something so strategically important like big pipe I don't know that anyone would be like yeah I want that but we know that that's something really valuable that they don't know they want because they like then you tell them it's faster pages they're like oh yeah I want that you know kind of thing like that so. It's a faster core. Yeah exactly but you know so but it's a good thing that we're gonna have to manage for sure but the idea is and the other thing that Jess frequently says is we should also limit the scope per minor lease and kind of say like I'm sorry this minor release is full like we've got content workflow going we've got some media things and da da da da if you've got your cool idea feel free to work on it wherever a sandbox core patch whatever but we're gonna target it for eight three instead because eight two is bursting at the seams we don't have that problem right now I don't feel anyway so feel free to work on whatever you'd like but yeah the idea is like these things would be mostly important strategic things we don't wanna make every effing bug fix and minor thing go through this workflow the idea is this workflow is for really important things that we wanna like feature in the release notes if that makes sense so yep yeah thank you so there's one scary part here for me and that's moving the gates to the end the most scary thing is that testing is a gate and I think testing be super tests will be super important to have in this loop in the experimental phase so I'm wondering if you really mean gates here or if you mean nit picking because a lot of like criticism that stop touching the mic a lot of the criticism that I think we can get in core patches isn't actually a gate but we end up fixing it anyway because we're compulsive about things and it bothers us so I'm wondering if this is not gates at the end but like polish and if we can keep gates in the loop I don't think it's polish I mean you certainly would not like ignore the security gate it's like oh here's an experimental module it makes your site insecure we don't wanna do that intentionally definitely so I don't think it's all the gates we need to define what gates you need to meet to be like to be included but I don't think you need to meet all the gates because it's not just polish or not just nit picking I would say no yeah like maybe we could say you have to have at least some test coverage for the major things your module does but we do not need comprehensive unit testing of every effing function in there until later or something it could be minimal gates this is just a proposal but the idea is we wanna be able to get a thing if we've gone through the work of getting a prototype that's been validated and we know this is gonna make Drupal better we wanna get everything out of the way of getting in that decor as fast as possible so that we can then iterate on it and move it into proper core yeah I think test is the one gate that probably will stick around for that so there's a useful like maybe shifting our concept a little bit the I think that so there's a healthy balance that we have between the product managers like Angie and the release management who are part of like pushing back and saying well no actually we do need this functionality in order to ship a sufficiently stable experimental module because like experimental modules we will not commit stuff that will introduce data integrity problems even if it is experimental we will not commit stuff that introduces security problems so those things that would be like fundamentally critical problems we don't go there and I think that MVP test coverage is part of the requirement for getting something as a stable thing like Angie was saying to the minimum case MVP documentation you can't like have no documentation whatsoever for the thing and so it's more about but it's not also limited to the core gates there's part of creating one of these plans and what makes them effective is you have someone who's like for a big initiative owning the initiative and actively managing the scope and so when something comes up in the process of reviewing the issue if they're like we don't we're not gonna discuss this here immediately nope that's gonna be part of making stable we're removing that from the discussion here and move that to the scope of the follow up discussion put it in the later part of the plan so it's not just like a binary list it's an active process of defining especially for big changes what is really the most fundamental thing we need to do versus what work can we do later to make the work that we do now the most benefit for the lease cost so in other words what I'm hearing as in some ways we formalize so before we did commit stuff to core that was not fully baked and we said here are the follow up issues that need to be resolved and then those may or may not have been resolved at the end so in some ways we're actually formalizing that now and we're saying that you only get the stable stamp if you actually resolve those follow up issues and then whatever gets the stable stamp you can now be assured that those follow up issues were actually resolved so that's a benefit for both the quality of whatever comes with core and the users knowing what comes is good so the iterative process is awesome and you know we needed Kevin could you step a little closer to the mic? Sorry and yeah and we needed it we needed it a long time ago but I'm not sure that I might be missing the fact here but are we saying that the experimental modules only go in every six months? They will only be released every six months but they'd go in during any open development cycle so right now if we were to commit an experimental module it would go into 8.2 and then users would see that benefit immediately if they're using dev releases or in October if they're using the core releases but we do release we release security releases so we could theoretically put an experimental module if it's only experimental anyway So what we talked about is you can add you can't add or remove major functionality in a patch release because people expect patch releases to be very easy to upgrade to we need to be so people aren't scared to do security updates but oh go ahead So this is not something inflicted on us from the outside we decided to do these minor releases every six months that can introduce these new things we could decide to make new minor releases every three months but we did not believe that we can deliver enough value every three months for you to endure updating for the new minor release and so we wanted to have a minor release that is well tested enough had time for beta testing, RC releases, quality assurance, had some of these things not just as prototypes but as somewhat more baked like those kind of things and we could still get this in front of people even in the development phase we don't need to deliver them to actual customer sites right in the prototype phase that wouldn't be true It's just that six months isn't a very nimble iterative cycle That's what So we did actually discuss Kevin the proposal you're talking about we had a like over the course of like 8-1 was both developing 8-1 and developing the processes we would use for future minors and we did discuss in a lot of detail whether we could add new experimental modules in patch releases because they were experimental the compromise we settled on is we don't add new ones but we do make significant changes to experimental models that are already added every patch release So that's where the iteration comes in and that's the compromise that we came up with that balances all of the different concerns between release management and the quick innovation that's there So a new version of a current experimental module can be Every two weeks not a new experiment Exactly So for example the big pipe module right now was adding an 8-1 we wouldn't have added that in 8-0-2 even though like I think it was ready around 8-0-3 or 8-0-4 but we now if there's significant changes that need to be made to that module based on the user testing that's already happening of it if we need to make even API changes to it if the user interface needs to complete overhaul because it's causing problems we can deliver that immediately in the next patch release in 8-2 so or 8.1.2, excuse me Also I want to give some credit for what we did so we moved from 4.5 years to six months and and thank you, thank you for making that happen so so this is already a huge change so if we find this is too slow then we can further change the process later on I think it's already a pretty ambitious change compared to what we've had before so we need to try this out and see how it works I think it's better that at least the changes to the experimental modules can go in and iterate every two weeks but we probably will get an Oklahoma land rush for experimental modules every six months like we used to get in major releases as well where everyone was to shove their new module in That's why we have scheduled data early Hi, I'm Dixon, the coordinator for the workflow initiative awesome stuff, really good things can we get an MVPE implemented of this? Ha ha ha Yes It's beautiful, yes I would love to do that Do you have ideas, because I agree I look at this and I'm like, that's a lot of steps and I don't know what, like do you have specific suggestions? So I think the devil is going to be in the details here So can we get a bot for something scheduled this week where we sort of flush down some of the details here because for me it's a cool... Do you want to go through a scenario? Yeah, because I see lots of use cases for already a big team that wants to get away and work on stuff right now and there's a lot of issues in core that we can stop using this for I think Yeah And exactly what are the gates that we can pass or what are the gates that we can compromise on white space, this, that, testing, UA Yeah, white space Coding standards is a gate though, it's part of documentation Basically as... I totally think it is and I worked on that stuff, but it's been a few years I would basically just want the list of things that I could hold people to saying no, you can't hold us back from getting this to move forward I want something concrete to look at So that would be really cool if we could do this Okay, probably you need at least a few core committers for that discussion and I can't be here for that Not that you need me really I'm pretty useless Can you make it though? Well, it depends on the time now That's not important to be there You can use the initiative for it We'll figure something out Okay anyway, but plus one to meeting this week to hammer out some details with a scenario I also need to figure out if other core committers are necessarily on board with this idea But it sounds like at least a few of them are That's good So would this also apply for not only modules that also have UI components but could we also do API level additions Yes in just modules Yes, and the second thing is we can even do prototyping on API modules Something I would love to see us do culturally is when we're about to make an API change we write the fucking documentation for what that's going to look like for end users, end users, developers because CMI did that very early on we were whiteboarding like config arrow save, config arrow delete having that level it doesn't have to be like extensive API but like a prototype of like this is what the API would look like and here's how to call it I think would be amazing because then we could see that ahead of time and then we don't end up with like now we have symphony, what? So like that kind of stuff Yeah, so I think totally we can do prototyping that way we can also ship API improvements as experimental modules and that's even better because then a module if it wants to use your new API just adds a dependencies line and they're done and it's a kind of an issue that we might have like a bazillion modules that are just API things I guess there's a line Yeah, I mean we could also hide those in the user interface like and they only turn on when someone needs like a module that declares as a dependency so there are ways around that Thanks Also for the MVP or if it's implemented or why didn't we implement it so I think when we started putting this session together we were like geez this is a very complicated process it looks very scary it's like I just want to write a patch and now I need to go through this I need to get approvals or everything and whatever and it looks very scary at first but if you think about yeah I can sit down and write that patch in five weeks and then it gets rejected and then I wasted five weeks and because I didn't talk to people and now who do I talk to and who's going to tell me if it's okay or not so it is it looks like a lot of process but it's actually going to save you time hopefully so we wanted to get this into that perspective and then figure out what people think about that and if they think that it's actually going to save them time or if it's going to be painful in a lot of process so that's why we brought it here so all of this looks looks great I have one reservation so from what I understand you're saying if I download like Drupal 8.4 or something like there'll be a bunch of core modules and a bunch of core experimental modules they'll all be there together I've noticed that in contrib for example there are modules that are very heavily used that have never had a stable release ever there's just some develop branch that knows you've got to use that and it just spins like every couple weeks or something but everyone needs that functionality so they use that I suspect that what might happen is that somebody will write some really cool core experimental module and then their energy will peter out and then and it'll have some I don't know like kills performance in X situation and so it can't possibly go into core stable so it's sitting there but you've got all these people using it but no one's really maintaining it and people walked away because it's been six months or whatever so then what because like that's a I consider that a really serious problem with Drupal contrib for example because then if there's no stable release that means you've got no security support so would there be security support for experimental module I'm guessing no yes yes okay it's in core it's in core okay so there would be but yeah that do you have do you have an idea of how to manage that so we cannot commend people to work on stuff if they don't work on it the NG explained this scenario that we set a deadline for when it's going to get to stable and if it's not making that deadline then sorry but it's going to go to contrib and then people can still use it from contrib later on if they want to but it's not going to be in core anymore so it would be removed yeah yeah then we already have a similar situation within line form errors right now in core where it's not really maintained and it's languishing there and we'll need to figure out what happens with that so the plan is you tell people it'll be ripped out in two months unless you fix it and if not it'll be in contrib yeah it's fine if you don't have I mean people should not kill themselves over excellence excellence yeah I'm assuming you'll you'll policy document somewhere that says you've got this long that sounds good yeah it's part of the plan is the deadline yeah and I guess you know for you as a end user though um you're pretty well unaffected you can still it's not like the code goes away and vanishes it just moves to contrib instead and then you just have the same problem you already have in contrib which is it's probably going to be a dev release and never really go anywhere but and they already have that problem you already have that problem now we're just generating more of that problem but hopefully most of these will end up on the other side because you know only people who are pretty freaking motivated are going to even start on this I'm thinking and yeah and then the idea is hopefully with the refinements and the fewer gates we burn people out a lot less than we used to that's the goal yeah that all sounds great yeah so even so we cannot guarantee you that even stable core modules aren't well maintained right so so promising that experimental modules will be well maintained is even less responsible so I mean people should not kill themselves over these things and if they need to go away they should go away and they take their time I think that's fine and then we'll figure out what happens um yeah so I'm Dave and I'll speak a little bit as a infrequent maintainer of docs and say that that particularly if you do this experimental thing with APIs it presents an interesting challenge associated with how to advertise api.druple.org which is already getting a little bit complicated with the new 8.0, 8.1, 8.2 and stuff like that so I'm really kind of interested in how we might think about that a little bit differently as part of this because flagging something as experimental is a great idea but it also needs to flow into the documentation so that people know what experimental APIs are versus vetted APIs that are going to move forward uh that that being said um well I was just going to say that's a great point that's all yeah so so what we already do is we mark deprecated APIs as deprecated and that shows up on api.druple.org and that trickles down into the system so you can see what APIs are not in fashion anymore to so what APIs have better alternatives that are that are better to use marking APIs as experimental would be just as important as marking APIs as deprecated um I think in that uh another thing that I said what I was looking at is I think it's really going to be important to understand how we get things fit things into the 6 month release cycle because I think it's really important to maintain the regularity of the release but some problems are hard and experimental modules take lots of time to develop maybe if the problems are hard and so this looks like it would be a really awesome candidate for some sense of feature branching and you've probably already thought of that but yeah we took that out of the press too it's funny yeah so we talked or Dries talked in his last keynote or you know the one previous to this about feature branches feature branches and then like you'll notice that's not mentioned here at all so there were there were a few issues that came up with feature branches thought that we still won't use those because some things are just not going to be able to be isolated by guys or for like say brand new user facing features that kind of thing lend themselves well to modules but not everything like if you want to do a system wide change of some magnitude you're going to need a feature branch for that the reason we go for modules as opposed to feature branches is a number of things though because feature branches what we ran into is one you need to know get in order to test it which is a huge barrier of entry and you get into this matrix of exploding testing problem where the DA already pays I don't know it's like 18 cents a test that's run now you're incrementally like not exponentially I should say each feature branch is going to run all 75,000 whatever tests per feature branch and then you kind of need to mix the feature branches and see so it's way easier if it's all just in one code base with a checkbox so where possible this is a pretty good model but we may still use feature branches in the future and then there needs to be some work done in Drupal.org so that you can select a version number that's not tied to a like it's just it got real complicated basically so it doesn't rule out the possibilities using feature branches in the future but I think we want to do this as far as we can do it first does that make sense that makes a lot of sense and the final thing that I was going to say is it's going to be really important to be clear about what's gait and what's not gait in this like unit testing is a way of coding and if we're going to adopt it you can't not unit test at the beginning right so yep so some things are gait and some things are not and as an infrequent for contributor I got to say that it's already hard to navigate the the the fact that there's a volunteer reviewers that need to be clear about what they're reviewing for when they do those reviews and we want to empower those people to do those reviews but if they're busy oh I should have checked for white space did you run it through coder you know those kinds of sort of core questions that sort of throw off a newbie I think we really need to be clear to the community about what is in those gaits when yeah that's a really good point and I'm definitely hearing from a lot of people we need to really clearly indicate what's the requirement to get something from build to shipped an experimental module versus what's required to get it into core properly and that is definitely a detail we need to flesh out so thank you thank you for that so I really think testing is important and I really think it's important for people joining something because by testing something you actually document what is currently the behavior like what is actually like how something should behave so I think especially for growing the community it's kind of a documentation and thank you for the proposal we really like it and it will especially enable people to understand that working on Bucs is possible at any point in time and I think people maybe not get it maybe people will focus on it but I will gonna ask what does that mean for the idea to be able to release at any point in time sorry I've heard that enough times that I just changed up carry on and so I was wondering I mean I don't know do we talk certainly in Barcelona but especially like years like when 2008 was started like that we are able to release at any point in time what does that process like how does the process take some time because I mean it could be that you are in the prototype state and we decide okay we have like we are C1 and whoa fuck like we are I don't know migrating spoken or something if we are in the end of July and your thing is a core patch and you are really trying to rally contributors to come on to like like the core commuters can at their discretion say alright we are going to squeeze this into beta if it is ready but yeah there is going to be some painful things and there was an 8-1 as well like we hit that beta phase and it was like kachunk okay whatever made the train is coming and everything else but the nice thing is now go take a vacation and learn another framework or whatever now it's like six months but I mean I'm really in the prototype state because you will find something at some point let him finish yeah but if you notice though look at the where the 8-2 dev branch opened right so 8-1 went da da da and at the end or the middle of February we kachunked the gate but now immediately 8-2 is open so you still work on your prototype oh does that work yeah cool we even had this fancy version update thing on Drupal.org where it automatically added a comment just like oh 8.1.x is now closed but 8.2.x is open so some innovation part or inside an issue or something I mean it sounded like it couldn't be there's still a problem of things that are still prototypes that are already in core and then how that time is up we didn't have that core experimental modules have their own separate alpha beta release candidate and then when they're stable it's just normal so right now the three experimental models that are four experimental models that are currently in core are all alpha stability they will go into their own like beta phases and stuff though so if it's still at like not even at alpha then we would we would not necessarily rip it out of core but it would be from the user interface so so just on the repeated point about coding standards like we have PHP CS rules or just applies them and just use fixer it's just over and if yeah there is there is no gate there it's just just do it just run PHP CS and be done with it and if it and if the all isn't in there Alex before you sit down though what do you think of the general just yay okay thank you you want to have it in record though yeah I want this in in I want to be able to refer to this as a time stamp so I think I remember being the person to say that we should put them in the experimental packages it wasn't the idea okay cool so so yeah I agree with it the one thing that people have been saying about like the larger core API changes is if we actually did require a big huge patch or big feature bunch that isn't really a good idea for something that's experimental but the good thing about Drupal 8 is most things are swappable so that experimental module if you wanted to like say we're going to change the whole module installer it could just swap out the module installer and we could experiment that so there's you could it might be creative but if it can't be done like that then we should probably ought to be postponing that quick enough for this person anything that looks like we can't do it with an experimental module then we shouldn't even be thinking about it ready for that okay thank you fix the slide it was a bug it's now fixed I was going to say like that's just a misunderstanding like it's not that Angie already lost that argument but it's just that she lives in a different she remembers a different kind of needing to test things so one thing I should mention like it is really a pain to test then we're doing something wrong either doesn't support testing in a nice way or the stuff we build is not probably done it's more like if you do a really fancy user facing feature and then we say now you need to write JavaScript test for every single thing of that they're going to be like fuck this and walk away and that's what I'm trying to avoid I totally think like actually ensure that MVP testing can we agree on that slide now oh geez there how's that if it oh I'm just kidding anyway we are over time so let's we are way too tired there's one really quick point Andy you said like we got to be designed it's really super complex but actually that means you just shouldn't do it fair enough but you know I don't know like the swishy sidebar thing if we were going to do that it's like that's going to be however many reams of JavaScript and then the idea is what I would want to see tested as a core committer personally is does the bar swish and does it swish out and were there errors no great done you know what I mean but you guys were kind of talking about an ad hoc meeting on Friday or something is there a channel would it be announced on the boff board or something let's get it now oh god the schedule person is in the room that's true anyone can participate I recommend not doing a boff because that session slots there is one to have all of the core committers participate or except for Andy who's going to be there that could be remote though yeah for sure actually that would be fantastic the time that's open to have that conversation is the afternoon of the Friday sprint day so I'm hoping like most of you are coming to sprints you all should come to sprints it's awesome fun so it would just be on the sprint board like the it'll be a table and that I'll put it so there's a group set triple at org post that has a schedule of discussions during the week I will amend that to include this at the end of the day so that way we can be sure it'll be like after the live the mentor sprint does because one of the committers has to do that okay so it's going to be under such a board on that sheet yeah so it will it will be in the general sprint room at at the Friday sprints in the afternoon like 3 p.m. or later and I'll put an exact time after looking talking with the core mentors on the schedule on group set triple at org core the most recent post great thank you if you thought it was a great talk but only if you thought it was great just kidding can you go to node nine eight six six I think that says and please evaluate us we would really appreciate your feedback