 Welcome everybody. Today the fabulous Duncan Dickinson Fountable Knowledge in Relation to Redbox is going to show us under the bonnet of release 1.6.1. Thanks Simon and thank you for giving me the opportunity to go through 1.6.1 as well Simon. What I was going to do today was go through the 1.6.1 release. I wanted to sort of talk about the various facets of it and then briefly mentioned 1.6.2 what's going to happen there. It's not going to be anywhere near the size of 1.6.1 and then try and have a good chunk of time for questions etc. As Simon mentioned before I put some links in the chat window which one is the link to the demonstration site which is what I'm going to use here. We've updated that to 1.6.1 and I've also put a link to the how to page which is largely a technical piece on how to do customizations. As you think of things to ask etc. please do throw them into that chat area that would be great. Before I start talking about 1.6.1 I guess it's important to couch it in terms of how it started off. Amanda Nixon at Flinders University spoke to us about putting in self data management planning tools into Redbox and that's what the 1.6.1 project has focused on. We worked with the QCIV team, worked with Amanda and Grant Flinders as well as the team at Deakin. Both groups were extremely helpful in working out what functionality was needed and testing etc. So I'd like to thank them as well for their efforts. So I'll make a start. I'm presuming that everyone can see my Redbox screen with the researcher dashboard. So 1.6.1 adds this researcher dashboard that did sort of come in 1.6 but it wasn't very complete at that point in time. The way it's been set up is in Redbox speak it's a separate view. So as you can see it doesn't have the admin links, it doesn't have all of the menu items. It's really aimed at researchers to log in and start working with. I guess part of that is if you're not wanting this functionality one of the things is that it is a separate link so don't hand out the URL. So this is what we call the researcher dashboard. It provides some key areas. The menu over here on the left allows you to create a plan plus also create a self submission for a data set or a collection. On the right hand side you can view the plans that you are creating. There's another section that comes in under this that people have shared their plan with you. Beneath that is a list of data sets. So these are the self submission data sets. We basically have draft data sets which are ones that the researcher is working on at that time and then they submit that to the main review workflow. So one of the key things in 1.6.1 was we went back and by we Andrew Brasattie and the technical team went back and undertook a couple of major tasks within Redbox. One is they redefined or created a new set of code for handling workflows and handling forms to try to improve a lot on the old form handling which is what we traditionally use in the review workflow. So it's important to know that the review workflow, the old Redbox workflow is still there. It's still running and it's still running in its old code base. So what I talk about here in terms of customization won't apply for that review workflow until a later time. The other thing that self submission calls us to do is allow for individualistic ownership within Redbox. So we've handled things by roles. So what we'll also see here is that there is an owner for these records and it's an individual. The last thing you want is all researchers being able to see everyone's plans. Okay, so picking up on the data management planning, we have the ability to add a new data management plan which as you'd imagine creates a new set of forms. What I'm actually going to do is go and look in at a plan that I created this morning mainly so we can get in and start looking at it. So if I click on that plan, so as in all good cooking shows, here's one I prepared earlier and you can see here we've got our display screen with the various bits of information that we provide. One of the functionality items we added was the ability to turn the information about the plan into a PDF. In our speak it's a transformer and basically you give it a template and it will allow you to create a PDF but also with local customizations, you know, your organizational headers, etc. And an important feature raised by the group was the ability to look at previous versions. So you can actually go back and look at prior versions of that PDF. Important to note that's not prior versions of the record, it's prior versions of the generated PDF. Okay, so we've got the project overview information and we've got various fields, various additional items that people can add. We've broken it up this way so the first form tries to grab information that's useful from the start and then at later date the researcher then can be encouraged to go in and enhance their information as it becomes available to them. So for example they may not have sorted out data licensing and access from the very beginning and at a later date we'd like to try and capture that from them. So I'll go in and edit the draft. So one of the first things that you'll notice is it's a reasonably straightforward web form. Sorry about that. That was some strange audio that we got. Seems to have gone quiet. All right. So one of the reasons this is reasonably straightforward in terms of its layout is to provide for customization. It's a lot easier for people to come along and customize to their various needs if we really give an example layout that can then be made more complex, etc. We decided not to have a more complex layout because then it's hard to work out what's actually doing functional stuff and what's actually doing form stuff and layout stuff. Okay, so some things that you've hopefully come to expect. There's inline help. There's the validation, the fields, etc. But actually what's going on in the back end is quite different to the old forms and I'll talk about that in a few moments. So I won't go through the form page by page. That is up on the demonstrator and it is available for you to go and have a look at. The demonstrator, when you do go into it, you can log in with the username researcher and the password researcher and you can start creating records there. So we collect a number of fields and the decision really was that I'm just going to push through these. The decision was that most sites are going to probably sit down and work out which fields they want to encourage their researchers to collect and potentially add fields as required. So these are indicative and we're assuming that individual sites will customize as they need. Okay, so I'll save and close this. It's a series of fields, etc. For the demonstration plan, I've then got a few options. I can go and view it which is what we saw at the beginning. I can edit it directly from this screen. I can download the PDF. I'll just pop into the PDF for that one. So this basically is a PDF version of that display screen for the record. Now this is a template that we use much like in other parts of Redbox. So you can do things such as put your institutional logo at the top. You can put headers, footers, color, etc. What actually drives this is an XHTML template. So it doesn't need you to do anything fancy with PDF or anything. It's just creating an XHTML file. I can delete the record, delete the plan. Deleting does delete it as far as the user is concerned, but it actually transfers the ownership back to admin. So the admin gets that record in an ongoing manner, which means that if the user accidentally deletes it, they can contact the administrator and ask for a back. We thought that was a handy safety net. The other thing that I can do is I can share the plan with the security that we've been putting in for this self-submission work. You basically end up with one user who's the owner and the owner can edit. When you share a plan, you're sharing view access. So those other users can't edit the plan. They can nearly view it. The reason we did that is it saved a lot of effort around locking records, around dealing with two people editing at the same time, etc. It just says there's one viewer, they're probably the data manager, and they're probably the one if you are in the team and you don't like what's being said to go in and... that they should be contacting the owner of the record rather than editing themselves. So I can actually share this as researcher, and I'm still listed. The demo user is still listed as the owner, but researcher now has view access. I can of course delete that. I can transfer ownership, which means that I'll lose edit access of that record and it'll pass over to researcher, but for now I'm just going to close this. So in the researchers dashboard, they'll actually see plans shared with me, and that will include the demonstration plan and let them go and view that. So handy for teams that are establishing their plan and wanting to share it around and discuss it. Within the demonstration plan, towards the bottom here, you'll see data sets and add more data set. Just notice the spelling error there. What this allows you to do is create a data set based on the plan. Now, of course, a plan and a collection description are not one-for-one swaps. You can't just copy all of the metadata over perfectly, but we do have a bridge that allows you to bring metadata over that you deem is useful. So where you add fields to the planning and you want different fields, for example, in your data set or collection description, you can actually set that up so that it will transfer between the two. It will do a copy. Okay, so if I go into the demonstration collection description, that is a self-submission interface for describing collections. So we've got the details regarding the collection plus a link back to the plan that this collection relates to. There is also in the dashboard the ability to create a collection description that is not related to a plan. It's just a standalone which could be useful for older collections, etc. But this way, of course, means that you can have a plan that links off to the different collections related to that plan. I'd imagine that a long-term research project will produce more than one collection, and this is a way to – one data set, and this is a way to capture that. If I go to edit my data set, again, you'll see the similarity in the form interface. And I'll talk about customization in a bit. So this is the self-submission of a collection, and it's the various fields. We are at this point limited in the fields to what is actually in the review workflow. So this eventually has to get over to the review workflow. If you add fields in here that don't exist in the review workflow, they're not going to display there. Redbox will capture it, but they might display. So these all map across to fields in the review workflow. Most of them Redbox users will be used to as a title, type, description, etc. And this allows me as a researcher to go through and describe my data set. There is one area that we did put in which is slightly different from the review workflow, which is where they nominate that they would like a DOI. We don't allow them in the form to create a DOI, and that's largely because of the management that should occur around a DOI rather than someone just going creating lots of them for themselves. And the normal inline help and form validation. So if I return back to the home page. So the demonstration collection is sitting there whilst I'm working on it. It's in my inbox as it were. I can know when I'm happy with it send that off for review. Now that heads off in the current out of the box. It heads off to the metadata review stage and I'll just pop over its demo self-submission for review. If I go to my other browser, it will open. This is the old review interface and you'll see the demo self-submission for review. Now what happens here is that leaves, in terms of edit access, it leaves the researcher and it heads over to metadata review so that the librarian or the data librarian is able to review that and then put it through the various processes to have published. What allows me to do though as a researcher is I can go in and have a look at the records that I've submitted and I can see where they're up to. So for example, if somebody was waiting on a record to be published in relation to a journal article, for example, they'd be able to see where it was in the review stage. So I guess general, the general points there was around the ability to create and view a data management plan to look at the PDF that's created from the data management plan that you can go in and have extra sections that are added at a later date. You can add a data set either as a standalone or in relation to a plan. When the researcher is happy with the data set description, they can then send it off for review and that's then picked up by reviewers for eventual publishing. Back in the dashboard, I'm able to share plans with my colleagues. Obviously, I'm able to delete the plan and the user interface here, of course, has been more refined I guess for a researcher group rather than all the admin menus and all that that was in the old interface. So that was a very quick look at what 1.6.1 offers. I think it's quite a strong set of additional functionality. It's a set of functions that people have been asking around and hopefully then something people can pick up and customize for their local versions. So in terms of customizations, I won't go into the overly technical aspects but a few bits and pieces are going on here that don't go on in the old review workflow. So first of all, the various texts on the page like the titles, the field labels, the help files, they now come out of a language file. They're not actually embedded in the form itself. It calls out to a language file. So one of the options is if you don't like the help that we provide or you've got further resources you want to suggest to the user, you don't have to go in and edit the forms. You just need to edit that language file which is just a text file and within that you basically just pick the field you want to change and the text you want to put into that. Instead of defining a big HTML, JavaScript form, we have a model which is more of a component model where you put a series of components in. So for example in this you've got a heading which is a component and you've got a project name so that's actually a label component and a text box component. So they actually build it by putting these components in and the idea there is that within that file it's not a huge HTML file, it's really a set of components that you build. The other key customization that we provide is a system we call transitions. So one transition is when we go from a plan over to a self-submission dataset and transition basically it brings metadata over to a new object. So in this case from a plan it takes the metadata that you need over to the self-submission forms and that transition happens immediately. So when you're in a plan and you say at another dataset it does that on the fly. The other transition that we have is when you're finished with a self-submission and you've sent it on to review, that's picked up by the system every 15 minutes. It looks for everything that's been tagged ready for review and that then applies a transition into the review workflow. So that doesn't happen immediately for the user but it does that in a 15 minute increment. You can reduce that increment to five minutes, one minute, whatever makes sense to yourselves. So that transition as well is a customizable template actually. So you basically say this form field goes to that form field in the new form or this form field, don't worry about it, it doesn't go across. So obviously between a plan and a collection there are certain fields that you wouldn't bring across at all. So that's the 1.6.1 feature set and the work that can occur around customizing it. The thought that most sites, if they rolled this out to researchers would have a big red box at the top and lots of red all through it. They'd probably put all of the branding. So we've got documentation about branding, institutional logo, et cetera around it. So we've tried to keep a lot of our layout to a minimum so that you can see where things are happening rather than where a lot of fancy CSS or JavaScript is going on. So that's 1.6.1. What I might do there is I might hold and I'll talk about 1.6.2 towards the end there Simon but it might be a good time to see if I just blasted through things a bit quickly if people want me to pick up on specifics. Okay, so those that don't have microphones, please put your questions in the chat box and if you do have a microphone, it might be... Well, by all means unmute yourself and ask a question. While people are typing in their questions, I've got one for you Duncan just to start off. And this is probably just me. But can you just go back to the project plan where you can... The form where you can enter a description. There was a plan and there was a field there for a description. Now when I... So I have a project. I put in a description of that project there. Does that become an activity record for the project? Or is it somehow related to the data? I'm just a little bit hazy on what you're capturing there and where it goes. Well, the description is really about the project that you're undertaking. With the alert system, and you've prompted me on two areas that I didn't cover. So alerts and also, and I wonder if Amanda's sitting there going Duncan, you've missed stuff. So in the alerts, for example, that's where something like a research master or similar system could actually start off a plan. And what goes on there is that some system sends through information that could start off a plan. And we actually have an element in the system that will allow... So for example, Professor Smith has entered a new project that they're doing in the research management system. That comes through as an alert. We have some components there that will allow you to not only create a data management plan but allocate the ownership to Professor Smith and make them aware that the plan's waiting for them. So they get ownership for that. There's Amanda. So that's the incoming. In terms of an activity record, we provide a link to the funding source and the grant numbers. But the actual turning of this into a data management plan into an activity was something we really didn't cover as part of our discussions. Amanda, did you want to talk to that at all? I think all I wanted to say is that you've probably seen from what Duncan's showing, there's been an awful lot of development here and awful lot of thinking. And while we were working collaboratively, we don't have... We can't think of everything. So I think that what you've brought up, Simon, is something we started to talk about probably towards the end and probably something that we could discuss further down the track in more developments in Fred Box. The way it's working now is that the stuff is effectively coming in from something like Research Master very early on in a research project and could even be before a research project has funding. So the information that's going into here can change. I know talking from our research office, the information that they have in their system is very preliminary and changes a few times before it actually looks like something you'd get that would be suitable for an activity record. So I know that's a hazy answer, but yeah, that's about where we are. So what happens to the description that I would put into that box that's showing? Where does that go, if anywhere? It would just stay there, I think. Why not, Duncan? Yeah, that's stored with the plan. We decided not to transition that to the dataset when you create a dataset description based on the plan because I think as Amanda quite rightly pointed out that your description of a project is likely to be quite different from the description of the dataset. So within the data management planning side of things is largely an internal administrative system that encourages researchers to flag that they're about to do research, that they have some information about that ethics, where they're going to store it, trying to get them to think about things like data licensing and storage, hopefully from day one rather than last day minus one. So one of the areas I think as well, I see your point Simon about creating activity records, but I wonder sometimes with groups going out, say for example in Amanda's team, going out to researchers, trying to get them on board with data management planning, it might be an easier sales thing at this point if it's just to help the researcher and potentially give them services within the university. Any publication of that information, say as an activity record, then creates a level of concern I think that they would probably, you wouldn't want them to moderate what they were putting in because they were concerned of what potentially could leave the university. It's just a thought. Now there's a question from Susan Robbins which I'll read out, in case people aren't looking at the chat box. She asked, Susan Robbins asked, who assigns researchers the login to start creating a record and is there somewhere in the system that stores them? Probably those logins, yes. Can you see that question? Yes. In the most basic version of Redbox there's an internal username and password store. It's not something we suggest that most groups use. So groups that use, say for example LDAP or AAF, basically as long as they're in the researcher role, so there's a role called researcher and you get access to this dashboard if you're in the researcher role. If you're in the LDAP plugin for, for example, for authentication and for roles, it would really say that if somebody logs in via LDAP, they get put into the researcher role and then they have access to the forms. That's also an important aspect because of the way that the authentication works. You actually would type in, for example, the persons, say university login or LDAP login, hit there. We don't do lookups mainly because they're quite large and quite often difficult to get access to the LDAP lookups for that. So one of the key things there is that, yes, they authenticate. If they're in the researcher role, they have access automatically, but you don't need to do anything as long as you've set it up that way. The other thing is that when they're then sharing their records, what they need to know is that the login that they're associate users and quite often in these, we thought that was pragmatic in terms of the trade-off between the technical and the human is probably quite easy for one member of the team to ring or email someone and say this is my email address. Could you please, not my email, my account. Could you add it to that box? Great. Let us know, Susan, if that doesn't answer your question properly. Beth Crawther from the University of Sunshine Coast has a question. Beth, would you like to unmute and ask it yourself? I always prefer it if people can speak. Can you do that? Can we hear you, Beth? Sorry, sorry. I was passing around. This is kind of the first time I've actually seen Red Box in action, so this might be a dumb question, but is there a way of somehow putting a link to or a PDF of the ethics form into here? That's a good question, Beth. There is a way. What we worked on is a series of components that met a good baseline of items that you could put together. So out of the box, we don't have an attachments widget, which is what we have in the review workflows. That being said, we have another project on the go at the moment where they definitely do want attachments put on, so we're looking at extending and adding components to do attachments. So out of the box, no. When I talk about these widgets, they're reasonably straightforward widgets to create. For us, it was really just an issue of time, and over the coming months, we expect to have an increase in the number of widgets available, so we'll add them as projects require. The main thing we didn't want to do is just have lots that potentially weren't used, but the form attachments were certainly one that people have flagged as something that they want, and we have an active, painful project at the moment where they need to do it, so it needs to be done. That's great. Thank you. Any questions here? Any more questions? No, it's something we hear. Mike. Mike Lynch has just asked. Yes. I'm sorry, Duncan. I was away from work yesterday. I know you were in a teleconference with some people here at UTS at Intersect, so apologies if this is covering existing ground. I'm just interested to know if we're collecting records from a data capture service and bringing them into Redbox via the alert system, would it be possible for us to inject those records into the self-submission workflow so that the researchers can edit them, or would they still have to go straight into the review workflow? Yeah, that is a good question. Sorry. I'll stop saying that's a good question. They're all good questions. Yes, Mike. Yeah, I mean, one of the pains that the people have raised with the review workflow is it's quite long, et cetera, et cetera. So one of the things that we did was when you submit a self-submission data set off for review, it's configurable as to which stage it goes into. It could go into final review. An incoming alert, we worked on a system where the incoming alerts in this release, you can create a new plan based on an incoming alert. But the code around that, when we talk about the difference between these things, like a review record or a self-submission record or an alert record, there's nothing overly technical going on in the background. They're largely property set on the object. So the alert system can set those properties. And Andrew and Grant, so Andrew and QCIF and Grant at Flinders worked on, have been working on the system in which the alert comes in and you could assign to whichever type of object you think is appropriate. So is it a plan? Is it a self-submission or is it a review workflow item? It will then also as part of that do a lookup and assign a security context to it. So for example at Flinders, we get a field which I think is the email address of the primary investigator and we use their LDAP lookup to work out the user name because the username doesn't come through in the CSV and we apply that to the record so that that person when they log in, they will see that plan. I couldn't see why that wouldn't work on self-submission either. Yeah, cool. Thanks. Grant, I think this is more a clarification than a question. But Grant, would you like to speak to this? This is Grant Jackson. You got a mic? Can we hear you, Grant? Yes, I just found it. That's great. I think that's what you're doing. That's right. I just wanted to clarify an earlier query which just to take a step back, which is the evolution of this project is that the main purpose was to create data management plans. So all the fields go into a form and result in a PDF and that is a plan for the researchers' use or the research team to use to plan how they're going to manage their research data. Then one of the things that comes out of this area quite a bit is people put in information and later on they put in similar information into a different form. Actually, the description field that you're asking about before Simon, that ends up in the plan. So that's where it's visible to people in a PDF or on the HTML form here. The second part of it is because there's a whole bunch of information that could be used potentially for a project, which is what you're querying, or a data set because there's quite a bit of overlap. It's been chosen to put it into a collection or data set metadata. So it finds its way there and some of the fields, for example, description that was chosen that the description for a plan might not quite match what you want for a data set. So you get the opportunity to put in a different description when you convert it to a data set. That's what I was attempting to clarify. That's great. Thanks. Are there any other questions? I might just pick up on one area that I did neglect to discuss. It's a very brief one. It's that of triggers. And one of the requirements within the project was to, when something happens, we can handle that some way in a trigger. Now, a good example is if we receive an incoming plan that's being associated to Professor Smith, one of the triggers is that on a periodic basis, the system checks if a new plan has been created for somebody and can fire them off an email using, again, a template. We love our templates. That says, dear Professor Smith, there is a plan waiting for you to go and fill in. Please contact us if you have any questions, et cetera, et cetera, as per your requirements. We've done a very elementary version of that, which is to define what, to create in the system the ability to define what you're trying to look for in terms of a trigger. So it really also opens the door for things such as, when you're creating a plan saying, I need to store 200 petabytes, the system might then be able to send off an email to the IT help desk saying you might want to go and speak to this person to find out where they're going to store 200 petabytes, something like that. So the trigger is a way that hopefully these plans can fit in with your organizational processes and provide a service to the researcher that fires off an email or some other form of communication that says, it might be a good time to speak to this researcher to help them. A good example might be if they don't have an ethics clearance that might be worth coming back to them. So one of the things that I think for anyone looking at 1.6.1 and this functionality is to really look and say, how would this work in our organization? What's the process flow? How do we want people creating plans? How are we going to support them? All that service level stuff that almost sits outside the technology. And then with your flow diagrams and your various event models, et cetera, you then come back to Redbox and say, now let's start putting this together. So that whole organizational thing is quite a big question and I never underestimate how long that would take, especially if you need to take that through several committees. Amanda, last week when we had Tobi Ohara from University of Western Sydney, I asked him a question about the collaboration that he had been undertaking. I just wondered, because this is a fantastic and good news story in a way, the collaborations that have been going on around this, would you just like to describe how this collaboration formed, who was involved, because I know Deakin had been involved, and the pros and cons from your perspective? Sure. This all started, well it was Duncan's fault, it was part of it. We from the very beginning wanted to have data management planning functionality as part of our metadata stores project at Flinders. We weren't quite sure how we were going to do that. And when we started looking at them, I was just bouncing ideas from Duncan and Duncan said, well, we can put it in front of Redbox and other people have been asking me about it. So I guess that's one of the first planks of the collaboration. Then just using the Redbox list, put the call out and got a great response from a number of institutions, including Newcastle, UTS, Deakin, and now I'm going to forget one, University of Western Sydney, so Toby was there as well. And then we made it clear because a lot of the development work was planned to be done over Christmas period and people were going to be taking leave, that I was happy to be the main liaison but I really needed to back up. And that's where Deakin put their hand up for that. And that was terrific because we did work very closely with Deakin in the end. That was terrific for a number of reasons. It gave us different expertise and different sets of requirements to talk about. So it means that we've probably ended up with much less Flinders-centric product than we might have ended up with. It was also terrific to have another institution to bounce ideas off of and also to take advantage of their expertise, particularly their technical expertise. Terry Deakin has been fantastic. I think it shows the strength of the teams on both sides in that the project manager from Deakin moved on to another project a few weeks ago and we got a new person to work with and that worked well also. In terms of the cons, it added another layer of pressure in that we had to work to multiple deadlines. So we had an earlier deadline than our collaborators but we had a lot more flexibility in meeting that deadline whereas other people had much harder deadlines. So it was just being aware of what issues were happening in everyone else's institutions. But other than that on the whole, it was very, very positive and I think coming from a place where we have worked with open source software before a lot of the people that we're dealing with in this space particularly that have come from library backgrounds we've worked together before on other projects which has been really useful. And also it just seems a waste to not do stuff collaboratively when there are so many projects around the place and people using the same software. That's about all I'm going to say I think. Okay, that's terrific because hopefully there will be more of these over time because it doesn't stop here. I'm just wondering just before Neil says something I'm not sure if Terry is there at Deakin because it's Deakin's present but I'm not sure if Terry is there just whether there's someone from Deakin who wants to say something. Perhaps, yes, no, it doesn't look like it. Maybe it's staying here a little warming. They're coming, yes? Hi Simon, I'm in Terry here. Oh, Terry, good. Can you hear me Simon? Yes. We're not generating too much static or feedback are we? No. No, good. No, I just wanted to say that pretty much to just reiterate what Amanda said that certainly the collaboration with QCIP and with Flinders to sort of produce the data management planning tool has been a really positive experience for us here at Deakin. It certainly expanded our initial thinking around how we're approaching the metadata store. Initially we weren't as focused on the data management planning side we were more looking to provide a researcher sort of interface for the self-submission component but I think in teaming up with Flinders and sort of combining those requirements I think it's resulted in a sort of a much more sort of feature rich tool which is certainly going to benefit Deakin as well I think in terms of what we're doing for our data management sort of projects as well. Now I just also just want to thank Duncan Fries and the team there for their great work. It certainly, I know it's been a challenge but I think that the product that put out has been really fantastic and I'm sure we'll get a lot of use out of it here at Deakin so I just wanted to thank you guys for that as well. Hi Amanda, hi Terry, hi Grant and Duncan. First of all I think you are all to be really strongly congratulated on what you've done. You may not know but research data management planning has been something which we hear it and we've been agonizing about for months and months and I have a simple question which is the set of questions that you have arrived at and what are they based on or where they primarily sourced from and I'm presuming other people's work, if so whose? Yeah, I might just start off with that. We started off at Flinders by drawing heavily on the Curtin Tool so Curtin University had a data management planning tool that they demonstrated at the University Research Australasia conference in 2011 I think and so that really was the starting point for us and then a little bit more reading we started adding more things in and then in the beginnings of the collaboration we had I sent it out to the other institutions and then we got more and more and so then it was a pairing back but I think conversations that we had with Deakin and I remember the exact words with Megan this is a starting point. We don't expect this to be the be-all and end-all of the data management plan for any institution. At the moment we also don't know there could be more requirements to come through from funders, we don't know but this is a template that as Duncan said is flexible so the institutions can change it according to what they want to capture, how they want to capture what terminology they want to use and hopefully we'll be able to adapt as the landscape changes. Fantastic, terrific. Well done. I think it's a really significant step forward to have that. So with that and there are no more questions I'd just like to say thank you. Thank you Amanda, thank you Duncan. Fantastic and next week there's a completely different view oh there's another question coming in is there? Wait a minute. Yeah sorry Simon I just want to mention 1.6.2 just very quickly if I can. Of course, that's right. So in hindsight maybe we should have called this 1.7 because it was quite a substantial amount of functionality. 1.6.2 might be a disappointment then to everybody when I say there's not going to be a lot of feature or any feature enhancements in 1.6.2 but the team are working on a couple of security and bug fixes and so especially those people who are on the security mailing list for Redbox you'll have seen Andrews posted we fixed a few security issues and we'll be doing some bug fixes so hopefully I'll get an ETA out in the coming week or two about when 1.6.2 will come out but yes it won't be anywhere near the size of what you see in this current release. Thanks Simon. Thanks Duncan.