 Rydyn ni'n meddwl'n chi'n gweld, mae'n 12. Rydyn ni'n meddwl y Workflow Initiative Core Conversation. Felly yn fawr o'n mynd i'n meddwl eich conversaion yw'r bydd. Felly, i wnaeth ymdweithio, rydyn ni'n Myllwyr Tim Millwood. Rydyn ni'n meddwl i'r newid, a rydyn ni'n meddwl drwpl i'r mynd i'r gwirionedd. A rydyn ni'n meddwl i'r Workflow Initiative. Rydyn ni'n meddwl i'r meddwl i'r wath, roedden i wneud. We had a UX sprint in Amsterdam in June and there we looked at a lot of the different concepts that we're bringing from contrived modules into core and the UX issues with them and things that we should look at. The main areas that we looked at were the content moderation, the undo or the trash functionality and workspaces and how workspaces are going to work and what they do and what they are. So we came up with a workspace concept model and this just tries to explain what a workspace is because when you say workspace is nobody knows what the hell we're on about. So at the top there we've got a live workspace. This is the one that all your users see when they visit your site and you can branch off that. You can create an upcoming event and behind that is the live workspace. You can create a new product and behind that is the live workspace. So you are branching off this live workspace adding new content to that sort of branch of the workspace. And then down the bottom here we've got a last minute fix. So you can branch off a branch and create fixes and push those up as well. So the two lines here represent a push and a pull. So the push will push all of your changes. So it will just push the white part, just the changes. And then the pull will pull any upstream changes down. So on the last minute fix we'll get all the changes from an upcoming event. On an upcoming event we'll get all the changes down from live. So we've got this full push and pull process on workspaces. So we also looked at a scenario on how workspaces actually work in a real life. So here we've got quite a detailed process. We set up the workspace at the start so the bottom, the yellow one is the live workspace and we create a branch of that above the white one. And then we can create content. So the black and white boxes within the white workspace represent creations, changes and deletions of content within your workspace. So these can be done many times throughout the process and you can do another update then from live which is done at the third step here. And then if this is okay we carry on. If not we look back and we keep doing changes and keep updating the workspace. And workspaces can go through the full sort of moderation process so you can mark them as needs review, you can mark them as published, and you can add moderation states to them and take them through this process. And then when we're finally all okay and we pass that okay mark we do a final pull because we want to make sure that everything we've got is the same as live. Before we do our push and make sure that everything on our workspaces is up on live. So when we do this pull and then push right at the end we would also look for conflicts and make sure there are no conflicts in the content. And we'll eventually need a way for resolving these conflicts. So also as part of the UX sprint we looked at different roles, different personas, different users. So we came up with this diagram here to try and explain the different roles that we have in play here. So we've got the create role there at the top, these are the type of people who would create the actual content on your workspace. And then we've got the review and approve so these are the type of people who approve the workspace, approve the content on the workspace and move it to the next moderation state. And then we have a final role of the publisher, the person who actually pushes it live. We're hoping for different permissions and different roles so you can differentiate between these different steps and only allow certain people within an organisation to do these. And then branching over all of this, at the bottom we have the configure role. These are your administrators and your developers who have access to all this stuff and they would set it all up. And they would configure all the different moderation states and the whole flow. And then we've also got this managed role, these are the managing editors and these have access to all the different steps and they can override anything and have access to the whole thing. So what we're thinking would be our roles and the different permissions that we'd need. So that was pretty much all that we looked at in this UX print and all the kind of concepts we came at around workspaces and the flows. From a code point of view in phase A we looked at a number of different issues. This was the phase where we were trying to get more revisions everywhere and there was a number of issues that were underlying to getting revisions everywhere. So these are some of the ones that we addressed. Revisions are now enabled by default and content entities inherit the base fields. So things like the revision ideas inherited from the content entity base. We've now got revision log interface being used on node and block content. A revision overview has got a pager now. Contextual links are now different for revisions compared with the default revision, the live version of the entity and non-revisionable translatable fields. It's quite a complex one where if you had a field that was translatable but not revisionable on a revisionable entity it caused a whole heap of issues. So that was another one that we looked at. So phase C is probably our only phase that is done. It's content moderation. It's in now as an experimental module. There's still a whole ton of stuff we need to do to make content moderation a stable module. But sort of as a phase I'd like to think it's pretty much done and we put workbench moderation into core, renaming it as content moderation. We made it uninstallable because with bench moderation you can't uninstall and experimental modules need to be uninstallable. And then we fixed a few bugs and cleaned up a few bits and it's all looking nice. So phase D enable archive and purge storage. So I spent weeks and maybe months looking at how we can archive entities, how we can mark things as deleted but not actually delete them. And in contrib we add an archive field to all entity types and that will allow us to mark things as archived. But in core that didn't really seem like the best approach. So we looked at changing the status field and making that a field that we can mark as deleted or mark as archived but that blew up a whole load of other things. Things like views that assumes a status field is boolean and we'd have to update every view ever on any onsite. That didn't sound very fun. We also looked at SQL views. So putting all this in the database and having a different SQL view for every different sort of status but nowhere in core has SQL views at the moment so adding that didn't really seem that fun either. So this whole phase has been postponed really because we didn't find a good solution. So what we've ended up doing is for the trash module which depended on that archive flag we're actually using content moderation. Content moderation already has an archive flag so we thought why don't we just use that. So trash will depend on content moderation and use the archived moderation state. So in contrib we've created a 2.x branch of the contrib module. The contrib module originally depended on multiversion which is the module that had the archive flag in before. So the 2.x branch depends on content moderation. It uses the archive moderation state. So we've been working quite a lot with our UX team as well to try and work out some of the issues with trash. Trash was originally written for this session in Barcelona so the 1.x branch was written in like 2 weeks. So there's a lot of issues with it. It didn't have any tests and it didn't work 100% of the time but now it's getting better. Things like the delete tab on the top of your entities now says move to trash and you click it and it moves things straight to the trash. There's no confirmation page so everything just goes to your trash and then you can go there and restore it. One thing I'm currently working on is when you tick all the different nodes on your admin content page and you do a bulk action to move things to delete it and now move the ones that can be moved to the trash to the trash and the ones that can't be moved to the trash it gives you the confirmation page because it's based on content moderation and content moderation is per bundle, so per content type. We have to do different things for different bundles. So there's a lot of checks in trash to see if a bundle is moderated. So yeah, that's pretty much the state on trash and I'm hoping that pretty soon we can get that in as an experimental module in A3. I'm hoping it will be there. So these are some of the UIs that we've been looking at for trash. So this would be the trash. So you see we've got a number of different entity types. So they're all mixed together. It's just your overall list of trash. What we were thinking was on your desktop machine if you put an image in the trash and if you put a text file in the trash and a word document in the trash, they're all led together. You don't have a separate trash for every type of file. So we're putting all entity types in together and from there you'll be able to restore or actually delete entities. So restoring them will take them back to the moderation state that they had before. One thing we're still trying to work out is what is before. So we've got to kind of work out from the revisions what would be the revision before, the revision that you put it in the trash and what if you were doing forward revisions. So if you had a published revision and then you created a draft revision and then you send a published revision to the trash, what happens to the draft revision? And when you send something to the trash it creates a new revision, it creates a trash revision. So that then bunny hops your draft revision, your forward revision. So when it goes back, does it go back to your draft revision or does it go back to your published revision and how do we know which one is which? So we've got a whole load of complex issues. So if anyone's got any ideas, I'm happy to take those. We're also adding an undo link to the trash. So when you add something to the trash, you'll be able to undo it. And that doesn't have a confirmation for me there. You just click undo and it undoes. Again, we've got the same issue. What do we go back to? What revision does it go back to? Because we don't know. Once you move something to the trash, we've added a new revision. We've added the trash date. In the most sensible situation just before you push the button, you remove your trash revision and you go back in the state you were. So the published note is the published one that was there. The draft is the draft. If there was a forward draft. Right. So the question was, why don't we just go back as we were? It's not simple to do technically, but logically it seems the most sensible thing you'd do. That's actually what we decided. So we are looking to go back. I'm wondering whether it is so easy to know how it was before. Because after you create a new revision, it's not 100% clear what the revision before was and what the state was before. But we can probably try and work it out. We do need to give that some thought. Has any schools been given to how that would interact with workflows? So like if you pull in changes and then someone actually to eat something from the live site and sort of the restore process behind that and getting it back across any necessary workflows. So the question was how would it work with workflows. It's something we need to think about. Because we don't really store much information at the moment about workflows and the process or the states that things have been through. And we are storing in content moderation all the different states that an entity has. And they all have an order because they have a sequential revision ID. But if someone's creating a draft when you've got something published and that's got a forward revision, a higher revision ID, but then when you delete the published revision then that's got a higher revision than the draft one. So as I was saying earlier you don't really know what you're going back to. It feels like it should have the awareness of who's my parent. Right. So yeah, the question was the revision needs to know who's its parent. And that's something I will get to in a bit because in the contrary modules we have got revision parents. So yeah, we can definitely look at using that. So on to what's next. And the UX stuff, still a lot of work there to do mainly around workspaces. So we need to get the name incorrect when we say workspaces. No one knows what we're on about. So is workspace the best name? Should it be site version, site revision, something else? Definitely open for suggestions there. We need to come up with some prototypes around the whole workflow to use it or interface and do some user testing around that just to make sure that it all kind of makes sense and works. One thing that we've got already in Contrib is moderation states on workspaces. So you can move a workspace between draft, needs review and published and trashed. And so when you publish a workspace it automatically moves all the content from that workspace to its parent workspace. So much like in a Git workflow every branch has got an upstream branch. So we'd have that similar sort of thing with workspaces where everything would have an upstream and it would just automatically merge up to its upstream. But does that make sense? It makes sense to me, but does it make sense to the people who are actually using it? So then in phase A, I said earlier we've done a load of stuff in phase A but we've still got a really big issue outstanding and that's to make things revisionable. And it's very easy to make things revisionable but the upgrade path is incredibly hard and moving all of your content from a non-revisionable entity schema to a revisionable entity schema is pretty complex. So we've got a lot of work done already on there but we just need to try and get it past the line and get it done. So in phase B we're looking to extend a revision API with revision hashes, revision parents and an upgrade path that generates all of these. So the revision hash is a hash of the revision so if user A creates a change to an entity and user B creates exactly the same change they will generate the same revision hash so we can just look at the hash and we know that they're both pretty much the same revision. And then revision parents will allow us to see this full sort of path of where our visions come from and this will definitely help the trash issues but it also allows us to resolve replication issues when we're replicating content between workspaces and between sites we know exactly where the revisions have come from. And then the upgrade path, as I said we need to generate all these so we're going to have to go through every entity on your site and generate a hash and work out the parents so we've still got the problem of what is the parent revision. I guess we could just assume that it's the sequential revision ID but again we're up to suggestions. So phase F is when we hope to add in a lot of workspace stuff and it's debatable on whether this depends on the revision hash and revision parents. So we can definitely add workspaces into core very soon and they don't need the revision hashes or the revision parents but they will need them when we start doing replication between workspaces. Is there any point adding workspaces before we can replicate content between the workspaces? Do we add workspaces to core now and leave the replication in contrib? That allows you to get workspaces as a basis into core and get something that probably will already be useful for a number of people and for a number of people to start using it without having all the complexity of solving the hash and a replication issue because if you only have two workspaces the replication logic becomes a lot more manageable. I guess the comment was about having limited workspaces so basically only two workspaces is a stage and a live and it makes it a lot simpler but I don't want to get into the situation where we add stuff into core that we then have a problem when we try and add more stuff in that we've actually got to take out what we first started with and we've already got all this working in contrib but I did write a blog post a few weeks ago where I said that it's really not that easy to just move it into core so I'm not saying because we've got it in contrib but we've got all this stuff working we just need to try and sort of port it over and a lot of the logic that we've got for replicating between workspaces we've taken from CouchDB and how that does the replication so it's a pretty solid process so I think that's I'm not going to say an easy bit but it's relatively straightforward sort of we know what we're doing because there's tried and tested ways to do this replication but it's definitely caught a bit of work to get it done but currently in contrib we add workspaces in the multi-version module which is like the base module and you can't actually do anything with those workspaces until you add the subsequent contrib modules so that's what we could look at doing in core initially is the experimental workspace module does a little more than just adding the workspaces and then we just have the contrib modules to do the replication until we get to subsequent core releases or we could go down the Drupal 7 root and you have your stage workspace and you can just copy and paste everything over to your live workspace and that will do your replication so yeah, still a lot to think about on workspaces we've also been looking at what CPS did as a module in Drupal 7 it's a very similar concept to workspaces and development seemed to start on both CPS and workspaces at about the same sort of time and they went in slightly different directions but the end product is very similar so we need to try and look at the best ideas from both and try and work out what we can do to get the best end product so on the bottom there I've also got sequence entity indexes so this is one thing that we use quite a lot in the contrib modules this we've got an index for UUID for revision hash and then also a sequence index so this allows us to do fast lookups by UUID of an entity by hash of revision and the sequence is we store a log of every entity change on the whole site so much like a Git log we can look at the sequence log and know exactly what's happened between the sequence item A and sequence item B so that's going to be pretty important when we start looking at replication so also in this phase we've got a couple of services these are the services that we use in contrib at the moment to do our application so the changes service will allow us to get the changes from a workspace and then the revisions diff service will allow us to diff those changes between a workspace so we're only replicating the entities that have changed the revisions that have changed so the replication that happens is often very small because we're only taking the changes so these are some of the services that we need to get in place to get the replication working and we've got the whole sort of replication API at the moment we're using tag services in contrib that seems to work pretty well in that more modules can define a different way to do replication and it will just loop through each way to do replication until it finds someone that applies so in contrib we've got a single site replication where it replicates from one workspace to another on a single site and then we've got site to site replication and it goes over HTTP to a completely different site and these are just two different tag services and it just looks to see which one it's going to use and then there's also the conflict API and this is something that we had a Google Summer of Codes student work on over the summer and they've come up with a great way to do three-way merges between entities so we can get two revisions of an entity and do a three-way merge between those and hopefully we can get this into sort of auto resolve any conflicts that there are So the question was is there a module for that and there is the conflict module which is where the work is going on it doesn't really do a lot at the moment all the underlying code is in separate PHP services so we've made it very decoupled from Drupal itself and then we're going to pull that into the Drupal module so it'll be able to resolve conflicts with entities but at the moment it's resolving conflicts with just random data with like arrays so we would take an entity and put it down to an array and then resolve the conflict at that level and that's what the PHP service is doing So then phase G is kind of the the final phase really but polishing all of the UIs and making sure there's a really nice way to replicate your content between workspaces to create workspaces to manage all of the moderation states on them full sort of conflict UIs so maybe you want to just pick which revision do you want from the conflicting revisions or maybe you do want to carry out a full merge yourself and get the traditional four pains and do all the merging yourself so we're thinking of trying to build a very flexible conflict UI with different plugins maybe so there's different ways to do conflicts so that's pretty much it on what we've done and what we've still got coming up so if anyone wants to up to the mic I'm happy to sort of take questions but more sort of open up discussions on what you think and what you want to work on what views do you have yeah it's an open floor really so the my name is Jess I'm XJM on www.dripple.org the trash module UI that you had up there I'm assuming that was not of you because it had multiple entity types in it is that correct? so it definitely wasn't of you it definitely wasn't of you but we are hoping to do reviews because it's a list of content moderation states it's not a list of entities oh okay so the base table is the content moderation states exactly okay thanks I'm Daniel Villan I also have some views so I was wondering about the work spaces bit you were talking about exponential modules if for that kind of stuff and I was wondering about that that's really the right approach work spaces or the life stuff would have to be taken on account everywhere so I was wondering like well that's the right approach there just yeah it's an open discussion still but I think experimental modules are definitely the way interpolate to add new features to core but we do get into a whole load of issues then that it's got to be something that's turned on and offable and we've already seen in putting workbench moderation in that we had to rewrite a whole chunk of it to make it uninstallable so it's still to see whether that's the right approach or not but it seems possible that we can do it as an experimental module and and store all the information in some sort of meta table or entity type I'm a little bit worried because like work spaces are like a new dimension of problems so if you want to test a new dimension of problems you would have to add this dimension to any test theoretically to really test it but if you had an experiment you would you need to know you don't know what you want to test for right so I was well one option the same is with translations right we have translations baked into the core because it's a fundamental part of what we have to think about no that's just that's just a UI well yeah so we could look at just that and putting the API into core itself and then the UI is an experimental module that's definitely an option but then we've got to look at if someone only has one workspace if they use Drupal 8 as it currently is we've still got to send them through the whole API of workspaces and the whole lookup of does this content belong in this workspace or does it not so we're going to have to manage the whole performance around that and I know CPS in Drupal 7 did it in pretty clever ways so we'll probably call on them to help but it's definitely something that we need to think about I'm Tobias I'm CPS this is not really a question just something kind of to throw at you to see if you have thoughts on that because we have the changed field on a bunch of entities so basically whenever you whenever you press save on an entity it updates the timestamp and I'm wondering how that fits into the whole entity hash thing because whenever you save it you have a different changed timestamp so there's definitely going to be like a change and does that really count or not or like so so in the contrib modules where we're generating the hash now we exclude a number of fields like revision ID and changed that are different between revisions and we generate the hash not including those and because the way we generate the hash is consistent it will always be the same if you generate it on site one or site two so yeah that's pretty much how we do it but we will have to take into account if some random contrib module is adding another field in that does similar stuff how do we manage it do we generate the hash of just known fields I don't know again it's something that we need to look at so the comment is it should be hookable or pluggable and yeah it probably should be especially when it comes to translations the change field is translatable so we have a change timestamp across translations or in general like how do the the hashes work when it comes to translations not sure to be honest but yeah again we're going to have to definitely take that into account thanks Tim Doug Green I also did some work on the CPS and just a bunch of random thoughts you mentioned archiving were you talking about archiving of versions or archiving of entities or both because we ran into lots of problems with CPS that keeping track of all of our revisions the tables got huge and we ended up archiving in files instead of right so we're looking at archiving and entity as a whole but the archive is denoted by the latest or the default revision being archived with the moderation state we're probably going to allow a setting to choose what is your sort of trash state or your archived state so each bundle potentially could have a different trash state but if the default revision has that state then it will be archived so essentially it's the same as any other revision in the entity API it's just got a different moderation state and a moderation state in content moderation is just a config entity so it's no different to needs review or any other moderation state really it's just sort of a special state so yes we probably will get into the problem of having big tables with lots of revisions but it's potential when you start looking at the workspaces that you had basically every copy of every revision and every workspace and it just balloons it's definitely something we need to the other thing that I saw that a few others in your workflow states we found that language translation was a workflow state that needed to be in there so it wasn't just content editors reviewers, approvers in addition to that okay it's interesting you mentioned trash and I was wondering isn't trash done in a workspace or are you trashing the live version potentially you could trash a live version and we are looking at replicating trashed states so if you trash something in stage and you replicate stage to live it will become trashed in live as well but potentially if you had the right permissions you could go on to live and trash it trash an entity that is so I think we need to leave it flexible enough from a permissions point of view that if someone does have the use case that they want to trash something in live that they can the last thought I had this has made a different design decisions and we did the replication wasn't really necessary we weren't replicating from one site to another site the revision control was all controlled within a single site are you complicating this model right now thinking about replication I'm throwing that out there yeah coming from the contrib background of all this the main goal was for site to site replication and for that we looked at the catchdb way of working because the replication there is very solid there's a very good protocol very good API so we copied the same principles when we looked at single site replication so maybe we are over complicating it but I think it currently in contrib anyway works pretty well and does what we need but for core I definitely think we need to look at it and whether whether it is creating too many revisions or many entities when we do replication so actually on that point having the axes of revision translation and workspace for every entity type I thought that you said something about a diffing API maybe this isn't related but wouldn't it be so if a workspace has a parent workspace that is by default just the live workspace wouldn't it be that you only need to store entities that are different like you only need to store the things that are different in whatever workspace than the parent workspace and so that greatly reduces the number of duplicated records that you need to have for everything and then also simplifies the total space which was like I think four dimensional at that point but now it's only like three and part of some in theory I think the problem there might be that if changes happen in the parent that create a difference in the the other one that's not going to be tracked so when you go to push it back it's potentially harder to if you make a change in the parent then you do an update and it pull the change down but then you'd get a conflict and you'd have to resolve your conflict I'm like yes it's based very much on getting so yeah I do really only need to store the changes we went through a lot of iterations in the contra modules on how we store things and got into a lot of complications and currently in contra we store everything multiple times and that can be pretty hard I think in CPS it does just store changes so yeah it needs a lot more discussion and there's sprints this week so so Kevin O'Leary TK O'Leary I'm totally applaud the I mean everything's awesome this is really really great stuff and it's very badly needed and I'm totally for the idea of it being on multiple sites and being able to replicate across multiple sites because I think that if we look broadly at what's happening in the world of large organizations using Drupal this is what they want to do they want to have a metasite that crosses their entire organization and leaks all their content together we've seen this at Acwia this is why we have content hub and why other people have done other things similar to that but I think looking at your whole plan from beginning to end I think every step is really important I feel like the step of let's clean up these UIs and make a good sort of mental model or way that the user can understand how to resolve conflicts and do merges and things like that being the last step is a mistake because the way that the users understand the mental model and the way that we construct the actual data model are inextricably linked and we need to map things to the way that the users are going to want to understand the data model that people mentioned get is a really good example of a tool which is incredibly powerful for which ever since it was created app developers have started creating all kinds of different ways of visualizing the tree and creating different kinds of applications to visualize diffing or mapping the tree or doing different kinds of things where they can create a visual model where the user can understand the mental model of how things get replicated and how I move back up the chain and where, what branch am I on and where am I in this whole structure and I think that if we work on the visual model of the UI for that much, much earlier in the process that it's also going to tease out and help us to resolve issues around what's important about the data model Does that make sense? Yeah, it makes sense and we have already been thinking a little bit about moving some of the UI stuff a bit earlier because I know there's some interest in getting bigger UI pieces into each release of Triple 8 but it's sometimes hard to get in these UI changes if you don't have the API behind them so we need to definitely think about some of this stuff also we'd like to try and keep the UI as simple as possible and maybe even pluggable so that with core you get a nice simple UI where you just sort of change a moderation state on a workspace and it's published and then we sort of need to look at what published means does it push up to the upstream space after it's published all these kind of questions but try and keep it as simple as possible and then we can have these add-on modules that do different ways of replication that do the cross site replication that allow you to do other, I don't know, crazy not just to replicate to the upstream but replicate to some other workspace or to multiple workspaces at once so we could have a content hub type thing where you can replicate out to 10 sites at once so it would be nice to keep it flexible but have a nice a nice basic UI so we do need to think about it early and we have got UX people trying to sort of solve these problems fairly early on like the trash stuff the UI so that were done quite a while ago and it's only the last few weeks that we've actually started working on building it so hopefully if the UX people can start getting a perfect world ideal UI early on and then we can try and work how we can fit the API to make that happen and what the MVP kind of steps would be together I think what I heard and maybe this was maybe I was mishearing was that you would have the API and much the same way that Git is what it is and provides no UI and then people could create their own UIs that visualize the revision stack in different kinds of ways and that's where I think we run into problems from a usability perspective and a consistency perspective across Drupal and here is a place where I feel like we need to be opinionated in our design if not necessarily in our code more opinionated in the design in the underlying code because if we have a cohesive and logical visual model of what the tree looks like to a user that can be extended and added on to I mean you can add on icons that represent replicate across sites or replicate within sites things like that that everyone uses this sort of single model to describe the tree that it becomes a kind of a touchstone that we can all kind of latch on to oh well this is how we all understand it even becomes easier for us to describe things to one another because we can just throw it up on the board and say oh well it's here you're on this note and then it goes much the same way that you created the diagram in your presentation it gives you something that you can hold on to so I think initially when we started looking at the initiative back in New Orleans it was very much the plan to build all the API first build the UI afterwards and we quickly came to found that we need more UI in earlier on so I think that's changing more and more and as we keep going I'm sure we'll get more UI in earlier and I think we do need the UI in earlier but I'm still concerned about the API and the data model and how we even do a simple entity query now we've got workspaces and entities that can live in multiple places and more revisions in one workspace and another and all this crazy data yeah it's coming along great though I think the place where we are at now is good and I'll definitely become more involved in the design part as well so to Kevin's comment I think it's important to distinguish when we do work from when work lands in core so while I agree that it's very important to have design very early in the process so that we know what it is that we're building in a way that's available to everyone at the same time that doesn't mean that Adam user interface itself can still be phase F that doesn't land for several years that the work space initiative has already demonstrated that it can put user-facing changes in core it's already demonstrated progress and success as an initiative so I want to roll back the pressure a little bit to have user-facing changes in every release of every minor release because that's it's also a very complicated problem that we need to get right and so there will be other great user-facing features that land in 8.3 and make 8.3 a release of Drupal so I want to install this pressure doesn't need to be only on your initiative but I do agree that having the design work done early so that we know what we're building and then can actually build that which involves not only having the design for the user interface but actually the APIs that makes the functionality that it exposes work can be something like that. I think the concern I have that even though we can add all this experimental modules sort of rip it out and start again and change things and it can be API breaking the data still needs to be all intact and working so we need to get that working and perfect really to start with so I think that's going to be the tricky first step with workspaces specifically any other questions? No, I think we're good so the only final thing I've got is that there's a boff at 2.15 so right after lunch so if anyone wants to start discussing some of this stuff or if you've got any other ideas then I'll be there in the boff and happy to hear any ideas and suggestions and then we're sprinting on Friday so I'll be there on Friday trying to get Trash ready to go into call and then there are sprints on Sunday at Sunday even though I'm not there there will be people sprinting on this stuff Thank you