 All right, I think we can get started. How's everyone doing? Welcome, everyone. I will be giving an update on the workflow initiative here today. More specifically, we'll be looking into the background, some of the goals of the initiative, brief overview of the plan, some lessons that we've learned along the way, and we're going to look a bit closer at the workspace module. I do want to try to leave some time for Q&A at the end. It's a very short session here today, so I'll try to keep it swift. First of all, I just want to sort of highlight the funded initiative team. We have some, if not all of them in the room here. We've also got some great contributors to the initiative here. So say hi to them if you bump into them. I also usually like to thank some of the kind of founders of some of these ideas in contrib from a long time back. Hey Rocker, Agent Rickard and Dave Hall all been sort of contributing with some of the fundamental ideas that all of this is based on. Nine years ago, Greg Dunlap started on working on some of these things. It's a long time. I also want to give a special mention to Rakesh Verma. I don't think he's in the room here right now, but he was a Google Summer of Code student last summer. He also contributed to the initiative. If you see him around, do say hi. He worked on some of the merge algorithms for conflict management and so on. Moving on, it's been a long way coming. Proposed these kind of ideas all the way back in Denver 2012, so that's been quite a few years. The workflow initiative, we were the first approved initiative after the 8.0 release. We take a lot of pride in that. That's pretty awesome. What we're trying to achieve, some of our goals are really efficient and accurate content workflows for the content editors. It's kind of the persona in the middle that we're trying to make things easier for. We want to do that by enabling moderation of content as well as full site preview. So the ability to preview your changes before they go live, essentially. Again, there's been a lot of work involved here. We spent, what's it, 2015 or 2016? Time in Amsterdam with Boyan, Roy and Joseph. What's it? I think the end of 2015. Flushing out all of these ideas, and that's where a lot of these concepts came to fruition. Not going to cover all the phases of the plan. I'm going to cover a few specific phases of the roadmap. You can see the whole roadmap on the Drupal.org issue on the screen. We'll start with phase A. So the very first phase was really to start using the excellent revision API for more entities in Drupal Core. It's really leveraging all the capabilities that we have. There's been a lot of work on underlying APIs, the upgrade path, such a big issue that Andrea was fighting with for a long, long time. We've introduced base classes and interfaces. So this was kind of a foundation for all the work that was going to be ahead. So we've closed out, successful on phase A. So that's been a long way coming. We're jumping a few steps to phase C, which was all about content moderation and the workflow modules. And as many of you might know, both of the modules are stable. Well, content moderation is hopefully being marked as beta soon, but it's stable code. It works well. Workflow module is definitely marked stable. Challenges throughout this phase of the initiative was uncovering a lot of long limitations and bugs at the very heart of Drupal Core. So we've done amazing, amazing progress there. So we consider ourselves more or less done with this phase as well. Again, jumping ahead a few steps. Phase G is currently where we're at at the moment. We've jumped from C to G. It doesn't really make sense, but anyway. Hear me out. This phase will be all about introducing really our... We'll start touching at the capabilities that we're most excited about. Enabling full site preview. We'll do this with the workspace module. So this is a quite bold new mental model of how content editors work with content in Drupal. And as I just mentioned, this is where we're actively doing a lot of work at the moment. So this will be our focus for the current release cycle. We'll dive into more detail of what workspace module, what it looks like and what it really means. We are targeting an experimental module, sort of the minimum viable product for 8.5. So the time is already ticking. We already have patches with a lot of passing tests, still a lot of work to do on the user interface and so on, but we are definitely getting there. Again, we'll look at that in just a moment. Before we get there, just want to go through some of the lessons that we've picked up along the way in this initiative. So it's all the initiatives that are currently going on in Drupal. They're quite different. We've faced quite some challenges with running iterative improvements on something that touches the very, very heart of Drupal. When it comes to our content model, content storage, touching APIs, that is very, very tricky. So that's been a great challenge. Not necessarily anything we can do other than improving our APIs, better interfaces and so on and so forth, but it's definitely been a challenge. Again, surfacing a lot of existing bugs with kind of the code itself in the modules that we've developed, that code is stable, but with surfacing bugs that's been existing for a long time. And that's sort of affected our productivity in writing these stable modules. So that's how do we judge kind of the release cycle and stability of the modules when the modules are stable but the surface kind of bugs somewhere else. That's tricky. Maybe we need to do some more work there in release management. Also, changing dependencies within a release cycle. That's been a challenge as well. Halfway through we kind of introduced the workflow module. So that changed things for content moderation, which proved to be challenging. And one of the things that we've also picked up on, we rely on too few core framework committers. I know that Jess and the release team is already ahead of us here. They're already working on sort of closing some of the gaps there, but we've definitely seen that. We have a very productive team and we've sometimes had issues sitting in the queue for a long time. It's no one's fault. It's just how the process is set up. But I think Jess and the team is already ahead of us there and working on getting more core framework committers. And perhaps the most important lesson that we've learned is that funding core development kind of works. With Drupal 8 and this new release cycle, funding core, funding work on core actually makes sense because we can work on something and we can actually have it in core released within six months. That's kind of amazing. We never had opportunity before. So the company I work for, we fund the workflow initiative, at least members of it, to a great extent. And that's working. We've seen good return of the investment. So that's a very good lesson and perhaps more companies should pick up on. But still, how the process is set up at the moment with experimental modules means it takes you six months to get an experimental module in, but then you need to stick around for another six months to get it stable. That's fund one or two developers for a whole year. That's not a small commitment for a company. It makes sense for Drupal shops or for Acquia and companies that make a living out of Drupal. But for a company that is an end user of Drupal, that's a big commitment. And we need more of these kind of companies to really chip in at funding core work. So perhaps we need to rethink how we can do that to make that possible. Funding a single core developer for a whole year, that's anywhere between $150,000 to $200,000. That's a lot of money. So maybe we can work on making iterations even quicker and cheaper somehow. Let's discuss how we do that, I'm not sure. All right, let's talk more details about workspaces. First, who are they for? The primary audience here would be our content editors, who moderate content packages. We're kind of moving away from this model of moderating a single article, a single piece of media, or a single piece of this and that, to moderating whole packages. We want to be able to publish those content packages, obviously, and collaborate with other content editors on moderating and changing those packages of content. So that's kind of the primary audience. The site builder, important here, right? That's essentially the audience to configure these workflows and to configure all the moderation states. So those are the two central audiences that we work. So what is a workspace? How does it work? There's a mental model here. A workspace is kind of a collection of content, right? So you have the live workspace, which when you visit the site, that's kind of the workspace that you see. The anonymous visitors coming to your site. But then your editorial team can then create new workspaces. In a particular workspace, they might work on adding a new product with additional media, so on and so forth. While in another workspace, they might work on an upcoming event and kind of extending from that workspace, there might be another workspace that work on some kind of last-minute fixes. So it's containing all of these content changes into separate workspaces. And you can then kind of pull down updates from the live workspace, push them up, update and so on and so forth. A particular scenario might look something like this. So at the bottom, we have the live workspace, kind of what the anonymous visitors to your site sees. And on the upper row, we have a workflow where a content editor might be working on some changes. So he sets up and creates a new workspace. He is adding and changing and deleting content in step two. In step three, the editorial user will review the workspace and moderate the whole workspace. So we have a moderation state on the whole workspace. Not on individual pieces of content, because kind of the mental model of content editors is they made changes on their site. They want to preview the site. They don't necessarily know or care about, this is a particular entity, this is a media entity, this is a block, this is an article. They made changes to kind of a section of the site and they want to preview that. And in the process, they can kind of pull in changes from live, as we see there in the middle. They pull in and update the workspace with sort of upstream changes. And then it can be this review process. So it might pass review, legal review, whatever it might be. Go back to step one and repeat. But if it passes review, we're on to kind of past step four. Then the last thing you might do before you push the content to your live workspace is you pull in the latest changes. Like we do with Git, before you push your code, you need to pull down the latest changes, resolve any conflicts before you push. So if you're a developer, you can kind of compare this quite a lot to how you work with Git branches, let's say. A workspace could be seen as kind of a branch of your site, if you may. Let's look at some wireframes. So this is... Let's see here. So this is wireframes. We have a simplistic version of this user interface in Contrib already working. This is a more elaborate user interface. The intention is here to get this user interface into core. It's probably part of this user interface will be now in 8.5, hopefully. But the idea is to have a more complete version of this user interface in Drupal 8.6. The fundamental bits and pieces here is being moved partially in from Contrib into core. We have a lot of these pieces working on Contrib already. So let's take a look at this. So we have your regular Drupal site here. We're currently in a workspace with an arbitrary name, the product microsite updates. We might have part of the site has taken some updates in this workspace. So we can kind of bring up this user interface at the top where you get an overview of the moderation state of this whole workspace. So we can see that this particular workspace is ready for deployment. So it's gone through review already. Again, I want to emphasize the fact that this is for the whole workspace. So all the content in this workspace is considered to be ready. You can switch back and forth between your different workspaces here. So you can go to any of the workspaces and sort of preview them. But if we're happy with this particular workspace, then we can move on with the deployment here. Before we do that, we can look at some other features here. So we can view all the workspaces on the site. So here you can get an overview. You'd be able to filter for workspaces that have changes that are ready to go live. You could search for names of workspaces to filter out kind of change sets from various teams. And that gives you kind of a good overview of all your workspaces. So let's go into the deployment workflow here. So essentially what you do, you press deploy to production. You can give a deployment message, kind of a change log message here if you want. We will go ahead and push to live. So it'll start go through the deployment procedure here. So what we can do is that we're checking for conflicts before we go live. So before we push anything, we pull down changes from the live workspace like we do with Git. We check that we can resolve all the conflicts. And if there are conflicts, then we get a message, something like this. What you need to do here then is to go through like a conflict resolution scenario. So Rakesh, he just entered the room here. I gave him a shout out. So he's been working on some of the conflict merging which is kind of allow automated freeway merges. So give a shout out to Rakesh. So this code is not folded into the modules yet, but all the libraries are there and it will be sort of the foundation that we will build on to make some of these things possible. And I need to unlock my computer. There we go. So resolving conflicts. This is a very simple user interface. This user interface would be pluggable. So here kind of the conflict resolution scenario is just pick one or the other. But if we use the libraries that Rakesh coded, for instance, then we can do much more clever things with freeway merges and have complicated diff interfaces if we want to. So this is a very simple user interface. We can just pick a version. So this is a menu item that is conflicting here. We just see the metadata because previewing a menu link might be difficult. It might appear in different multiple places. So we kind of do a comparison here on just the metadata. Next up is a node. So this is the second conflict that we have. So here nodes or content, those are easier to preview. So here we can preview the local version or the home page edit version. We can compare the version that's in production. Kind of make a decision here of which revision is it that we really want to keep. We pick the one that we want to keep. We move on to the last conflict, which is a block. Blocks is also difficult to preview because they can sort of appear in different contexts in different panels or sidebars or whatever. So best case here is probably to just review the metadata, pick one, and then continue with the deployment. So now we've sort of resolved all the conflicts and the deployment is then in the production workspace. And I want to emphasize here is that all of this is happening on the same site. So we're not moving content between different servers or between different virtual hosts. This is on the same site instance with multiple workspaces. In scenarios where in a more enterprise scenario you might want to have different virtual hosts, then there will be, or there is already, a module in contrib which makes it possible to move content between workspaces on different server instances or different virtual hosts. If you have your editorial environment behind a corporate firewall or something like that. All right, we can explore more of the user interface here. So the simpler scenario, if we go back to the beginning here, the simpler scenario is just deploy to production. Oops, I want to show I picked the right one there. Let me back up. So just deploying to production without any conflicts. Obviously very straightforward. We check for conflicts, no conflicts. And the deployment just goes to life immediately. That's kind of the simpler scenario. We can dive into more detail here. We can have an overview of your workspace. So this, now we're looking at the production workspace here. So there's no workspace changes. But if we go back... Joseph is... It's better at navigating these wireframes than I am. But here we go. So here's the overview page of a workspace. So this is kind of, you can view metadata about this particular workspace. You'll be able to see the target workspace kind of when you click the deploy button to what workspace does it go. You can change the moderation state here as well and you can then get a summary of all the changes that's been happening in this workspace. You could potentially then also compare each revision and so on and so forth. So that's a brief overview of what workspace is and what it looks like. So we have a simplistic user interface for this already in contrib, but we are evolving that as we go into core. All right. Let's move on. We're slowly running out of time here. You'll find the workspace roadmap on the issues on Drupal.org. A lot of work in the next couple of months going on here. So take a look at those issues if you're interested. And that's it. I think we have a little bit of time for questions. So please step up to the mic if you have any questions or comments, concerns or feedback. Does it look good? Does it make sense? Yeah, it makes sense? I'll ask a question. Would most people see themselves using workspaces on a single site or kind of across different hosts? Let's say if you have a stage host single site, hands up, across different hosts, it's kind of half-half. So it might be... Yeah, server load perhaps, but also security. You might not want to have your editorial team logging into production. You might not want to manage 50 to 100 editorial user accounts on your production instance. So maybe you want to have an editorial environment separate, and then all you need to do is manage a few user accounts in production and you deploy through a corporate firewall, let's say. So that's one use case. Then you can probably iterate faster, iterate quicker perhaps. If you kind of decouple them, you run a little bit less risk on maybe if you want to make changes to particularly the editorial environment. Another use case is also... This obviously works well because your changes just affect content. But if you have a content package that needs to go along with, let's say, configuration updates, then this scenario becomes a little bit trickier. Question? Step up to the mic, please. Can you schedule deployments? It's not something that we have planned for core. That is a very frequent question, however. There are, I think, Ted, he's backing up in the queue there. He's been working on scheduling features, so there's definitely solutions for that and the intention is to make them work well together. So go to Ted with any questions. Scheduling is, however, tricky when you run with multiple workspaces, multiple change sets, because the very last thing you need to do before you push anything live is to pull down updates and resolve conflicts. So what if there is conflicts when you're in bed sleeping and you want your content to go live, then we have to stop the deployment there because there's conflicts. Scheduling is a bit tricky, but with automated three-way mergers and stuff like that, we can kind of... We have content that has to go live on January 1st, one minute past midnight. The best option is probably to have one of your editorial staff to sit there because there might be conflicts at that very last moment. Can you manage a schedule such that you can assure that there's not going to be any conflicts? The government employees, so... No, they won't be there. I am also a government employee and I do have to be there at midnight. It looks really good. I know some of the others in my team would be keen to know if it also includes files in the package because that's a really big thing for us. The things that we publish can move the financial markets. So if someone would link to an unpublished version and a published version in the same package, would that be the sort of thing that would come up? We definitely support files. That's a very core use case for us as well. If we don't publish quarterly reports or then at the proper time and the files aren't included with the package, we'll be in a lot of trouble as well. So files and media is definitely supported. I agree. It looks really great and I would love to see it happen as soon as possible. Do you have a sense of how much work it is? Is much of it already done? A lot of work. So the basic question is do you have a very rough time frame? Do you think it's doable to get it as 8.5, beta and 8.5? So we haven't talked alpha versus beta but I have a feeling alpha in 8.5. We only have, like the release cycle says if we can't stabilize it within a year, we're out. So we kind of have the... I think we're going to have conversations around the year time frame. But definitely we want to have something in core for 8.5. So as Drupal has the CMS and looking at how it compares to other systems like what other proprietary or open source products have something like this and how does this compare to that? It's very different and most of the proprietary CMSs they sort of leave everything up to be very configurable. It's very different to set it up. So we've done a lot of comparison but there isn't a lot of things like this really. It ends up being different virtual hosts. I just got a point that we only have one more minute. So quick question. Okay, I have two quick questions. One is when you have this conflict resolution can you make an additional... like an additional change like an additional revision during this time? Because if you like... Merge, yeah. And the other one is to what degree do the conflict have to align and do you have some sort of measure to protect? Especially when you have like several instances of the site where the conflict can be different. So do you protect their align? Yeah, so first question. Yes, we can create the additional revision. It'll be up to the plugin to sort of implement the user interface and update the relations as you need to. Is that already like the stable... No, so none of the conflict stuff is implemented yet. Second question. Config super hard. This will not solve that for you. You need to have a staging environment, kind of a feature branch workflow spin up on-demand environments too. The question is do you have a measure to see if the conflict is aligned? Like, if you have another field there and nothing the other one, do you measure this in a way? Nothing at the moment, no. All right, thanks everyone. Yeah, thanks. So... Yeah, I know, we're getting there, we're getting there.