 All right, let's dive into it. So first of all, we're going to talk a little bit about the background and the goals, what we're trying to achieve with this initiative. We're going to keep it brief. We will look at the plan, overview of the plan, look at some of the lessons learned throughout this initiative, and then dive into more details on some of the work that we're doing at this very moment. This is also a core conversation track. So I'm going to try to leave plenty of time towards the end for questions and hopefully answers as well. Just so we can hear from you guys, possibly using or watching this initiative, what you guys think, what you think our priority should be, and so on. So hopefully we can have a conversation there. Very important for this type of track. All right, first of all, I want to say a big thanks to the funded team that we have in the initiative. We have two of the members on the team here in the room. Joseph and Andrew, can you please stand up? Tim Milwood and Andrew Matesco, they are not here at DrupalCon, but they are definitely worth an applause than them as well, I think. So this isn't just the work of a few people, right? This has been a big topic for Drupal and within the community for a long time. So it's not only the funded team here that's done a lot of work, but it's been people in the past that's put in a great deal of effort here. So Hey Rocker, Greg Dunlop, started committing to modules that we started trying to get into nine years ago. That's a long time ago. Ken Rickert or Agent Rickert, six years ago, Workbench Moderation, and Dave here in the room as well has been involved in related efforts for a long time as well. Six years ago, we did the first commits there to the UUID module. So big applause for these guys as well. And Dave is in the room here as well, so he can't hide. He never hides. So and then about seven years ago, this is when we first started having core conversations around getting some of these pieces into quarters. It's been a long period of time. Persistent work being put in to talk about these things, improve Drupal, and hopefully get these things into course. It's not only been Drupal 8. This has been a long effort. That's all I want to say. So the first core conversations, that was Denver, 2012. After the 8.0 release, the workflow initiative was the first approved initiative to move ahead. Since then, there's been many, many more initiatives, but we take a little bit of pride in being the first post 8.0 initiative to be approved. So what are we trying to achieve? So we want to enable efficient and accurate content workflows in Drupal. We are a content management system, after all. That's what we're trying to achieve. Four content editors, obviously, by enabling moderation, content moderation, and full site preview. We'll talk more about what that means in a second. One of the things we did about a year ago, when this initiative really had crystallized, is that we had a sprint, a usability sprint, or a planning sprint in Amsterdam, where we mapped out a lot of the efforts and a lot of the stories and journeys that we wanted to achieve. So this we did with Boyan and Roy from the community, and Joseph from the funded team. A lot of whiteboard, a lot of sticky notes, a lot of thinking, a lot of planning. Who's this for, and what will it look like, and how are we going to go about these things? So that was a very important effort we did last year in Amsterdam. All right, let's dive into some Drupal issue queue, shall we? Or we're gonna take a look at the phases here. So the general plan you'll find in the issue queue, there's a lot in there, a lot of detail, but it's for the purpose of letting everyone having the chance of being a part of this journey and contribute. So the plan is divided up in several phases. So we're gonna walk through the phases to give you an idea of what we're targeting or functionality we're targeting where and when. So the first phase, also aligned in the issue queue, is we want to introduce the revision API for more entities in core. At the moment, it's only the node entity and blocks that have revisions on them. In order to do any sort of moderation or workflows, we need revisions everywhere. So this was one of the very first things that we're doing. And there's a lot of work in this very first phase. A lot of underlying APIs, not necessarily visible to anyone. We're working on an upgrade path because if we're enabling revisions on content entities that don't have them, we need to be able to upgrade to that within the cycle of Drupal 8. Also a lot of hidden work, so to speak, with new interfaces. We've got an editorial content entity base, lots and lots of work just going into that particular piece of code that is not used in many places at this point. So this is a big phase. It's taken a lot of time, probably more time than we envisioned in the first place. I'm saying that it's fixed here because we're almost there for the purpose of this presentation. I like the color green, so I'm gonna say that it's fixed. There's some outstanding issues there still. So almost fixed. But that's phase A, so big milestone. Phase B, initially we had in the earlier phases here to introduce the concept of parent revisions. This is to allow branches and sort of parallel changes to entities. Introducing things as revision trees, branches and ultimately conflict management for like concurrent work. We've postponed this phase. We're waiting on actually the very last phase to finish this line of work. So we're not gonna talk too much about this because it's still quite far in the future. Phase C of the initiative is what many of you have seen in various announcements around Drupal 8.2 and Drupal 8.3. We've introduced the content moderation and the workflow modules. I'm not gonna dive into details on exactly what you're doing. That's not the purpose of this presentation here. Some of the challenges that we've run into here is, and we spoke about this on Gabor's session here just before my session, is with these modules, we're suddenly giving a UI, a user interface to longstanding challenges and bugs in core. So we've had to deal with not only introducing new code and user interfaces, but these old assumptions and old bugs in Drupal around revisions, forward revisions, forward revisions and translations, moderation of translations and forward, all of these things. So that's been a big challenge, big challenge. But content moderation is now in 8.2 and the rewritten version of it is in 8.3. So phase C, although there's again a few minor issues that are outstanding, we consider this phase largely closed and done at this point. And the goal here is to make it stable by Drupal 8.4. It's currently experimental in 8.3. So that's where we're at with that. And you might think that I don't know the alphabet. But we've had, I'll come to this later in the point, but we've removed some phases. So phase E comes after phase C. Phase C is dealing with trash, we'll introduce a trash module and undo functionality. Quite a basic functionality. It made it into Macintosh around, I think it was in the 80s. We still don't have it in our content management system in 2017. But so that's quite a basic functionality that many people exist from a content management system today, we don't have that. We're looking to introduce that. There's quite a few usability challenges around this. So this phase still needs work. We have proposals in the ECQ, we have wireframes and designs and quite well flushed out patches. So if you're interested in this particular functionality, we need help with this one at the moment. So take a look at the issue number on the screen there. The release target for trash module and undo functionality is still to be decided. It depends a little bit also on the effort from the community here and the interest in this phase. After E comes G in my alphabet. So this phase is actually split up into two a little bit. So we've got two issues tracking this. So to answer your question mode, yes. So this phase is ultimately here to introduce the end goal of this initiative quite much. Enabling full site preview with something that we call the workspace module. So this is something we're gonna dive into a little bit in more detail later. It's introducing a very bold and new mental model to Drupal, a different way of thinking when it comes to managing and moderating content. So it's a big change. Perhaps even in terms of thinking how we use Drupal and how we work with Drupal, perhaps one of the bigger ones that we introduced in recent years. So this phase obviously still needs work. We are however targeting 8.4 for a very minimal experience of some of this functionality. So we're making a lot of progress here already. And this will be a big, big focus in the coming weeks and months getting work on this. Peter. Are you gonna come back to the mental model? Or to the mental model? Yes, yes, absolutely. And then the very last phase, phase age. We're gonna deal with conflict management of parallel changes because when we introduce all of these moderation capabilities and so on, there's, we enable content editors to be very productive. That also means that they will start stepping on each other's toes if we have multiple workspaces, perhaps branches of content changes that are being done. So we need to empower content editors to collaborate and solve conflict. So that's a big phase. Lots of UI complexity. We're gonna look into what we think that, some of these, how we can solve some of these problems. This phase has ultimately, we haven't started coding on any of this yet. So before we dive into more detail of the mental model there and about workspaces, let's just summarize a little bit what the functionality we're looking at here are. So we wanna make revisions of all content. That's something we want the end user to be able to do. We want to be able to moderate content packages, groups of content together. Existing tools within Drupal today allows you to moderate single pieces of content. That's not enough in this case. So moderation of content packages. We want to be able to review content packages under deletion of content, of any content, and collaborate with others content packages or others work. So this is like the big picture of what we're trying to enable within this initiative. Sounds basic for a content management system. And some of these things is obviously not there. Again, a brief overview. So we've removed a few phases and merged them together. So at the moment, there's two green, two yellow. Looks pretty good, I think. We've made a lot of good progress. Phase B is currently postponed and phase H outstanding so far. All right, before details, let's just cover some of the lessons learned. Again, we talked about this in Gabor session just before here, but we found it pretty challenging to do experimental modules that needs very deep integration with Drupal. Experimental modules is a great way of adding new kind of separate functionality. But we've found ourselves having to rely on the traditional core contribution or core governance model for making these very big and sweeping changes. And that's still slow and hard. It takes a lot of work. So our new governance process and our new experimental module process doesn't necessarily have a solution to making these deep sweeping changes, touching the entity API, touching the translation API, data storage, these kind of things. So that's a lesson learned. We can still improve there, I think. And again, I mentioned this already, surfacing existing bugs with stable code. What's stable and experimental and the timelines here when it comes to the experimental governance process, that's still maybe there's a bit more discussion that we can have there. Also, introducing new dependencies to or during the experimental timeline for a module is also posing some challenges. So we introduced a workflow module in 8.3. The generic governance model says you have one year to make it stable. But because it's now a dependency of content moderation, we've only got six months to make it stable because content moderation needs to be stable within its one year cycle. So there's some lessons there that we perhaps could learn something from. And we still rely on very few core framework committers. I think they're doing a great job. But our community's productivity has gone up quite a lot during our eight cycle. And although we've added core committers, we haven't necessarily added core framework committers. Again, going back to that first point of doing deep integration change into Drupal, perhaps we can look and learn from some of these lessons here to further increase productivity within our core process. And the very last point that I'd like to make despite some of these lessons is funding core development actually works now in Drupal 8. We can be very productive and we can see change come through. And that hasn't been the case previously. So it's been a great experience. I think that we, again, we can do more but I'm very glad to see that we've done some sweeping changes and actually funding developers to work in core, specific areas, specific initiatives. It's been a great, it's been a good experience. All right, let's dive into a little bit more detail. So I'm gonna focus on two phases, phase C and phase G. Phase C is content moderation. And this is not all issues that we need help and we're still working on, but it's some highlights of issues. So we're working on enabling workflows on entities without bundles. Quite a lot of technical terms here, but again, this is core conversation. So that's an important one that's sitting. There's quite a few or two or three tricky bugs when it comes to forward revisions with translations that we're still tackling. And a big area of discussion has also been the entity form save button. So the button and the design around the interface where you save entities when it comes to moderation states and so on. I'm not gonna dive into details of these issues, but if you are interested in contributing and helping out, please take a look at those issues in the issue queue. One other thing that I wanna highlight with the content moderation module is the improvements, the UX improvements that we've done. So we have the very first or the old user interface and the new. The video is a bit small here, but the point I wanna drive across here is the speed of which you will get your work done configuring content moderation. So essentially both sides are performing the same task. You'll see that it's a much better experience and you'll get your work done configuring transition states on the right side. On the left side, the old interface, you have to switch between pages, go back and forth. We're being a bit more in line on the right hand side, making it a lot easier for site builders to get their work done. Making a good use of the models, the model windows. On the new side, we're already done. In the old user experience, we're sort of still switching between pages, switching between different structures within the administrative user interface, going back and forth. So that's good, right? That's good. It's a much better experience. Thanks, Joseph, for making many of those improvements and suggestions. All right, that's content moderation. Let's talk a bit more about work spaces. And again, this is one of the primary goals of the initiative. So I wanna spend some time here really explaining this concept and trying to get people to understand how we intend for this to work. And again, it's the perfect time to get everyone's feedback on these things because we're still in the very early phases of doing this work. So before we dive into this, who are work spaces for? Who are we designing for here? So the first role is obviously our content editors or even the primary role. We talked already a little bit about the stories that we wanna enable here. So obviously we want to be able to moderate content packages, groups of content. And we want to be able to publish that content, that content package as a whole and review that at the same time. And then collaborate with other parallel content packages at the same time. You might have multiple editorial staff on your team, parallel changes going on. So that's sort of facilitating that collaboration is important. Secondary role is obviously the site builder. We want to enable configuration of workflows, quite obvious, and configuration of moderation states. But again, the first line there on the content editors, that's really the primary audience that we're dealing with here. Okay, I'm gonna try to explain what a work space is. I'm gonna do so by having three work spaces, three content packages that are being worked on at the same time. So we've got the live workspace, the live version of your site, the visitor see when they come to the site. We've got three changes going on. One introducing a new product out on the left. One editorial staff might be working on an upcoming event and then there might be last minute fixes to the upcoming event. So we've got three parallel changes going on here. New product and upcoming event. There are sort of copies of the live workspace where live is the upstream. The last minute fix that's being worked on has the upcoming event as it's upstream, all right? So it's the last minute fix to this upcoming event. You can see here how you can pull down updates from your upstream workspace and how you can obviously push additions to your upstream workspace as well. One scenario could look something like this. So we start at the very left. We want to make a change, we want to make any type of change, maybe that new product that we looked at in the beginning. So the first thing, the first step that you're going through is that you will create a new workspace. In this new workspace, the third step too will be to create, change, or delete content, making your changes. Third step would be to review those changes. Before you're doing the review, you probably want to pull in updates from the live workspace or from the upstream workspace just so that you have a fresh copy of everything, all right? So you pull in those updates, potentially resolving any conflicts because there might be conflicting changes going on in the upstream workspace, right? Once that's done, you can go through the review, the review of the entire workspace. So we're not thinking about individual pieces of content here, we're moderating and reviewing the entire workspace, all the changes within that workspace. And then if you don't pass the review, obviously you go back, make the changes you want. If you pass the review, you can do one last pull from the upstream workspace and then publish your whole change set. So that's what one scenario could look like. So what we're gonna look at now is some prototypes. So I'm gonna switch to the browser. So these are our prototypes, this is not, oops, you don't see the prototypes, that's quite helpful. Here we go. So what we're looking at here is not a fully working Drupal site, obviously, this is prototypes. So we're looking at a Drupal site. We are in a workspace that in this case we've called product microsite updates. So we've done some sort of updates to part of the website. We can open up the toolbar, where there's a lot of things here and we'll go through this. First of all, we can look at the current workspace. So we have some information about the current workspace up here. We can click on manage this workspace just to get a better understanding of what's in this workspace. So in our microsite updates here, we can get a good summer of where this workspace is at. So we can see all the changes that has been made. So 76 nodes, 12 users, five main menu items have been changed in this workspace. In this change set, so to speak. And get a list of all the changes that was done here. Further, we can switch between workspaces. So we're in this microsite updates here. A different team might be doing changes separately. So we might have a new news article workspace here. So you can see we can switch between these workspaces. And as you can see, the site obviously looks different because there are different content changes going on. And again, workspaces is a full copy of your upstream workspace. We can then take actions on these changes. So let's say that this workspace, which contains new news articles, we can deploy this. So let's go through what this looks like. Because this workspace is currently ready for deployment. So we've applied moderation states to full workspaces here. So this workspace is already reviewed. It's gone through some moderation. And it has the status ready for deployment. So we can hit deploy to production or deploy to live. We can add in sort of a message here just to describe the change. And then we can deploy to live. And what's happening here is that we're updating the workspace from upstream. We're checking for conflicting changes. And then the last step is with deploying to the upstream. So after that process, your changes has been brought live so that your visitors can see the changes. Back here. So we can also get a better overview of everything that's been going on on your site. So there's quite a few changes going on here. Multiple teams working on multiple changes. So this is an overview of all your workspaces. We can filter workspaces based on their state. So we can say, I only wanna look at the workspaces that are ready for deployment. That's already been reviewed, for instance. We can preview these workspaces and switch between them. And we can also search for specific workspaces based on certain keywords. So filtering capabilities here are important for changes. Very busy, busy sites with a lot of changes. And another thing they can see here is that there is a notification up here. Again, facilitating collaboration between various teams. We can see that there are seven changes that you might need to pull down from your upstream workspace. So let's do that. We see that we have seven changes here that's already been going on in live. And in order to get a clear view of what your site will look like before you go live, you need to pull down those changes. Quite similar to a Git workflow. So before you push your Git changes, you have to always pull down the latest changes to resolve conflicts. So you can't just push anything without having to first solve the conflict. So it's your responsibility before you go live to push those. That's a question. So the question was, when I say live, is this within one Drupal environment or we're talking multiple different servers or physical separate instances? This is all within one site. So that's a good question. What we're talking about here is workspaces within one live site. So workspaces exist in parallel on a single site. Something that we haven't touched on here which is not within the scope of this initiative for Core is you can actually have workspaces on separate sites as well and deploy between those. That's a separate session. There's one more question. So the question is if this handles both content and config, we only do content here. There's a very strict separation between content and config. So only content. So again, let's go back to the example here. So we have seven changes in the upstream workspace and we can simply click on the update button which then pulls down those changes to your workspace and your workspace is updated. We no longer have a notification there and now we can do a full, clean review of what your site will look like before it goes live, right? And it's the same process that we're going through before we actually do the deployment. Every deployment always includes like that update pulling down the latest changes. Another scenario, which is quite important, talking, oh, we have a question. Yeah, sorry. Can we assume that in this, with this enabled, that you will always use a workspace? You'll never like actually make a change in line? Yes, the idea is that every change should be separated in a different workspace. You don't have to necessarily, but it's certainly encouraged to do so. All right, let's look at another scenario. A scenario where you have a very busy site. There's lots of changes going on at the same time and there might be conflicting changes, right? That's quite a tricky scenario to deal with. I'm just gonna go back to the beginning here. So we have this workspace. We've done a bunch of changes here. We wanna get this into the production workspace or the live workspace. So we're gonna deploy this to live. The first step we're doing is that we're pulling down updates again. So pulling down updates. Then we're checking for conflicts and the process stops here because there are conflicting changes that someone else has made in live or it might be another workspace that has already published changes that are conflicting with your changes. So during the process here, it stops and it will ask you to resolve the conflicts. So we'll do that. And that brings you to a separate interface here. So in this case here, we have three conflicts. First conflict is in a menu, in a menu item and a menu link. A menu link is quite tricky to visually preview because your menu might be in multiple places on your site. So in this case, we're only sort of giving you some metadata. So we give you the revision and the actual link that's been changed. And here you can pick which one you want to keep. So either your own or the production version. So let's say we pick one. And then obviously you need to here, machines can only do so much. So we can't magically figure out which version you need. So ultimately, you'll have to knock on your friend's shoulder and actually ask which one should we have. So machines, we can't solve all the problems here. So there needs to be communication here as well. So talk to your staff who's been making the conflicting change. Decide on which one we should have as the version right now. We go to the next conflict. So in this case here, this is a node. So this we can actually visually preview. So we have first of all a basic version here with like a preview of the text and some metadata. But let's say that might not be enough in order to make a call on what version we want to use. So what we can do here is that we can preview the local version, which below gives us a preview of this particular version. We can go up or preview the remote version where we have a change title for instance. So again, you see this user interface sort of sits on top of your site because we're not really within a workspace here. We're operating on top of the site a little bit. Does that make sense? So again, we can preview the different versions of the site here, pick a version and then go to the next one. Again, this is a block. A block might exist on multiple instances in your site so we can't easily visually preview this. I think there's a question on there. Very good feedback. The author field should definitely be in there, right? That's very good feedback. So back to the custom block, we can pick a version and now when we've sort of resolved the conflicts here, we've picked what versions we should actually go with, we can continue with the deployment. That brings us back to the last step where we're actually deploying and that has then made the changes live. So the question is when we've got to that point of picking the conflicting versions, if I decide to cancel instead of going ahead, what happens, like how far in the deployment have we gone? So the good thing with this design is that your conflict is always resolved within your workspace. So you have to solve all conflicts. You need to be completely green within your own workspace before pushing anything live. And it's the same with those of you who work with Git. You need to resolve fully your conflicts locally before you promote any changes upstream. So you can back out and you haven't done a single change to production. So that's a workflow of going through conflicting changes. As relatively simple as that looks, I can tell you that there's projects that we've done where if they could, the client would choose to not be allowed to experience a conflict. So when you go edit something, it says no, it's already been changed by someone else or blocked or something, do you know what I'm saying? They'd rather be prevented from ever encountering a conflict than having to resolve. Is that something that you could enable as a choice so we have details in the user interface to sort of perhaps help you a little bit with this. There will always be conflicts. So when we sort of enable or want to improve productivity of our content editors, there's always gonna be conflicts. So there's no way of avoiding that. But we can do smart things in the user interface to facilitate communication or facilitate collaboration in order to avoid as many of those scenarios as possible. So if I go back here, so for instance, the notification up here seeing that you have 28 changes upstream, don't let that number grow too big because that means that you probably have a lot of work to do in order to sort of fix that. We can also then say, do smart things in the user interface here as saying this workspace here, the text is a little bit smaller for the demo, but this workspace here, it already says here that there's five conflicts in this workspace. So it probably needs some attention, right? So switching to such a workspace, you'll get clear visual clues here of what's going on. So workspace status, there's conflicting changes here. We will never be able to sort of neatly walk around and avoid conflicts, but we can facilitate collaboration in the best possible way. Jonathan. So the question is the conflict resolution process, could that be smart enough to be on a field level? So the plan is, I was gonna ask more or less the same thing, but even within a field, I mean with code you can diff by line, right? And can I pick which of the two changes I would prefer? So the initiative intends to make the conflict resolution part pluggable. So you could have a pick a winner, or you could have within merge systems or branching systems, there's something called a four-window three-way merge interface where you could help the user to make a manual three-way merge. There could be a fallback to that process being an automated three-way merge. We've already started experimenting with that within the initiative, introducing a merge library that can actually like a PHP library that can do three-way merges. It's based on traditional lowest common ancestor merge functionality. So we could do a user interface that actually attempts to automatically solve your conflicts for you first with a automated three-way merge, but in the case that the merge doesn't work, then bring up a user interface to say, a human needs to help here. So to answer your question shortly, yes, we can definitely do that. So this is one of the repositories that we within the initiative own and develop as part of this. Yes, let me bring up the, here. We have a question at the mic here first. So step up to the mic so that the questions are recorded in the screencast layer. Yes. Have you thought about the permissioning around workspaces and multiple users utilizing one workspace or is there any? Yes, we have been thinking about that. There's still a lot of details to sort of figure out there, but at the moment there's basic access management around that, probably a lot more we can do. So these are ideas and feedback that we gladly receive for the initiative, so we take the right calls. Okay, so my question is related with his question. How do you get workspace to work with workflow moderation? When you need like a high level of moderation, you know different states going through. Before that content is deployed to life, so what is the plan for that? Is it a way to integrate it? So the idea here is that we don't do any moderation at all on individual pieces of content. We always do moderation on a workspace level. So because end users very rarely think about changes as a node or as an article as a single page. I've changed my website. That's the mental model of most end users. They'll say, hey, Dick, I've made a change to the website. Can you take a look at it and deploy it? They won't say, I've made a change to this block and that node only, can you, and that menu link? It's, we moderate a whole content package. So the moderation states are then applied to the whole workspace. So I can go in and manage the workspace. I can change the moderation state right here. You can see that there's an edit button here. Or I can go in and change the moderation state of this workspace on the back end here and switch between moderation states here. And this is then, this applies to the whole workspace. So all the changes within workspace is then moderated this way. This sort of removes the element of it. Joseph. You can help me for a minute. Just step up. So Joseph is the designer behind a lot of these concepts. Yeah, I just want to add that you can have different workflow types. So there can be a workflow type for managing content individually, but you can have a different workflow type for managing workspaces with different states, moderation states and transitions. Yeah, so if you would like to do moderation on the individual piece of content within a workspace, you could do that. It's probably simpler to just have moderation on a workspace, but we're not making any calls here. It's still up to you to sort of configure if you want to. The idea is to empower the end user to do more of these things. So creating a workspace, we don't have that in the mock-ups here, but creating a workspace is done by a click of a button which gives you a clean slate to work on where you can do all your changes without having to care about knowing what's a single piece of content and so on. So the purpose is to make it easier for the end users. That's the primary audience that we're trying to make it. Of course, you need to understand the concept of how a workspace works, and that's why we do a lot of communication around this and that's why I said this is a bold new mental model that we introduced to end users. It's a reimagination of how Drupal works that we're introducing here. Peter. Question, you mentioned configuration before and a separation between configuration and content. Do you, within the workspaces, block all the changes to configuration entities and simple config, or how do you prevent someone from thinking they can change a view radically, let's say, within the workspace and have that go live? Very good question, and there's been a lot of conversations around this, not to have confusion in this space, right? So one of the proposals is that when you are in a non-live workspace, so let's say we're working on our product update here, when you're in a non-live workspace, we disable any form of config changes. So very much like config read only, but in a non-live workspace, which means that the user have to go to the live workspace in order to do any config change. It needs to be explicit and that way the user will understand that any config change that I'm doing right now will be in live because again, we're working on a single instance of the site here. If you wanna separate that workflow, then you'll need two instance of the site and then the problem becomes a lot more complex, but there are some ideas of disabling config changes in non-live workspaces, because if we let people do config changes in non-live workspaces, the user might think that, okay, these config changes is only locally, right? What about hooks that can fire in non-live workspaces and email notifications and all of that? Now you're being so complicated, Moosh. Yeah. Yeah. Yeah. Good question. We don't necessarily have it. Yeah. They will run or they will not run. Yeah. Yeah. Okay. Gabor. So hi, so just wanted to add some anecdotal evidence to try to protect people from making conflicts, because we've hit a critical bug with content translation and content moderation states, where if you make new versions of content in one language and you're trying to do a different new version in a different language of the same content, then they may clash due to the moderation state storage system and the current proposed stop gap is to stop you from being able to making those changes. So you go hit the edit button and it tells you, no, you're not allowed to edit this because of this and this. And we've got a lot of people freaking out on the issue because it does not match their idea of what should be allowed to be done. So I think where we've hit this problem and we hit it hard and we tried to use this as a stop gap, even then it was not very positively received. Are there more questions? User case that we wanna have scheduling, but we also want to have content moderation. I was wondering if there's any plan to integrate those two. So when you wanna have content moderation and... Schedule. Scheduling. Ted, where are you? He's not here? Yeah, so there is work being done on this. It's being done outside of the initiative, but scheduling is certainly something that a lot of people are thinking about. And I suppose the goal is to make them work together. Yeah. Yes? First of all, to say seeing this kind of evolve from deploy in Drupal 7 and then the suite in Drupal 8 is amazing. It's really wonderful stuff. I was curious with the relaxed services and communicating between multiple environment. Is that something that's gonna stay as kind of a contrib space for the time being? For the time being, that's gonna be staying in the contrib space. The conversations that has been within core is that that's not an 80% use case. The people, we who are involved in the initiative, it's a primary use case for us, so you could quite fairly accept that that's always gonna be a sort of part and that's always gonna stay up to date with this. So that's, for now, it's gonna live in contrib. And then just kind of a follow up to that. It seems like another possibility with at least a subset of these modules is multi-site sharing content. So the conflict stuff, merge stuff, even the workspaces and then deploying those to a completely separate site and having the UID stuff, just having that pluggable and allowing the contrib space to work on that. Tons of potential there, so it looks amazing. And one other piece is, I can see this solving a lot of problems with, say, entity references to media. Okay, is the media, are we tracking revisions against the host entity or is that living in its own state and instead just having a global workspace to store kind of those revision changes that you can push out once is amazing ideas, so really great stuff. Yeah, thank you. There is a lot of work in that sort of space in thinking about content as a service. There's been, there was a session yesterday and Dries yesterday posted a blog post. We've made some very intentional design decisions with the system when it comes to the API and the protocol that we use to push changes which enables some very interesting use cases around sort of central content management, content hubs and so on. Watch this space, there'll be more coming, that's for sure. A part that we're working on as well. Yeah. So sort of a follow up to the config moderation or the config changes in workspace and it's probably outside of the scope of the current initiative but have there been discussions about revisioning everything? Like so you could change the site title or you could change layouts or a view page title or things like that. So there has been, I think there are some very early stage patches in making config revisionable as well. Certainly within the initiative, our goal is to make every content that is revisionable to start with. There's been discussions within page manager and panels to make all of that revisionable. Obviously site title would be config. Yeah, there are discussions around it, nothing sort of concrete at this time. I wanna finish off the presentation here. We're just showing a different prototype that includes some animation, a bit more eye candy of what we intend the final product to be. So to sort of reinforce this mental model that workspaces are entirely separate from each other, we worked a bit on the user interface on sort of how it could work and look. Sort of swiping the whole workspace to site to really understand that this is not individual changes. This is an entirely separate copy of your site and we have multiple of those. So there are some quite nice sort of visual clues that we can help people with in understanding this. So this is just an animated prototype in switching between workspaces and different changes and the toolbar here on top. So this is the final product that we sort of envisioning. For 8.4, there'll be a minimal experience of this coming in, but then 8.5, 8.6, we're gonna sort of grow this user interface. Another question? Yeah, well, to me. Yeah. Fixing conflicts of conflict changes. It's whoever gets into the upstream workspace first, wins and then the other person will have to solve a conflict on a conflict on a conflict. That is most of what I had. Let's switch back to the presentation for a moment.