 All right, I think it's time, so let's not Let's not run out of time although I have very little to talk about and I hope this to be Conversation as the track description says I also tried to get Daniel Schmidt over Here through Google Hangouts, but he's not responding to my Google Hangout. I mean I've sent it to him via Twitter I wanted to get all the Experimental modules stakeholders in here, so we have people from migrate. We have people from big pipe We have people from layouts. We have people from settings tray We Don't explicitly have people from media I think although there's some experimental stuff involved there as well Because I think it's interesting What were the experiences of these different projects and where do we go forward? So this is we have experimental modules. Now what I'm a Gabbro Hoi Chi on Twitter and Gabbro Hoi Chi on Drupal org with accents So first I wanted to ask a few questions on who used Drupal 8 a year before its release That's quite a few people. Okay, that's cool Pre-release Drupal 8 nice Who uses dev alpha or beta contributed modules? That's table almost everyone. Okay, it's a room of like 40-50 people everyone. Okay, who uses core experimental modules? Less but not so much less in production Only a couple of you. Okay So that's interesting because the core experimental modules are in many ways the same as contrib dev modules It's just not getting the warning for the country dev modules. You're getting the warning for core experimental modules Interesting so So yeah, so let's start with why do we even have them or why do we think we need them to to exist in the first place? so I think what we did in prior Drupal releases is We've had a stable core branch like Drupal 7 or Drupal 6 or 5 or whatever and that was stable And we usually did not touch it. We did not introduce new features We did not make any major changes unless required by critical issues or security fixes or whatever and the same time We've been working on the next core branch and and plus one seven eight whatever was the what plus one two n So when we've had triple seven stable supported We've been working on Drupal 8 for several years and that was unstable So if you use the Drupal 8 a year before it was released because we were still making big changes If even earlier we were making huge changes so it was not feasible for Everyone or it was not a economical for everyone to use Drupal 8 at that stage It was very comfy for us to do because we've had a stable version that people could use download and enjoy and we've had a thriving contrib ecosystem on that version and Then we could Redefine Drupal in the next version however much we wanted and we did very huge changes in Drupal 8 So that this model served us well to be able to do those huge changes The problem is that we did make those huge changes so that a lot of things changed and people were not Ready and there were did not have the opportunity to go through with those changes and they got all of those changes that ones like a big all-in-one package and There was a lot of effort to to train the new people that we're still ongoing here There was a lot of effort to build migration paths between the two that's still ongoing still not done and There was just this tension between the two as well so what we wanted to do and also also generally it took a long time to build the new version for Drupal 8 it took more than four years and We were building things that were not necessarily validated by the world We were building things that we thought will be nice, but we didn't know if they are going to be good or not I've been involved with the multi-lingual initiative and we did a lot of conceptual Building so we like made up something and we were like maybe this is going to be good for the market We don't know and I'm I still enjoy hearing these validations here I've been to the media summit and I've heard the validation that it actually works which is kind of nice But we've not been in touch with the market for for four years to validate what we're working on actually makes sense And it's useful for people to use on the site so what we decided to do instead is to Instead of working on a separate unstable version try to innovate within our stable version To introduce new features to build a new capabilities But turns out we cannot do that fast enough So we wanted to release new improvements to people At least twice a year. So we have scheduled releases that come out every six months and What we are used to do in the unstable versions is we have years to figure out what we want to do We have a proof of concept We figure out the the flaws of the proof of concept We write some some tests for that and then we work it and then refactor it and then okay now We have a better version and then we Then we start with that again, and then we do this process two or three times We did that with the configuration system in Drupal 8 we rewrote it two or three times We did that with some of the multilingual code for for a config translation for content translation So we've had that time to do that do that processing ourselves But if we need to release twice a year and we need to give people the chance to use the new stuff We don't have that luxury to like rewrite everything So what we decided to do is make space for us within the stable release and have a separate playground of unstable things within that stable branch So we don't need to deal with building a branch of building a totally different branch. That's unstable and this allows us to support our stable code and It also allows us to put out code. That's not yet stable But we would like to have it be stable soon maybe in six months maybe in a year We are giving it some time so it gets the kind of feedback that we need so instead of building this connected from the market in a totally different branch that nobody can use for four years we put this in the faces of everyone in core it listed in the modules and We hope to get the kind of feedback that helps us make it stable and we helps us make it move into core so the way we decided to place them in core is We have a big set of stable modules that are included in core and they are in different groups of modules and Then we have a set of experimental modules that are in alpha We have a set of experimental modules that are in beta and RC and They live alongside in core in one package we deliver them in one package So the way we differentiate them is we put the all the experimental modules in core experimental and we put all the rest of the modules in different stable packets and The key thing with introducing an experimental module is We eventually want to have it as a stable feature so people can actually use that So one of the more important things that we set as a requirement for new experimental modules is For not just them to stay somewhere, but to have a plan to move forward to beta RC and then stable So we wanted to have a way to experiment with new things put them in core put them in and users faces But also a way to tell What's still left to do and this is a part of a requirement to add a new experimental module in core is to Define this plan and to have this plan available and also to have a timeline for that plan to be completed and the timeline is probably the most interesting or most Risky part that we need to talk about today So we put these Non-stable modules in core. We're working on them for them. Hopefully to get stable at the end And if they don't become stable by the timeline that we hope to for them to become stable They risk being removed from core. So if they don't move forward on the yellow brick road, then They have a chance to Get removed from core So where are we with all of this process? So let me try to get the sieve Stefan joined us. No, he did not That's sad So where are we with the process? So we've been introducing and advancing with experimental modules from triple eight point zero point zero The first experimental module that we've had is inline form errors It's in core it this is still in alpha. So these are the same colors that I used before in line form errors is an alpha core experimental module and It's it received a lot of great work recently. Thankfully We've also added my great Drupal and my great Drupal UI in 8.1.0. I think and We advanced since then the migrate module to beta So it now has a stable API that you can build off of but the rest of my great Drupal and the my great Drupal UI are still alpha Modules we've added place block and settings tray in Drupal 8.2, which let you have an easy way to add blocks on the page and to Configure blocks on the site and hopefully for more more contributed module integrations allow you to Do all kinds of other fun things work with workflows or web forms in the settings tray We've added daytime range as well in 8.2.0 Which lets you set ranges for dates Surprisingly, and we've added content moderation in 8.2.0 and all of these still remain alpha experimental modules and then we refactored some of the content moderation module in 8.3.0 and Created the workflows module that now the content moderation module relies on And all of them remain alpha and we've added the fill layout and discovery modules These are two modules that are new alpha modules in 8.3.0 And that's where we are right now so we keep adding experimental modules and Moving forward with some of them the most successful modules so far in the process was big pipe That reached out of the experimental module range and is now a stable module I think it had a very lucky time because it was small self-contained not providing an API for others and Had very little but had no settings. So it was building on what Drupal already know about your data And the rest we found all kinds of interesting difficulties with However, we are also planning for 8.4.0 and We plan to add a demo Installation profile that may be experimental and a demo theme that may be experimental and a media library that may be experimental So when you look at this picture, I think you you may understand the anxiety in the Drupal release management team So keep adding all these Alpha experimental things and we are not really moving them forward We are like if we get Drupal 8.4.0 with this then we've spent More than two years working on things and we haven't been stabilizing what we've been working on So the way we are trying to get people to try these out is we created a core experimental package in core All these modules are listed there It's not very ideal because they're they're not grouped by functionality But we thought it's more important to group them by stability and when you actually want to enable them we tell you that These are experimental and we ask you if you are sure you wish to enable experimental modules. We warn you three Sorry three ways So you warn you in the title We warn you in a warning message and then you warn you in the list of the air of the warning messages These are experimental modules really really experimental modules Are you sure are you sure and if you're really sure then you install them and once you're sure and you've installed them When you go to your status page, we also give you a warning that says by the way you have experimental modules And that may not be the right choice So so I guess I'd based on the hands up at the start We've been very successful scaring people away running experimental modules in production at least people in the room So that's nice. It's also good because we've been making really big breaking changes Like if you enable content moderation in 8.2 and you try to update to 8.3 You got a fail error in your update and there's no way out. It's impossible to continue. So Yeah, so you should not do that on your production sites So the way to tell which modules are which level of stability is Quite obscurely on a documentation page on Drupal.org because we don't have a way to put that on the UI so As this documentation page, these are all the modules we have so the things that I wanted to call out here are Big pipe and inline form errors So big pipe is still listed as an experimental module because it was an experimental module up until recently and it had a deadline In 8.3 to be removed and it got stable So it's not removed and inline form errors also had a deadline to be removed and we did not remove it Because there was a lot of because there's a lot of great work going into it And we and the release managers decided to give the module another chance the text and the bottom says that this deadline is the what we assumed by default and then committed discretion allows committers to postpone that deadline the really scary thing is The is well, not this is the real case Not this is not yet the really scary thing. So we also have the migrate suite, which is another special case Because they don't have a deadline Because we consider migrate to be an essential part of what Drupal needs to do because we want Drupal 8 to be A system that people can migrate to from earlier versions and also from other systems But this is really for earlier versions And we don't want to remove that functionality ever. So we consider that that a key functionality So I'm gonna be removed even though they are experimental for quite a while But the really scary thing is What's coming up in the next release? Because workflows has a deadline in the upcoming release content moderation has a deadline Inline form errors going to be having a deadline now place box setting strain daytime range So So it's not so it's not just that we that that we have a lot of experimental modules And we may be adding even more in this release It's also that that two-thirds of the existing experimental modules have a deadline in Four months or something beta one four months So So it's quite pressing. So that's why we are here today So So the question is how do we get better? I Don't know Another question is our experimental modules working out for us Is this the right tool? Are we doing this right? Should we do something else? Should we? Figure out some other way to put people put new features in people's faces and then and then It would also like to hear from all the maintainers of these modules as in terms of how it worked for them So with this I would like to open this up for discussion Can you just I'm Laura. I'm one of the provisional framework managers focused on front end. I just wanted to ask clarifying question Because it might affect the conversation about what is the specific reason for the deadline being set for experimental? modules Yeah, I think that's there's multiple reasons We so the reason we put experimental modules in core is because we think that these are great features And we want people to use them in production But so long as they are experimental We don't suggest them to be used in production because there may be changes that break their sites so we want to eventually be able to to provide them as actual features and Longer we not do that the worst that becomes it's also a Big burden on maintenance to try to figure out the different combinations of these not yet really working modules with each other Although a lot of the bugs that the experimental modules identified were pre-existing bugs in core and not necessarily bugs with the combination of experimental modules and Yeah, I think those are the main reasons Yeah, so the more we have in core the harder to like shuffle them around and figure out the plan Yeah, it definitely makes sense But there is also probably other reasons that we should be considering such as how many Experimental modules to be when I have open at the same time, which I don't feel like we've considered as much yet at this point I don't think we have a number defined I've invited release managers to this conversation, but we don't have them present But they would be the authority to define that I think there's a general feeling from release managers that they are not comfortable adding several of them in 8.4 Because they already kind of a agreed to have media library maybe and the demo stuff Which will be some more So there's been some debates around new experimental modules for API first for example Which we discussed and turn and and turned out to be better fit for contrib for now But then we don't have a number defined Yeah, and that's true. Yeah, that's just something that I Fund personally very helpful in a client work that we limit the amount of work We take into to be worked at the same time and it helps the First the success rate like how successful the things get usually done because you have more focusing on a single thing at once and that but also it Adds more speed because if you don't have to try to use switch context Yeah for an experimental module to get into core is much less of a requirement than a stable module so Any feedback from the experimental module maintainers? What they think is the strong and or weak part of the process. How can we improve? Is this the right tool? Hey, some dick. I'm the corn the initiative coordinator for the work for initiative I think that the experimental Module process has been working quite well It has certainly introduced a very like a great venue for getting things done quite fast in core But it's challenging with initiatives that need to change Fundamental parts of of core because things can't necessarily be separated out in an experimental module very easily We of course have the regular core Process that we can there we can rely on but that is still a slow process. That hasn't changed a lot recently So content moderation for instance content moderation itself is Stable piece of code, but we're surfacing a lot of bugs that has existed for six eight ten years in Drupal and content moderation is stable by itself But we when you enable it you get all those bugs you get all of those parts so what what apply like What constitutes stable for an experimental module? that is like an Interesting gray area to me that it's that we've had a lot of challenge with Yeah, Danny I could not call in but but he faced the similar problems with inline form errors is That in line from errors surfaces a lot of bugs that were years old and just if you enable in and form errors They are much worse because now if the error is not displayed at all for a field like for one of the bugs was that if Element is in a field set that's closed Then the error did not display and with inline form errors because the error was on the form element If you've had a closed field set you would never see that there was an error But if you don't have inline form errors enable the errors at the top of the form So who cares if the field set is open or not because you see the error So it's like okay, so this is a thing that we need to open the field set for things that have errors. Yes so I think initiatives were put in place to really drive change in core and And and our initiatives funded so we have like a stable team that works on it. We're very productive But there's still and So I think the need maybe we need to think a little bit harder for initiatives I want to like do deep change in Drupal like the entity API the in the in the translation API on the storage level Data stuff. I think experimental modules. We don't have an answer to you know initiatives They want to do great change there. We have the regular core process, but still quite slow and and it's not it's still not E what am I saying that's wrong here People line up behind you immediately So that's what I want to say now Converse Continue conversing. I just have 40 Last point that especially when we get closer to Drupal 9 it becomes more and more the problem because we have to start to be factoring our APIs and preparing for Drupal 9 and it's definitely something that we need to figure in Soon near future Hi, I'm Tim. I'm the co-leader the layout initiative and I'm responsible for some of those other features that are kind of left to Themselves and that's what I wanted to talk about in addition to the the challenges of making sweeping changes in core The ones that aren't part of like a larger Focus are just like we want to solve this one problem in a specific way And not but it's not stable yet, but they kind of language. It's easier for them to languish Since they only do one small thing and there's no larger work being done around that So I worry every time we had a new module that is standalone that is They're the ones that have the harder problems hitting their deadlines. Yeah, so those are the ones that scare me I don't know if you have any opinions about that That's ten since those are all yours. I don't have a solution But although one of the tricks that you have Tim for or do you use Tim for? for for adding new core stuff that's not necessarily a module is you've added services and Then it's only exposed for Drupal if you enable the experimental module So it's added as a core service which on which on the cursory look like a core service in this table core system But then you need to enable the experimental module. So it's in a place where it is supposedly gonna be at the end But until we figure out if it's good or not, you'd need to enable an experimental module to expose the feature I think that's a good trick to like putting something in in as in a it was a new subsystem that you need and Exposed it as an experimental thing So my name is Ted Bowman. I was working Ted Bonjupit Lord org I was working on this or I am working on the settings tray module so that's the tray that comes out and Place blocks module and trying to get them to look to act together I think some of the pain points were one, you know, we're doing a lot of JavaScript in the and this is probably not That the fact that it was experimental just that there was a fair amount of JavaScript in the module and Java JavaScript resources as far as developers to review and stuff are pretty limited in the Drupal community or Seems like to me, but I mean I'm new to core. So I think that maybe it's been a problem for a long time So that's sort of most of the stuff that after the initial commit of the Module for settings tray, at least almost all the issues involve some JavaScript So and then also we have to write so we write JavaScript tests for all the stuff that we put in which Is great, but also I think we ran into a lot of issues with the JavaScript testing because I think a lot of the advanced JavaScript stuff in Drupal 8 got in before the requirement for JavaScript testing I think that's true Yeah, so we're running into a lot of like random errors that just that it works and then like the test randomly will fail For some people and then of course that breaks head and it's horrible Try to think well, I think the other probably main problem that I see a general problem is I Don't know if there was a buy-in for the settings tray module in the larger community I mean maybe there was but it wasn't like something like the layout where you had a bunch of people already using it And you could say okay, we're gonna get this into core and it really helps a bunch of stuff and contribe all at once or has a potential to Where the settings tray You know that wasn't like okay if you work in x y and z can trip, you know this let's All work together and do the setting straight I talked to some people with panelizer because they have a tray and you know They were interested in once I get stable that maybe they'll start using it for part of it But when it first came out The other problem was trying to get trying to extract some of it out of the module before it got into stable Which I think was probably a bad idea in hindsight, but the idea that the portion of the tray opening up and the portion where the blocks are you click on them and you You just click anywhere in the site and it opens up a form My thought at first was to get that tray separated out so contribute start using it without the whole blocks functionality I don't know if I'd do that again if I was going to do it I think a lot of it had to do with like getting JavaScript maintainer should get stuff and I've worked in contribe like so this was my first big thing in core and I worked in contribe a whole lot more and of course Things just happen faster and contribe Code quality is better in core for sure at least for compared to my contribe modules though. I think they're alright I think they're pretty good, but they're better in core It's a thing. We are hearing a lot from Tim Milwood as well in the workflow. Yeah, that it's I think expected Things to grow much faster in core Yeah, and I know all these things that turned up from the other existing bugs I know a long time ago. There was a thought of having branches for a triple development your blade development I don't think that ever Happened well, obviously it didn't happen But you know if we had a settings trade a settings trade because it's not really integrated with a bunch of other stuff like Content workflow or content moderation might be I feel like that could have developed in a branch Pretty easily, but I'm not sure if we actually would have got commits faster because it's the same committers So it's not necessarily like that that would help much because there's only X number of committers So I don't know I guess if it was if I was to do it again if it was all up to me Which is not I mean I probably would have considered doing Something and contribute a whole lot more working can trip more and then trying to get it in Place blocks is simpler I Guess the other thing is like how do we like promote this? I now the web form module is using settings trade has an option to but it's also like I want to go out I'm just now going out and trying to like get contribute to use it, but it's obviously You can't have contribute use it and be the only has to be like a fallback because it's it's it's experimental obviously so If I would say it's whether success or not really probably depends on whether The people work on it me and the people work on and get it done by July the end of July if it is then I feel like it was excess success if it we don't then it wasn't so I Still to be seen I think we will hopefully But if anybody wants to get involved and help it would be a whole lot We could use help basically basically like we could use help that would be great So anybody who's wants to get involved in core development. Maybe you're already involved Yeah, talk to me after this session. Yeah, I think it's interesting that we are finding a lot of these auxiliary problems Like for JavaScript testing, but then those are problems that we would want to solve any way in some way And then we turn up a set of people who are interested in that and are starting to work on it So it's in one way. It's slowing things down in another way. It's raising problems That are ideally solved as well. I think I was wanted to mention this what I would have done in my situation differently, I would have spent You know like probably a quarter of my time trying to promote it Versus Like take the time out. I was coding it. So yeah, we need to really dedicate a quarter of this time to actually like saying Hey, here it is everybody and you could help out with it Which I'm this call right now to do that But in general like it would have been better for me to do that way back when so Mike Ryan my great So Well, I was already going to say it even though it's already been covered, but you know, there is the The trade-off between developing as an core experimental module versus contrib and heights in hindsight, I think my great could have been Baked a little more in contra before we put it into core. There's obviously some more Friction it's a lot easier to develop quickly when you can commit it will On the other hand migrates a special case it touched so many parts of core that our our sandbox was actually a fork of core Rather than a module Which complicates things and And that that was rather a mess But apart from that I guess I just want to call out Particular issue with my great that Probably doesn't apply to too many other experimental modules, but And that's the fact for the same the same reason where and a For the for the deadline is that There is no alternative It has to be there people need it Which means even though We've been alpha People are really using that and we we could not simply ignore BC Alpha Alpha says we can ignore BC, but in practice no we we had to be very careful about the changes we've made and If we had to do a hard BC break be very clear and do do the best we could to help people make the transition Yeah, that's a very good point when I was preparing for my session I was trying to find the similar patterns with different Experimental modules and they all have they are most of them are their own special flower of what they've turned up and found And how they solve the problem and for my greatest is very true that we've got a lot of feedback from people when we change some things that were not not backwards compatible anymore, and they Like but I have my Contributed distro have a migration path the built on top of this and why are you changing this because now it's there And we're like, but it's an alpha thing and they're like no, but it's the only thing we have Yeah, yeah, and another thing I want to point out is just even though they're those hard labels alpha beta rc Which looks like a step function in reality you really have to gradually Raise your thresholds in terms of what you allow in terms of BC breaks if you're on the verge of going from alpha to beta You know you've got to start saying okay. We cannot have a major BC break now We can't to completely redesign things. Yeah, you know you just have to incrementally Make your bees whatever BC changes you have to make narrower in scope smaller smaller impact Yeah, good point It's dick here again, so I just wanted to address the productivity question and discussion we had earlier when it comes to core commuters So I think some issues that we've faced Was had to be pushed down further down the line because of Core commuters are very busy and I'm not I'm not pointing any fingers here at all I think they're doing a great great job and it's improved tremendously over the past a year and year and a half But I think when there is a an initiative that's sort of show a great deal of commitment And we have this great experimental module process Perhaps part of the solution could be like core commuter access to your own experimental module that it poses some great governance issues and and I'm not saying that just because you show up with a pile of cash you get core commuter access I'm not at all suggesting that What I'm saying is that there's been issues many issues that we've marked as workflow initiative critical That's been sitting in our to be seek you for three four weeks and it's greatly in you know Had an impact on our productivity, which is why eight point three in in in some respect turned out to be this Big, you know change migration issue for content moderation some of that could have been addressed with okay We've got a separate experimental module Let's give a Initiative team that has in our long-term commitment Let's give them some autonomy over that experimental module perhaps to to increase that productivity Lots of governance issues around that I'm well aware of that, but perhaps that could be it could be something We've added more core committers recently, but we still rely on very very few framework type core committers That hasn't changed at all in the past. I would say two years almost And and for us where we try to make deep changes into Drupal It doesn't matter if we have more core committers if there's still just one or two framework type core committers that we rely on Yeah, I know at this has has been a very active concern for the core committee or team the Decreased capacity that there's not many framework managers and there's also decreased capacity of existing framework managers because of just human life events So that's a that's a concern and they and there's there were some attempts to feel that gap But they did not work out so far Unfortunately, yeah, but it's definitely on the radar. Yeah, it could yeah I think experimental module core commit to access could be something to explore perhaps. Mm-hmm. I Think that sounds terrifying. I don't think anyone should give me core access So I want to talk Mike mentioned Letting things kind of grow and contribute first One thing that you had didn't talk about the kind of the first experimental module in a sense was views Views was a module that was moved straight basically into core during the dev cycle And that was done in a in a sandbox as a clone of core not as a module and that really helped us Track core changes a lot better We had to bribe a test spot maintainer though to set things up so that we could actually like track core closely So there are some infrastructure changes that could be made to make that more feasible And then you do have commit access to all of core In a way, and then you they would only have to review the merges later. So I think there's a lot we can do with get There that would help And I'm now completely forgotten the other point The reason this so there's discussion on having core branches also for things and That was also in the context of the existing core committers having commit access to branches only not the initiative reads Because there's if we are if we are concerned that there's framework manager and core committer resourcing problem then Reviewing those huge merges is is an even worse problem than trying to review some of these smaller Yeah, smaller changes that are still quite big That I would like go there so it's recorded So a point with experimental modules though is to put it in front of people right and not do it separately in a sandbox And I really like that idea. I also like your idea because that would that turn out to be really successful But like to find a balance Putting things in front of people versus productivity. That's a hard problem Yeah, I still think we could solve it with infrastructure like the Subtree split of core just started today like you can now pull in single packages of parts of core core could easily pull in Parts are like on the fly from other other sandboxes and whatnot I did the other point take me about framework managers feel The layout initiative would be much further along if it weren't for that bottleneck Except for the part where the reviews given by those framework managers were invaluable And if we had been able to commit things Without their review, we would have moved faster, but we would be in a worse place Would be moving on an architecture that then you would right? We would be going very quickly in the wrong direction Yeah Which is not really progress in my opinion No, and honestly, you know the there are certain only certain few people in core that can really Understand the entire weight and scope of a change So and while I wish can move faster. I respect bottleneck That's why it's hard to recruit people for that role. I had Before I was asked to become a commuter. I had a pretty interesting discussion with Alex Alex bot About like how do we manage the initiatives as a maintainers of the software and One of the things that we both agreed on was that we would like to be more Involved in a little bit earlier on the issues than at the committing phase when the committing phase would be easier And it would become more productive for the initiatives because if they could get the feedback earlier on then at the patch phase and Yeah, my personal opinion is like once we can go towards that direction Maybe like some sandboxes or other things would be more helpful but having like this initiatives working in isolation in a Different project pages would just make the situation worse because of like reviewing Huge chunks of code. This is not productive at all Hi, I'm I'm when I maintain the big pipe module together with a Fabian I Think the reason the big pipe module had a easier time to become stable as an experimental module is simply because it doesn't have a UI It doesn't have configuration, which is kind of what gabber mentioned. So it is kind of the only one In the list, I think like that. So if you have an Experimental module that you want to propose that is like that. I think you have an easier time maybe we need to favor those kinds of modules because they can Come to fruition faster, but then at the same time, of course modules like workflows and console moderation are super important But obviously those cannot live without UI without data storage and so on so big pipe is kind of Exceptionally easy in that way We also had the benefit of having worked on both of us on the render system in Stabilizing triple-8. So we know where the edge cases were that we had to think about we were able to write extremely Comprehensive test coverage that prevented lots of problems later on. So I think we just got lucky in that sense But then also from the perspective of I'm also the coordinator for the API first initiative now And as part of that we work on the rest module in Drupal core the rest module in Drupal core is marked as stable Should have been experiment and should have been experimental So it should have been over there at the top above in line for Maris And I think the fact that it is not stable or the fact that it was not Marked as experimental that it was marked as stable inappropriately. So It means that we shifted the problem of properly integrating all the things to a later point in time as in Triple-8 1 2 3 and still on going because that's roughly what what dick was getting at about The speed and Tim as well. There is a certain like I think Tim put it really well. He said I'm glad things are blocked essentially Respect the bottleneck, right? So basically respect the bottleneck is equivalent to Do not ignore the in the cost of integration and take integrating all the things takes all of time And that's what you're seeing with a workflow initiative Content moderation itself is stable But you're surfacing all the integration problems in the different subsystems that you're relying on or Exercising that we're in being exercise before we have the same problem with the rest The thing is that because you're not yet a stable module with content moderation workflows You can still change things in rests. We have to work extremely hard to not break things and it's excruciatingly painful So that's that's a downside if you go with the right of having fewer Framework manager reviews and so on so I would say that's not forgot forget about that because it could be a big downside I was sort of thinking about the idea of branches again So I could see for a lot of stuff where it wouldn't work But if you have a module like block place or settings tray were I think we had one core change in settings tray that was Probably needed for other stuff. It seems like branches would work better in that case, but it only really works if you You know if it's a really encapsulated module, which maybe most of these aren't maybe they surface other errors that then you really need to fix But I don't I don't know if like making a branch and then giving the Initiative owner like access to just that branch as long as it only changes something in that that experimental module holder would be something The other thing about like, you know not doing in the branches To avoid these big chunks of code that would be committed But for stuff like place block Potentially if it gets into the block module anyways, there will be no place block module. So there will be that end huge Coder view I think because it'll have to it won't be where it is Some of that's true for settings. Hey, too I think that was one of the problems with us trying to get some of the the tray part out of settings tray and into Cores it is that one big review Which is I think why it didn't make it in 8.3 But yeah, that's just I don't think I don't know if place block is the only module that potentially won't exist Once it's stable that it would just be in the block. I don't Discovery Yeah, it's gonna be a system Field layout So I don't I don't know if I don't know if there should be Different workflow for those kind of modules that though that we're not planning on them being a permanent thing Because I think in a lot of those isn't they're gonna be at some point a big if they are moved into another system Isn't there gonna be a big code review anyways? I'm not sure like field like yes There's gonna I don't yeah, even once we finish the module and it's done It's gonna all three of those field layout field discovery. Are you sorry field layout layout discovery and block place are Intended their future home is somewhere else as instead of being they're basically a set of altars Yeah alter hook form altars and whatnot and yeah when we rewrite them to actually go to the place that also needs code review Because we are changing more the actual core for once Even once the rest of it is Concerned stable and yeah, you start so you still have that giant one lift and shift at the end One more question anyone maintaining distributions are modules that rely on core experimental modules to work Yes, you You have the migrate tools and stuff to relying on my great and Dick you're working on okay Yeah, because so that's a problem that's been that's been an issue around layouts and workflows at least and Is being a driving force behind media to get the media modules stable in core initially instead of experimental and Just the media library to be experimental and not the media data management thing to be experimental because As long as there's contributing modules that need to rely on your stuff for distributions They will have a very hard time if they need to rely on a stable unstable Experimental things in core and that was a lot of argument around in the layout Seen and there was a thing that the media team wanted to avoid at all cost And it took half a year now to try to avoid that problem So it's it's been a lot of cost to the media team as well so we've only heard from experimental module maintainers and core committers and part of experimental module processes trying to surface that to other people so maybe Like it'd be good to hear from people who like is this actually surfacing anything to anybody or is it not? So if anybody has an opinion on their experience not being involved in actually making the experimental modules But either seeing them or possibly using them or thinking about using them. That'd be good to hear also Just a quick observation on my my great plus my great tools today. I opened 8x-4x For both those to be compatible with Drupal core 8 3x. I've had a new major version of those contra modules for each core minor version because the my great API has kept Evolving I really really I am motivated to get the stable for 8 4 So you don't need to maintain the branches, but that's what that's what the layout Ecosystem does as well as that the display suite and panels. They're making new branches for new core versions. I Don't maintain any of these modules, but as somebody who tries to Like I have a patch on CDM that Whim I don't know where he went But like is providing me some really great feedback on and it's you know that kind of high-level review that that seems consistent there And it is a long process, but at the end of it, you know Getting feedback from people who are really good. We have a lot of experience is super helpful So I get what's slow about it, but I think some of this belies some of the Stuff that infrastructure team is going to be working on about Like it's hard to like you can't mention people in the issue queue, right? So like and which I get is a thing and all of that but like I think some of this It speaks to just problems with the tools that we're using of it would be way easier to get quick early feedback from people if You know, I would imagine the core committers have trouble just finding out where they're needed Because the tools are so like I don't know where those discussions are happening But like if we moved to get lab, you know a get lab instance or something like that That I know they're talking about maybe doing I feel like it would be easier even in contrib where it's like I just need a little bit of access to like smart people who run some of these projects to move things forward Just an idea Okay Aaron do you have Daniel on there? Is he has anything to say? On my hand we're gonna try to join again see what happens. Yeah, Daniel. Hi. You want to Say something I missed the first half of your presentation, but What I heard were some Question-to-answer some nicer Suggestions What I was interested about is What would happen? Once an experimental doesn't make it and I form errors was the first module that was considered to be removed I Was said that we should move it to country if it failed, but Yeah, okay, we passed but I'm interested what would happen if it gets in country Yeah, that's a good question. I did not talk about that. So so yeah in that case It could move to contrib and then whatever And then people can take it on and take ownership and then do whatever they want once it's in contrib So then from there on it's Whoever takes it on It's similar to what happened to like block module other things that have been removed from core. Okay. That's clear What I liked about keeping it in core is it's especially for inline form errors it touches so many aspects of triple That it felt like it was easier to change all these little things to make the big thing great And if it moved to country, but I think it would be really hard to fix all these small things in core to have this focus under one and for inline form errors, it's all in one Meta issue and I think 80 to 90 percent of all the issues were already core bugs I think it really helped to keep it in core to well just make Core better and then get in line form errors more stable So but all right. Thank you. Any other feedback or concern or suggestion for improvement or based on your experience? I think it's It's nice if things are not in contrast. So if we would skip Experimental models and say okay, we develop everything in contraband. I think getting credits for core is Nicer than getting them for a contraband. So maybe it helps getting people to join develop for it because well, it's for a broader audience Yeah, maybe that On the other hand Feels kind of sluggish that we have so many experimental modules now in core So I don't know if there's a possibility to have something in between so we ship Drupal only Without experimental modules and then with composure we can see our deaf requirements out there. There are something like that Okay Thanks Okay, we have another person here. Yeah Hello, I'm Josh. I work at Acromedia and we build a lot of e-commerce sites and talk to a lot of people about building sites more than we usually build and We don't enable any of them any of the experimental modules because they're experimental but we see them and From my perspective Seeing it in core really helps me as a developer when I'm in a meeting with clients with sales Communicate where core is going That's really helpful my great. I consider it stable whether it's alpha or not Even if it's changing because core changes too a little bit, but I guess something I'm Thinking about you know, we have this problem We need people to use things that are experimental to push them forward If we're warning people three times when they're enabling a module Maybe we could encourage them as well to please enable this module and give us good feedback Go to this issue queue Maybe work on some of these issues get excited about it because it's a big platform We're giving them putting them in core and we can use that for good not just for warning Yeah, there was some discussion though There was some discussion on Having a dev slash live toggle that way you can say this is a deaf side to please don't warn me about these things This is a live site. Please warn me about these things. So that would help I don't know where it's at right now, but this being one of the proposals that could help with this All right, so Thanks, everyone for being here and I'm glad we've had all these great feedback. Thank you for the discussion Thanks, Daniel Thank you. Goodbye