 OK, so you'll see, I'll post the URL. Can someone let us know when the stream is coming through? Oh, it's not on. It sounds like you're typing so we need to do the markup. What's that? It sounds like you're typing so we need to do the markup. Yeah, it says that, but it is coming through. Yep, it's working now. You're good to go. All right, so I'm going to count to three and see if you can look out the lag. One, two, three. Have you heard one, two, three yet? Oh, well, Michael, do you want to lead off? You're more committed to the agenda than I am. Yeah, hi everybody. Sorry, I'm not in the office at the moment. Yep, there's the delay. This meeting is supposed to be focusing on things that are happening outside of the middle HQ. So we're going to start off there. And one of the people who's been doing some work outside, although he claims it's not really significant, was Jamie, and Jamie's been working on the mock submit of forms, which is very useful for unit tests and so on. And I thought, well, we may as well get him along to have a brief word about that. So, lead us off, Jamie. Yeah, hi. I've been working with the OU on some, we're redoing the quiz reports, and we wanted to have a thorough unit test kind of regime before we started developing the new code for the quiz reports. So one of the things we wanted to do was to be able to generate questions. We're using the new data generator framework to, in the unit test, be able to generate questions which could be added to quizzes. And those quizzes be supplied with data, with student attempt data, so that we could then build up in the database some test data to demonstrate what, to check that the stats were being generated, being calculated as expected by the stats code. So along the way of doing this, this was actually Tim's idea that it would be nice to have a way to submit, have a test to submit data to the question forms, the question type editing forms, and to then get the data back from the form and then save a question and using the question type code. And then check that the question, load the question again, and check that the question was as expected after we've loaded it again. So we, I'm not sure if this kind of duplicates what's been done with Behats, but it's on a lower level. So we're working at a much lower level with the question engine appy to just to thoroughly unit test all aspects of the quiz and the question code. And so what we've done, what Michael asked me to talk about was this method that I've added to the forms lib to simulate a form submission. And all that code does, it's very simple. You pass it an array and the array is just in the format that you'd expect the post data to be in. So we've got something popped up here that looks to be the tracker issue. And so we can simulate, we can inject post data into the forms and then use get data to get the data back out of the form as if the form has been submitted by a teacher. So we've been using this for the question editing forms to test that their work is expected. We would have liked to have been able to use to instead of passing an array in the post, the underscore post format as you'd expect to receive in the PHP script. We wanted to maybe use set data to load up the form with data as if it was being loaded up from the database, the data in the format as it would be loaded from the database and to have set data, set the defaults in the form. But that didn't really work. We couldn't do that because of some weirdness in forms lib that when you try and set the default on some of the form elements, the select form element was the problem. The select form elements in the question forms has a grade, we have a grade select form element in the question forms and with the float value that was the float value as a string that was the keys for those select form elements, there was a weird bug which meant that the data wasn't getting through to the get data. We weren't able to get the data out of the form. So we went with using post instead that we simulate, we inject data into the post array. Instead of what would be more useful would be to be able to not to use data in the format that we'd get it out of the database rather than the format that we get it out of the, it comes through via post data because basically you just get post data out in the same format it went in, it comes out of get data in the same format. So that's a kind of a long winded explanation of what I did in not very articulate explanation perhaps. I hope those who are interested could follow what I said. If you have any questions about what I did then. Well I had a question and Tim sort of already answered it and that was to do with validation. So obviously one of the reasons you'd want to do this is so that you could test the validation of a form and Tim suggested in the dev chat that you can. Yeah that's right. We've injected post data into the form so it's just as if the post data has been submitted in the form so you can check to see if the validation fails as expected or passes as expected. And if the validation hasn't passed then you can't get anything out of get data. I did quickly, very quickly just write a few words on the dev wiki about this new method. But it could do with fleshing out a little bit maybe. I'll post that. Yeah forms lib is a crazy beast. I wonder if anyone's got any plans to replace it to maybe do something else. I think everyone has plans to replace it. It doesn't mean it's happening though. It's been quite a large job too. I guess we could have two forms libraries going on at once in Moodle and gradually move over from one to the other with a similar appy in each of the libraries maybe. There was some discussion at the hackfest last year about it but I can't remember where it got to actually. But yeah that's one approach I suppose. We have a lot of things that will be half migrated from one system to another and end up with two half systems. I don't know if it would be interesting to have a discussion about forms lib actually. Anyone wants to say anything? I mean was this like too impossible to do? This kind of this addition you've made was it? Oh no it's very easy. It was just one method added to the one class. I've got some diffs here that I could. You can share your screen. The screen share button on the side if you want. Shall I post some links in the dev chat? I wonder how big a job it would be to replace forms lib with something more. It's a maze of code. I said so at the time. I felt a bit bad that I maybe didn't say something sooner or didn't try and get that up the command chain a little bit. I guess you and Peter must have looked at the forms lib code and decided you wanted to go with it. At the time there wasn't many people saying no to it. I still haven't seen a really good description of what it should be doing better actually. There's a strange kind of event appy going on in there that I don't really see the purpose of. It would be nice if it was more cleanly. I would have thought you could follow a much more simple object oriented approach to making a forms lib for PHP. I would think if someone did produce something that it might be quite popular because it doesn't seem like there's many alternatives to pair quick forms. Is it because it had all this support for client side validation which I don't think we ever even implemented it. It had all these quite advanced features in there in quick forms. There's a weird kind of event responding functionality in there which I didn't really, maybe it's got something to do with the client. I don't see how it would help with client side. Yeah, I don't know. I never really did much with forms lib myself. There's some comments there if anyone's watching this afterwards. There's a discussion going on in the dev chat about what we talked about at the Hackfest last year. There was sort of a working group talking about it. We split up into discussion groups. There was some notes on the Hackfest page so if anyone's still got up, it's probably there. But there's no actual plans to do anything at this point. It's not scheduled or anything. It's just floating around as it has been for a while. All right. Have we talked enough about forms? I'm good. Well, thanks Jamie for sharing that. I think you'll probably find a few people using it now that it's available. Yeah, the next item on the agenda is Google Summer of Code. At the moment, the Google Summer of Code is about halfway through. In fact, at the moment we're being asked to do the midterm evaluations. So both the students and the mentors involved and we have seven projects on the go. So we're all putting in that sort of evaluation at the moment. All the projects seem to be proceeding bar one. One of the students seems to have gone AWOL. But you should start seeing some requests for testing coming out of those projects soon. If you're particularly interested and I hope you'll find some of them interesting because they're quite interesting projects. Anyway, you can go to the Google Summer of Code page. It's linked off the agenda. And go to the projects for 2013. All of the projects have various project pages, an individual project page and on that there should be links to the various forums that the students are posting to and trying to engage the community through those forums. And that's where they're going to be asking for testers to come forward and have a look at their project code. Some of them are ahead of schedule so they've almost got workable products ready to go. So yeah, you should be seeing some of those requests coming out soon. Is anyone else who's involved in the Google Summer of Code want to say anything at the moment? Yeah, so Tim said that one of his students has disappeared. Which one was it, Tim? Which of the projects was affected? So it was the pronunciation one, which is a shame because it looked like a good collaboration with James as well. Why are you just pausing anyway? I just want to test this lag so we have a better idea of how long it is. I'm going to say now and I'm going to type now at the same time. When you hear it, type now. My gosh, that's a massive lag. That's not even finished yet. Even if other people have typed it, if it just happens to you, you just type it anyway because you can see how different lags are going to be. That's awesome. So there's between 45 seconds and a minute lag for most people. So we're not going to have a lot of discussion between the audio and the chat. So we're just going to try and manage that. Go on, Michael. So there was some discussion on the dev chat about one project. So Thomas posted a link to a discussion on the Global Search project. So if you're interested in the new Global Search, that's hopefully going to come from that project. You can follow up on that. Some of the other projects, I was just going through them. There's a self-assessment activity using the question bank. There's a scorn player rewrite. I mentioned Global Search. There's a course search project that Marina is mentoring on and I'm helping her out with that. There's another one on determining quiz authorship using biometrics, which looks rather interesting. And there's a portfolio plugin for Evernote being developed. So if you're interested in any of those projects, head over to the Google Summer of Code docs page and follow the links from there to the project page that you're interested in and see if you can get involved, at least in the testing. And those students will really benefit from your experience, I'm sure. All right. Well, that's all I wanted to say about Google Summer of Code. Did you want to talk about the accessibility stuff, Munn? Right, yeah. Well, just in general, hang on. Let me turn off the screen share here. Yeah, so nobody likes doing accessibility. It's fairly dull stuff for most people. But we have a bunch of accessibility review issues. Issues that were turned up during big accessibility reviews sitting in the track for some time. We did a push in January at Moodle HQ and we knocked off nearly half of them as a group. So that was quite a good push. But then the other half have been sitting there for a while. And we've been hearing from some of these accessibility groups like the National Federation for the Blind that they're not happy about it. Because in some universities, in many universities I think, they have an accessibility requirement. And Moodle doesn't, we don't have a certification as such to any particular level. And they are putting some pressure on us to conform. Otherwise they won't be recommending Moodle for use. And that's not a good thing to kind of have people not be able to use Moodle just because of that. So we are putting an extra effort in there now. And there's a sprint going on now with the front-end team which I think we described last time. If anyone needs to have the front-end and back-end team explained, let me know. So the front-end team who are focusing on all the user-facing, usability stuff in Moodle at HQ is working on a sprint which is almost entirely accessibility issues. And there's a whole bunch of adding, aim, not tags, what's the word? Attributes onto things. A lot of little things. So yeah, that's happening now. But if there's issues linked in the agenda there, if there's any of those you want to help with or you want to say anything at all if you want to help at all or help us focus on it, then that would be great. That issue is the one to look at. It's actually not an issue, it's an epic and it has a lot of issues tacked onto it. We won't even have time to even tackle them all. So if you've got some time and you want to help, then we'd really welcome your help. After this is done, hopefully try and shoot for some level of accessibility compliance. Yeah, so the front-end team is working on about a third of those issues in the epic at the moment. They might get through a bit more, but yeah, if anybody else is wanting to help and help Moodle gain that sort of accreditation, we'd really welcome that sort of support. Yeah, start from the bottom lines if you want to write any code for anything. So that's all I want to say about that, really. Other than, you know, accessibility is important. The front-end team are working on, I guess, accessibility in every possible meaning of the word. So a lot of mobile interface stuff and general interface likeability and usability. Well, good. I don't know who the Mr. T of the MoodleA team is. Anybody has a guess? So that's all we're not going to work for anyone else because of the streaming lag, but anyway. Okay, so thanks all. And whoever's next, Michael? Well, next on the agenda is an item for server clustering. So Pett has been looking at a few aspects of server clustering and talking to some of the partners about this. It was an item of interest, so it made it onto the agenda. Pett promises that it's not going to be a lengthy item to discuss. So we'll cross our fingers and hand over to Pett. Thanks. I prepared a proposal some time ago and implemented a few things. You can see it here. And the current status is that, I think it was last week, there is a new directory called local cache there, which can be used to store information that is cached or separately on each cluster node. It should help with many issues on the clusters. So together with cleaned up theme caching and JavaScript caching, this part should be finished. And now we need to discuss the local clustering in MUC because if you want to create a local cache on a node, you need to deal with caching validation. And we also do not have yet browser sessions for MUC or some other types of backends. And another problem which was mentioned is the file storage, which is at the moment hardcoded into one directory. Some people proposed bakery factoring there. And of course we lack documentation and some guides how to set up the clustered sites, how to upgrade them, how to install them, how to set up databases and so on. So it would be great if more people could be involved in this. And yeah, that's pretty much all. Thanks Pett, so obviously this is still sort of a preliminary work only going into master and any sort of support from interested people would be welcome. Obviously that's something that affects clustered sites, so very large implementations across multiple nodes. There's been a lot of feedback from some of the partners on some of these ideas, so hopefully it's going to benefit the high end of our sort of scalability. Has anyone got any comments? I guess in sort of allowing for lag and that sort of thing. Yep, so month posted some information there. How long do we have to wait for comments? Dead air. I don't think there's any secretive things going on in the background here. Is that it? Yeah, it looks like it. I've made your face really big now, Michael. Oh, awesome. Well, I'll move on then. The next two items have my name, yeah, next to it. The first one being this item about patched issues, peer reviewing, and the peer review dashboard. We are very privileged to be able to have such a large community of developers and we really welcome the contribution that a lot of the developers make to Moodle. We've got some pretty well-established processes now for taking those sorts of changes and incorporating them into Moodle Core. Now, there is a problem that's arisen in relation to having so many people contributing and that is that to squeeze them through the processes creates a bit of a bottleneck sometimes. So what we have is we have a large number of patched issues that aren't being looked at very quickly. The teams at Moodle HQ do as part of their regular sprints have a proportion of the issues that they look at being patched issues, but there's probably more patches coming in than those teams can have a look at. Peer reviewing is also a bit of an issue in that we now have a number of people who are recognized as developers, at least in the tracker, and they are contributing solutions and pushing them up for peer review. Then some of them are sitting around for some time and not being looked at. We've had a bit of a discussion of late about how we can sort of resolve some of these issues. We don't have a really great solution for these. We're wanting to try and keep up with the amount of patches and work needed to do to complete peer reviews. One thing I wanted to ask for from people who are contributing fixes and putting them up for peer review is to also consider doing some peer reviews themselves. That might seem a little scary. I'll just share if I can find the right window. This is the peer review dashboard. If you're looking for some peer review work, it's sort of broken down and you can add this dashboard yourself in Tracker or you can just look for it and find it. There are issues on the left which are basically waiting for someone to come along and volunteer to peer review them. The issues in the middle have been claimed, if you like, so they're waiting for people to actually go in and do the work of peer reviewing them. Then the column on the right represents work that has been done on peer reviews. Thanks for sharing the link there. There's plenty to be done. At the moment there's 22 issues up for peer review, just waiting for someone to come along and volunteer to take them. If you're putting in an issue, maybe consider looking for something that you can help out with in peer review. The next question I guess would be, how do you do the peer review? I'll take you now to the peer review checklist. This is basically a list of things that you should look at if you're doing a peer review. It's not an unstructured exercise. We want to make it as objective as we can. There's all sorts of things that you should consider, not all of them are relevant to every code change, but it's worth going through the list. One of the things that we recommend is that you just copy and paste this checklist down the bottom into a comment in Tracker Issue. Then you can put in a Y for yes, N for no, or a dash if it's not applicable. That sort of becomes a bit of a standard for saying that you've gone through this checklist and seen where things are applicable. Then you can comment below that or in conjunction with that to point out things that you think need to be worked on. This list has evolved. If you've got any ideas of improving that list, you're welcome to get in there and add bits, but it's getting to be quite a nice mature document started off reasonably simply, but it's become quite complete. As I said, we're wanting to put more resources into peer reviewing. There are a few ideas that are going around at Moodle HQ. One thing that has been sort of informal as a rule in relation to peer review is the responsibility of people at various levels for putting things up for peer review. It says in the documentation that all people should go through the process. We've been sort of shortcutting people who are component leads, so people who are responsible for an area of code have been able to skip peer review and put their changes straight to integration. We're trialling a bit of a change in that we're asking component leads to put their code changes up for peer review for at least a week. If no one touches it after a week, it can then go straight to integration, but the idea is to give people an opportunity to peer review issues that they might be interested in looking at rather than some issues can go by so quickly if they're not peer reviewed. That's been formalized a bit more. If someone's working outside of their component, if they're a component lead in one area but they're working in another area, they'll need to do the formal peer review process like everybody else. I didn't have anything else to say in relation to peer review unless someone wants to chime in. Anyone at HQ maybe? All right. I think we're all good here. It's more what other people think. Yeah, let's just put component maintainers. Yeah, which is only really a small number of people. For the next issue on the agenda, and I'm promising I'll keep this very quick. I just want to share a bit of a slideshow. Can you see that? Yeah. Okay. Recently, we've been sort of looking at the way that we're organizing issues in hierarchical fashion in the tracker. For time up to now, we've been using issues with subtasks and we've been referring to those as meta issues. JIRA also supports a slightly different way of organizing issues together, and now that we're sort of taking on more of the scrum related aspects of JIRA, the system behind tracker, we're starting to employ that second sort of way of organizing things in a hierarchy because JIRA kind of enforces it at certain points. So I'll try and describe the difference between the two ways now. So let's just say you have a bunch of issues and you've decided that these issues are related. So you want to sort of group them together and sort of have a way of identifying that they're related. Possibly if they're independent issues, the best way is to create what's called an EPIC. So an EPIC is another issue and has a type EPIC in the same way that you would create an issue that's a bug or improvement, you can create an issue with a type EPIC. When you create an EPIC you can use that EPIC issue to link together separate issues and it forms an EPIC of work if you like, a grouping together of issues. What that allows you to do is to keep the independence of the issues that are being grouped together so that you can individually rank them and they can be implemented independently as well. In relation to what we're doing at HQ that means that we can give them different values when we're looking at which ones to draw into sprints for the scrum. And if there is a large number of issues, a good example is the accessibility work that we're doing at the moment. It means that we don't have to do all of the accessibility work in one hit and look like we're just doing half of it. It means that we can draw in an appropriate amount of issues in one sprint and then continue working on this in future sprints rather than saying we're going to try and do it all in one sprint. The other way is the way that you might already be familiar with and that is to create subtasks within an issue. Now we have been applying that pretty generally just to group issues together but what the idea of subtasks is meant to be useful is to take a single issue and break it down into some component parts. So from that point of view, those subtasks are meant to be ranked with a single value and implemented in one hit. And so that notion of subtasks is really only meant to be relevant to the developers who are going to be working on the task of implementing that issue. So in a way we have been a bit misusing this idea of subtasks in relation to what is expected in relation to JIRA. How do you make this all happen? So just say you wanted to create an EPIC. The first thing you want to do is create a new issue and when you do you can select the type which is EPIC and you have to put in a name for the EPIC as well. That EPIC name field only appears if you set the type to EPIC. Once you've created an EPIC you can link issues back to it. If you edit those issues that you want to incorporate into the EPIC one of the fields in the form there is EPIC link and if you just start typing in the name of the EPIC it will help you try and find it has a bit of a search thing in there. An issue can only be part of one EPIC. Once you've saved that you'll see on the issue that it is part of an EPIC and you can click on the link to get to the EPIC from there and the EPIC itself will then have a list of issues inside it. So it does the same sort of linking back and forth as you might be familiar with if you've been using subtasks but it's done in a slightly different way. Subtasks, so to say you've got an issue you've decided you want to work on it but you want to break it down into a few more workable chunks. You can do that by going to the more actions menu. Now if you're looking at the parent task you can say I want to create a sub-task for this or if you've found an issue that you think should be a sub-task of a parent issue you can convert the issue to a sub-task. If you're converting it leads you through a wizard and if you're creating a sub-task it leads you through the process of creating a new issue. Unfortunately it's not as easy to do batch changes working back and forth between normal issues and sub-tasks. They're meant to be pretty much stuck as sub-tasks when they are sub-tasks. What you get on the parent issue then is a list of sub-tasks and here you can see it expects you to complete all of those tasks, the sub-tasks in order to say that the parent is completed which is a bit of a distinction between that and an EPIC. In the sub-tasks themselves they're sort of apparently linked to the parent issue by looking at the bread crumb at the top for that issue. If you're wanting to get a textual view and come back and wonder whether should I create an EPIC or should I create an issue with sub-tasks there is some documentation for this in the bug triage page. There's also some in the document for creating issues but maybe not in the same sort of rationalization approach. So you're welcome to go in there and have a look at that. If you've got any feedback on that please let me know. Alright, that's probably enough talking from me. So what was next on the agenda? Moodle 2.6 Project Progress. Alright, does anyone want to talk to the mobile device improvements that we've been working on, someone from the front-end team? Actually Michael maybe there was something added at the last minute on above. Do you want to tackle that at the end or? Sorry, I'll refresh. Back up and restore improvements. I see. Alright, well I completely missed that and my apologies. We should probably tackle that now before we move on to the progress item. So Mr. Russ, Andrew Nichols, you're up. Well I think Tim added this one. I didn't know anything about it until he added it and I refreshed the page. But I don't know if you remember at Hackfest we talked about doing fileless backups, putting it back up in the store on the same site to try and improve some of the performance, that was particularly for people running multiple servers because I think NFS make it really slow. So one of the things we've done recently, I can't remember the issue number, but we've now got fileless backups for the same site. So if you're duplicating a course using the web services file course imports, so when you go into a course, you click the import button and do the backup restore that way. Then we get fileless backups so we don't go to the data store, grab all the files, stick them into a directory, copy them all and restore them only to throw them away. So we've done a lot there to try and improve some performance. That also happens for activity duplication. So that should all be a lot faster. And Russell Smith at the University of La Trobe in Melbourne has been doing a lot on profiling and fixing performance issues. I think mostly that's been related to the quiz questions, but I don't know if he's around to talk about it some more. He's been doing a lot on general profiling and I think he's done some stuff so that you can compare multiple performance benchmarks from XH Prof against one another. So you get, rather than just comparing one against another, you can compare multiples against multiples, I think it is, to get averages so that on multiple runs of an XH Prof comparison, you can get better averages. I don't know if Tim knows any more on exactly what he's been doing on the quiz side and other fixing performance issues, but he's saying earlier he's got a kind of 25% speed improvement on backup from the store. And I was hoping to get a chance to look at finding out why when you've got lots of course modules on a course, we use a lot of memory because we were doing some backup from the stores the other week. And for a small course with only about 60 or 70, I think it was course modules, we were using 7GB of RAM, which wasn't so good. So that's one of the things that we're having to be looking at soon. But that's all I have on backup from the store. So if Tim has any more to say, or Russell hasn't, I know he's in the chat, but it is 1 AM in Melbourne, I think, so he might be asleep. Actually, it's quite surprising it's taking so much RAM because one of the reasons for the backup rerun was to do that was to chunk it up more and keep it in smaller chunks. So I don't know, is it interesting that it's being found? Yeah, I don't know exactly why it's doing it. I think it's something to do, or Russell was suggesting it might be something to do with the amount of times that we keep reparting the XML file because we do it for every single course module I think it is, which obviously gets quite a lot of XML parsing. And if we don't throw that away properly, I guess that could be related. But I haven't had a chance to look properly. Right. Cool. I'm throwing this here because I can, but my personal pet hate with backup restorer is how long the interface is. Yeah. It would just be lovely to have that, because I bet you in the 1999 sort of time people just back up everything or restore everything. There needs to be a skip to the end button or something that you can just accept all the faults. Yeah. On the course module duplication, at the moment we've got the links in the course page to duplicate something, and that takes you away, but I'm hoping that for 2.6, if we get some time to do some JavaScript at the time, we'll be able to make that an Ajax confirmation as well and duplicate it on the page. But yeah, we could do the same thing for courses somehow. No. Cool. Cool. Our course looks really good this issue. Thanks. I'll just put it up on the screen a bit. So you're still there, Michael? I am. Okay. So... All right, yeah. Thanks, Andrew. Good job, mate. Yeah, zero notice. That's right. Yeah, so who from the front-end team would like to raise a few of the improvements that have been done particularly on mobile devices and so forth in the last front-end sprint? I can talk about a couple of them. I haven't got the tracker numbers, so then we looked up the tracker numbers and put some in the chat and look at that. What we did when we started this round of sprints is we went and gathered up all the devices that we have, all the different devices and the different browsers, Android and different versions of iOS and things like that. And we often did a whole bunch of testing all over Moodle to find pages that weren't working nicely on mobile, pages that weren't working at all on mobile and pages that were okay but could do a little bit of improvements. And from that we raised a whole bunch of issues in the tracker. Some of them were big issues and some of them were little issues and we've been slowly working through that list. So some of the improvements that we've already done for 2.6, for example, there's the full-screen pop-up for the file picker and activity chooser. That's actually been done in call dialogue. So anything that's using a call dialogue if the screen width is less than a certain size, that dialogue will show as full-screen. So basically you can imagine on a mobile phone it doesn't really make much sense to pram a full or a page into a dialogue in the middle of the page. It really just wouldn't be doing one thing at a time and it makes sense when you're using it to just have that take the full screen and then when you pick okay, it takes you back to the screen that you're on. So that one's up for integration review for next week. Again. The other one, we've been making some changes to TinyMTE. So the first thing is that there's a lot of problems with TinyMTE not being able to be re-sized and not being able to be sized down to a small size. So if it was on a phone it would be hanging off the right-hand side of the page. So we've changed that so that the icons can now, the icons in the toolbar can now fold nicely and the actual editor itself can be made small enough to fit on a mobile phone. Jason's added a new version of the Collapse Toolbars plug-in. So we had a version that was just a hired show but the new version basically lets you toggle between one and three rows and we re-ordered all the buttons in the TinyMTE Toolbars so that the ones that you want to use most often are in the first toolbar and that's the one that you see by default. And then you have a button to see the extra buttons so that looks a lot better. Jason was looking, was wondering about TinyMTE themes as well because one of the other issues that we're looking at is backfording all of the icons from TinyMTE 4 into the Moodle version of TinyMTE which is TinyMTE 3. Yes, we've been checking out our right to left issues on mobile as we've been doing all the things we've been working on. One of the other issues that Sam has been spending a lot of time on is looking at the activity icons in the course page when you're editing the course page. So having a row of very small icons very close together is impossible to use on a mobile phone. You have to pinch and zoom right in to be able to click on the icon that you want to click on. So a solution there is something that's been talked about and worked on in the past and we've now gone ahead and that's been integrated this week. But the icons, the editing icons, there's a few more changes to go on these editing icons but you now get a drop-down menu next to all of the activities with things like edit, title and move left and move right. So they've been changed from a row of icons into a menu which seems to work quite nicely and the buttons have been made of the icons that open the menu are a little bit larger and have a bit more spacing so you can actually click on them on a mobile. I think that's probably the most significant stuff here. Yeah, that's most of the big stuff that we've been working on for mobile. We're obviously doing the accessibility sprint this time as well now so there'll be a lot of changes for screen readers and keyboard navigation and things like that. Thanks Damian. Yeah, the front-end team will probably still do more work on mobile device improvements in the future. It's going to take a bit of a backseat for a few weeks while they work on accessibility stuff. The back-end team has been looking primarily at leading to a new event and logging system. Events has been the first target and that's going to be used as the basis for the future logging system. One of the critical changes needed to achieve a new event system was an automatic class-loading system and a pet is going to talk about that. Is that right, Petter? Yes, I am. Well, if you didn't try automatic class-loading yet, please do it and I'm sure you will love it. So from now on, whatever you work on you should be using automatic class-loading. Can you show how it works? Well, it's a magic. It just works. The only problem is you have to name your classes the right way and you have to put the class files to proper locations and both of these are pretty simple. You just start with a Franken-style prefix and you put it into classes subdirectory in your plugin. That's all. And then you just use the class as before and you don't have to include anything. Any questions? What are the benefits of using this? Well, it takes less memory to load everything. You can just load PHP loads only classes that are really necessary. So if we have a PHP file with a few megabytes of data which is used only in few areas, instead this includes only the classes that are necessary. And there are no benefits for administrators when running Moodle. It's mostly for developers because it's easier to organize your code. You don't have to think about how to name your classes or how to put them like before. Oh, how to include them. So any questions? Well, I suppose... Oh, one thing. I forgot to mention that we have also kind of automatic class loading for PHP unit. You had to type PHP unit or vendor slash bin slash PHP unit and then a path to the test file, test case file that you want to execute. Now you can just type the class name after the PHP unit and the loader for test cases tries to find the appropriate file included for the test. I'm going to improve it a bit more this week so that it works in sites of directories for the core subsystem. But at the moment it is fully working for your tests in plugins. All you have to do is to use the same style for class names. All test cases have to start prefix and they have to end with the test case worked and they have to be stored in a similar files for the auto logging but with extension test test.php So after that you can just do PHP unit space and then name of the class 8 enter and it gets executed. Well, I would have hoped at this stage if anyone had any questions they could have asked. So I think that is going to take a while to dawn on people. But hopefully it will get in there eventually. All right, which leads nicely into our discussion of events and logging. I know Marina is there, Pet is there and other people, Fred is there Adrian and so on from the back-end team. Marina maybe you would like to have a chance to say hello and you are not in the hangout so she will recognize that she can't do that in about 40 seconds. Fred, did you want to say something? I don't know where to start though. So what's new about the new events too? The way the events were working before was that you would just set up any name of any event and you could listen to it anywhere, which was pretty easy. The downside of it is that there were no rules on what data to pass and there was no consistency between the different places where you were actually throwing events. So as we were working thinking about implementing a new logging system we thought to tie that to work with the event system. The event system we would trigger events in much more places than before but in order to have consistent data we had to create some format, some sort of rules so that the logger would know what to work with because the problem we had now with the logging system was that there are data passed from one place to sorry, I don't really know how to express myself. There were places where loads of data would pass so that the logger could do a lot of things with it and other places where it was less important less data would pass then same with the event so we had to standardize all that and we decided to create one class for it which can be a bit scary at the start but the good thing of that is that the event itself is self-documenting so you know exactly what it's going to contain, where it's coming from, what it's doing and why and so when you capture this event you know what to expect what kind of data you can expect in there the new thing also is that so the observer of those events will work a bit differently you will not be able to listen to all events which might not be something that we would recommend but the logging system will work like that we will listen to everything and then decide what to log, where to log it etc so yeah the automatic class was also implemented for that you don't have to include anything to trigger an event the class will be loaded following its name and yeah I don't really know what else to say about it Kara you might want to complete my brief explanation yeah can you shut this please pet is busy filling in the issues yeah frankly we can see what you're doing pet yeah so I don't know if there is any question about the new event system don't know if I if my explanation was clear alright so we're going for a much more structured event system something that's built for speed something that's going to be able to handle small and large amounts of information something that we'll be able to feed into multiple handlers including potentially multiple logging outputs yeah so a lot of potential benefits in a new architecture there well Tim that's for speed because for now we load all the events in an array and so we know which one exists and which ones don't and we can easily capture them all or just capture one if you want to have more to dispatch the event to specific observers with more strict how to say with different criteria would be much slower and could be costly so we decided to go with catch all or catch one and if you catch them all you can just filter by yourself those you don't want to listen to I mean so that's work that's still ongoing the events and logging system work is sort of dovetailing into each other we're trying to see what we can get done for Moodle 2.6 at least the underlying architecture but there's a lot of little changes to be made along the way in relation to the the existing events and logging calls which is going to take us some time and then there's a whole bunch of improvements that have been asked for in relation to the richness of logs which we'll follow on from that so definitely something to keep an eye on and hopefully that'll help lead to better analytics yes Scott I just came there because we were talking about this again today so with the logging this logging 2 spec will be changing pretty soon with some stuff from PETA which is currently on the discussion page and we're going to be working on that quite heavily in the next very short time so the whole logging proposal is kind of big and complex so if you're only involved in an early stage now's a good time I guess to watch this page and watch it change in the next few days or so yeah so just pointing that out I think the goal for 2.6 is hopefully to have logging working more or less like it did in 2.5 in terms of where logging some stuff but there won't be too many new features other than you can start writing your own plugins to do cool things and that's all excellent alright the only other thing on the agenda is this the most anticipated change in Moodle ever I'm referring to the alternate name fields a billion people in Asia celebrated there was parties in the streets when this was implemented and Adrian Adrian Grieve was one of the people instrumental behind that there are some implications for developers Adrian is going to talk about that now I hope okay not much of a build up there yeah yeah well basically I think the main people pushing for this sort of change where people from Asian institutions the Japanese Middle Association strongly pushing for this change basically said that in their Moodle instances they can put phonetic information in there and make it easier to look between different students and differentiate between between them so basically what's happened is we've added four new fields to the user table these are name fields basically we've given them names as to how we think they could be used but they're not definitely don't have to use them how they're labeled at the moment I think we've got phonetic first name phonetic last name middle name and alternate name but you can change it to use it exactly however you want in this change we've moved one of the settings the full name display we've moved from server site policies now it's been moved to user profile information or something like that basically that's very well the other information regarding displaying user names is located and it seems silly to have just that one setting somewhere else another thing is that we've implemented placeholders this is so that you have more flexibility about how your names are displayed as opposed to just having first name and last name you can now put brackets around it or commas or colons or any other sort of punctuation just to make it easier to read is it on display? well I mean I could pull up my instance of Google which I guess I could show you sure it's good we need more demos it's not like demos of these things there's at least half of one there's not much to show you but it's inversely okay hold it right yeah sorry it's in Japanese at the moment okay so we'll go to the setting now where it's currently located as you can see here we have other user profile information and down here is the new setting well old setting re-implemented here these are the placeholders I've included here this is a Japanese style bracket which is what they use over there instead of normal ones well normal is subjective I guess so what I've got here is first name, last name and then the middle name now I'll head to a course and this participants phase should show people with middle names being displayed so not everybody has the middle name there this is if they don't actually enter their information in then it will sort of remove the punctuation around it it's not full proof if you want to try and break it I'm sure that you can but basically we went for simplicity for how to remove that information rather than a very complicated regular expression another thing that I may just like alteration to is the edit page that's a bit quick as you can see here the middle name has been displayed right next to the first name and the surname if you put the placeholders into that setting they will become available in this section here and they're just over once the ones that haven't been implemented around in this section here and that's that's pretty much it from this side of things it's all fairly fairly simple basically what developers have to look out for there's a question sorry the user has no control over what's displayed at the moment basically we're looking just for a fairly straightforward implementation to start off with and then any further enhancements will come down the track at the moment only the administrator can determine what names to show you getting to my other point developers anybody that's made any plugins and may find a developer warning saying that they need to provide more information to be supplied into full name basically the user class needs the four additional name fields it will just pop up a warning when it won't actually go off and do any searching itself so that we don't make any unnecessary database calls but I've created a dev.page explaining probably the best way to go about getting user information sort of recommend using the user picture class to get everything that you need so questions there is an equivalent function to the user picture one that if you're not intending to output a picture yes I've created a new function which basically has all of the name fields in it it gives induction to either output it as an array or as a stream if you output it as a stream you can actually specify an alias to go with it so that you can easily go into an SQL statement and yeah I'll link to that docs page yes I think we lost the go back yeah this is the oh good I added a new page here so this is the option name page this is basically just the specification for information regarding development this is probably the better page to have a look at I just started it so it's probably missing a little bit of information but should give you a good idea as to what to do and that's where I got to today Michael anything else? I think we've covered the agenda there's some extra questions that have been added and I don't know if I'll do a refresh to see if there's any more there is another question for you on the dev chat while I'm looking at that Adrian if you just specified auto name on its own and didn't put any other information into the setting if it hasn't been filled out the auto name it will be back to the first name just the first name? just the first name basically that was for reasons basically we didn't want to that if you set it to first name in order to provide the information that it reversed back to first last name well are those all the dark questions? well it's that standard supporting metadata for courses, resources and activities Roodle Hub not sure what that's about okay I haven't seen that one in the dev yeah it's all pretty old well yeah I can't really answer this I don't it would be nice to have a list of the use cases for it what's the is it just so you can add an exchange hub you can add metadata to courses resources and activities yeah it's probably it's hard I know there's been several efforts at writing a spec for this in the past they haven't stored yeah we do maybe someone needs to write a new spec and maybe in this issue in fact but I can't really read all this there's no plans to work on it right now probably the only place I'm seeing anything like this being done is for LTI activities in those LTI repositories like explore and things like that yeah it seems to be that we need to have some problem for some way of doing it for every single item in Moodle so that's the the full addressing of course module and item and everything so then we would apply across it would sort of be a layer lying on top of everything rather than adding new fields to everything that's what I would think but that's quite a big job it's every now and then someone will have a project like that and they'll need to they want it something that comes up that often there's also a global search the global search project happening for GSOC which might be worth a look at for the search part anyway second question what's the standard experience API well I can start from the last one the future of SCORM is not much we're not going to do anything more with SCORM I don't think I think anybody wants to the LTI version 2 we will get there when it's I don't think it's released yet is it but I'm sure the LTI module will be updated for that CMI 5 I know nothing about personally never hearing about it and the Tinkine API is as far as I'm concerned mostly something that we will produce data for so the new logging stuff you'll be able to stream that data out in Tinkine format via a plugin or something you can convert our logs our logs are like a Tinkine stream so people can write plugins to do that quite easily I would say we're also looking at the Tinkine spec for the verbs that our logging uses so they'll be really quite close but I'm not massively excited by Tinkine personally every time I've looked at it I'm not seeing a lot of use for it except in SCORM-like situations if somebody wants to write a Tinkine activity module for Moodle they're obviously completely free I think actually there were some plans to try and work that into SCORM but I'm not sure no I think no we'll keep SCORM but almost nobody moved on to SCORM 2004 they all stayed on SCORM 1.2 so I'm pretty glad we didn't spend six months required to work on that it just never was useful but there's a lot of SCORM stuff out there and SCORM will be maintained for a long time so SCORM packages running at Moodle yeah I haven't been following it maybe someone else can talk about SCORM Dan you're here actually what a comment I'm guessing Moodle rooms might work on LTI version 2 they're currently the maintainers of the LTI module comparatively so I think it's probably their interest to do that if they don't we'll pick up the slack at some late point but they haven't said they're not doing it last question theme clean is the new standard theme it's not right now but we really want it to be or something like it but I don't think we've decided to make it the standard theme yet I mean unofficially it's kind of a bit in early experimental mode really it was put in pretty quickly and there are quite a lot of bugs being discovered in it so they're all being fixed the front-end team are working a lot on it but ideally it would be the standard theme I don't think the other themes have been deprecated for quite some time like over a year hopefully the pool to those bootstrap mobile first themes are going to be so strong that everybody will want to move off their old themes anyway just to get all the mobile stuff got to get them off 1.9 first yeah or leave them on my mind alright there was a question a bit further back well first of all someone asked why are we doing the meetings at this time regularly now and I should apologize to all the Kiwis it certainly it's not the greatest time when you're in Australasia and if you're in New Zealand well it's rather nasty we we did try rotating through a number of time slots but every time we changed we'd get objections and this time slot seemed to be the least objectionable time the other thing too was by adding reliable recording through YouTube we sort of thought well maybe we could have a regular time slot but we wouldn't disaffect everybody so we're going to try this and it seems to be going alright so far there was another question as well further up about the hackathon the hackathon we pushed it back we pushed it back again and then we decided is it really going to have benefits while we're all rather busy and we we decided well we could just put it back indefinitely or we could just sort of can it for now so apologies to those people who are really looking forward to a hackathon yeah other things took precedence and we've decided not to hold it now okay alright is there anything else Martin you can think of any other news no I think that's it I can stick with too many things that's the problem we can just start talking about all the hundreds of issues but I think these are all the main things that are going on one last little thing we are if you haven't heard we're running a MOOC to try and help teachers learn the Moodle it'll be throughout the month of September so that's been quite exciting for the site team to set up a server for that club on the cluster we started out on Amazon and we actually gave up on Amazon support we've gone to digital ocean now for those servers and that's working out okay and that's that'll be almost a vanilla Moodle site with a couple of small hacks and mostly just showing how configurable the Moodle site can be and how scalable hopefully lots of teachers get into that four week course so if you know some teachers around the place who probably need to learn Moodle you might want to send them along and that's about it for me I think we can probably wrap it up thanks everybody for joining us and I think by the numbers it's possibly the largest list of attendees that we've had and I suspect that there's even more people who aren't in the dev chat that are just following along on the YouTube stream so the message is getting out there so we're really grateful for you guys joining us and we hope that this meeting has been useful for all the developers and everybody else out there we'll do it again in two months it'll be our pre-release sort of equivalent meeting and you'll get the scoop on what's in and what's out and so on alright I'll leave it up to Martin to close up the meeting because you've got control okay thanks all good night from Perth thanks for coming along everybody I think we peaked at about 46 people so that's not a bad turnout sorry about the delay between the video and the text that's annoying and annoying so we'll see you all next time and drop in on the dev chat chow all thanks everybody bye