08:15:21 #startmeeting 08:15:21 Meeting started Thu Jun 5 08:15:21 2014 UTC. The chair is yuliyabozhko. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:15:21 Useful Commands: #action #agreed #help #info #idea #link #topic. 08:15:38 thanks dobedobedoh 08:15:43 thank you dobedobedoh 08:15:47 ghada: It's running on my personal VM 08:15:51 shall we carry on? 08:16:17 someone should write meetbot instructions 08:16:20 intros again? 08:16:33 might be easier than trying to combine things later 08:16:38 yeah, we just started anyway 08:16:51 #info ghada is Ghada El-Zoghbi, developer at Catalyst IT, Sydney, AU 08:16:53 #info tobiasz is Tobias Zeuch, developer at the KIT, Karlsruhe, Germany 08:16:54 #info anitsirk is Kristina Hoeppner, Catalyst IT, Wellington, NZ 08:17:01 #info yuliya is Yuliya Bozhko, developer at TotaraLMS, Wellington, NZ 08:17:06 May be we can intro, and then someone copy-paste previous discussion you had before meetbot woke up 08:17:10 yuliyabozhko: you’d need to paste the agreed action. i think it only shows up from you as chair 08:17:23 #info rkabalin is Ruslan Kabalin, Lancaster University, UK 08:17:26 #info sonn_ is Son Nguyen, Catalyst IT, Wellington, NZ 08:17:29 #info robertl_ is Robert Lyon, Catalyst IT, Wellington, NZ 08:17:29 irc://irc.freenode.net:6667/#info simoncoggins1 is Simon Coggins, TotaraLMS, Wellington, NZ 08:17:33 anitsirk: will do 08:17:39 oops 08:17:55 #info simoncoggins1 is Simon Coggins, TotaraLMS, Wellington, NZ 08:18:04 dobedobedoh: can you please introduce yourself for the meeting minutes too? 08:18:49 if that's everyone, we can carry on then :) 08:18:51 #info aarowlaptop is Aaron G. Wells of Catalyst in Wellington NZ 08:19:07 yep, carry on 08:19:09 #topic Items from last meeting 08:19:14 #info everyone to look at list of enhancement suggestions made by the Ljubljana group 08:19:35 #agreed everyone need to comment on the individual items from enhancement list in the forums / bugs and then talk about them if needed 08:19:44 I am just adding what we agreed on 08:19:54 #link https://mahara.org/interaction/forum/topic.php?id=6283 08:19:55 yep. that’s fine 08:20:12 #info aarowlaptop look into gerrit update 08:20:30 did you have a chance to look at it, aarowlaptop? 08:20:46 No, I haven't looked into that yet 08:21:09 gerrit is currently on version 2.6.1 and can be updated to 2.8.5 which has quite useful features 08:21:29 Yep, I'm definitely in favor of upgrading, just haven't gotten round to it yet. 08:21:38 would you like me to added to the next meeting agenda? 08:22:17 or would you prefer someone else looks into that? 08:22:17 Sure 08:22:30 We should still upgrade, so you can put it on the next meeting agenda 08:22:36 ok 08:22:40 #action aarowlaptop look into gerrit update 08:23:05 dobedobedoh: is Andrew Nicols @ Moodle Pty Limited 08:23:12 #topic tobiasz on non-reusable textboxes: new block type or diversified interface for existing one 08:23:30 We repeatedly had users complain about text boxes in copied pages, when they didn't notice the hint about the shared notes artefact and accidently overwrote the content of the original page. You find the discussion in the forum here: https://mahara.org/interaction/forum/topic.php?id=6257 08:23:39 I'll give a quick summary 08:23:57 I had found an old discussion touching that topic when the feature of reusable text boxes was announced (in 2011) and I think the idea back there was to add a switch to the text box between the reusable/artefact-related functionality and a plain version. Aaron, however, had the idea to split the functionality into two separate block types. 08:24:09 I think the solution with two artefacts is cleaner, but it should be clear to users, which one is which. Aaron suggested the non-artefact-related block type to offer a simplified interface (e.g. no file attachments). 08:24:24 My idea was to move the complete editing functionality for the notes to the content panel and on the portfolio level only select the note artefact - where Kristina objected that users want to create content on the portfolio view. 08:24:29 #info users complain about text boxes in copied pages where they don’t see the hint and accidentally overwrite the original text. 08:24:30 So I'd like to clarify, if we want two add a switch to the existing checkboxes or rather two separate block types - and if so, how to distinguish them so users don't get confused about which one to use. 08:24:47 did you mention that it was on enhancements suggestion from Gregor's list? 08:25:08 This was item 2 on Gregor's list 08:25:09 ah, sorry, forgot that. It's also on the list of the enhancements from the Ljubljana group 08:25:15 "Copying of Textboxes should create real copies" 08:25:22 it had already come u pbefore gregor’s list though 08:25:23 https://bugs.launchpad.net/mahara/+bug/1296390 08:25:26 yep 08:25:38 #link https://bugs.launchpad.net/mahara/+bug/1296390 08:26:05 Yeah, my favored way of doing this is to create two separate block types -- one for one-off text, and another for reusable notes 08:26:22 #idea 1) make it distinguishable in one block that you can have re-usable notes and those that can’t be re-used 08:26:44 #idea 2) have two different blocktypes because then the non-reusable text snippets can have a simpler interface 08:27:17 i think that would be the best. the re-usable interface is already quite complex. adding yet another layer may be too much. 08:27:23 I also favor the second idea, I think it easier to explain that to the user 08:27:43 hmm, it should be made clear enough to users 08:28:10 while i favor that re-usable text boxes should stil be able to be created on a page itself, i think it should also be possible to create them under content. it’s the only artefact that cannot be created there but only edited 08:28:13 i think users will also want to 'convert' one to the other. 08:28:22 ghada: good point 08:28:37 maybe 08:28:44 yeah, might get complicated 08:28:56 Aaron suggested rename the actual textbox blocktype to "note" and call the new, non-copiable block type one text 08:28:57 does anyone want to write down some ideas on bug listing? 08:28:59 you might start out with a non-reusable one but then realize that it’s gotten so long / important that it would be good to keep. however, it might be easier to just copy and paste 08:29:00 i agree but there will be voices out there 08:29:36 ghada: it could be a future enhancement :-) 08:29:37 yes, copy/paste is always available. 08:29:41 exactly. 08:29:42 yeah, future enhancement ;) 08:30:21 i think fixing up the current functionality is more important. i also noticed that notes do not ever get deleted even when they don’t exist in pages anymore. 08:30:22 We have very small communities on mahara here, but I don't know any of our users, that uses the copyable feature on purpose. Are there users out htere that use them frequently? 08:30:28 how would existing text blocks be migrated? would they be notes or new textboxes? 08:30:34 tobiasz: i do 08:30:39 ok :) 08:30:58 i use it when i have similar text for templates for example or when creating a series of pages that are fairly similar 08:31:12 yes, one client (a school) does hits here in Sydney 08:31:15 sure. i could just copy and paste, but it’s quite handy that the title is available as well as all the formatting 08:31:35 and, we've got an outstanding bug for months now. 08:31:41 I wouldn't migrate any existing block types, though it doesn't help with huge list of notes that you can already choose from, from which most are not intended to be copied 08:31:41 I haven't used them much 08:31:53 but in general, it would be better to not be connected to the original from the start i think but choose that only if you want to stay connected to it. 08:32:17 Could be that when you delete a note, if it's used in any pages you have the option to "downgrade" those into standalone text blocks 08:32:20 ghada: i think that bug is different and related to their portal / firewall 08:32:25 that would be a relatively simple migration path 08:32:31 the copying functionality itself works as intended. 08:32:32 anitsirk: that would be one interface for both? 08:32:39 funny, these clients want it connected to the original text and are complaining that it's not linked. 08:33:00 tobiasz: that’s the tricky bit. 08:33:01 anitsirk: this is a different one. I fixed the firewall/portal issue. 08:33:14 ah ok, ghada. good to know that that works now :-) 08:33:27 :) 08:33:42 tobiasz: starting out with not being connected i think is trickier than the current behavior because you’d do it retroactivtlye 08:33:57 to best not open that can of worms. 08:33:57 good to hear the portal issue is fixed :) 08:34:14 robertl_: "fudged".... 08:34:24 :) 08:34:25 lol 08:34:29 But many users don't notice that the content is connected, especially new users 08:35:10 yes. we’ve pondered using a pop-up box but that can also be quite intrusive esp. once you’ve got it and still need to click them away all the time 08:35:11 tobiasz: i agree. and the ones who do use this functionality, get it confused. 08:35:43 can we actually have it "look" different? 08:35:57 ghada: in what wa? 08:35:57 that could be one of the options 08:35:58 way? 08:35:59 would it be worth having some indication on edit screen that the textbox is linked? like some header to the textbox in a bright colour letting them know 08:36:03 different colour background, more rounded corners, i don't know... 08:36:13 robertl_: it’s already there in red ;-) 08:36:20 From a new user perspective I would imagine it more the other way round: you write a text and then notice, that this is a snippet/note, you would like to keep for another page 08:36:27 not in the config form but the edit page 08:37:33 if reusable items and non-reusable items are in different categories, they would be seen as different 08:37:36 there's already a message at the top to inform the users that this if they make changes, it will change the original 08:37:55 robertl: I like that idea, I think if we'd stick with one blocktype, the difference should be more notorious than just a little switch or a small red text 08:38:12 having two blocktypes would make it clearer i think 08:38:24 noticable, not notoriuous 08:38:25 I agree with anitsirk 08:38:25 adding more to the edit screen might be overloading that one. it’s already very busy 08:38:54 because then users would make a conscious choice between just having plain text vs. creating something they can re-use. 08:38:56 yeah, that was my thought 08:39:03 it can be one block with two options 08:39:17 anitsirk: agreed. 08:39:24 and you probably only re-use in very specific cases. i re-use text boxes for similar content or for the same content, in particular instructions on templates 08:39:47 any other ideas? 08:39:50 there i really only want to update one copy of the textbox and have it updated in 10 other pages without having to go into every single one and update the textobx manually 08:40:42 i guess we’d need to figure out what to do with the current notes. what about having those that were re-used as re-usable blocktypes and the rest as simple text? 08:40:43 would having a confirm prompt when saving a textbox alerting user that it will change in other places - giving them options 'ok' 'no make copy' or 'cancel' be useful 08:40:52 From a portfolio perspective, I think the usual case for reusable elements would be, create a note on the content-area and select it in the portfolio view 08:41:57 tobiasz: there i’d still like to be able to create re-usable item directly in the portfolio. a number of people complain about the process of having to go into content first and then needing to put it onto a portfolio page instead of starting on the portfolio page. 08:42:16 tobiasz: I think we are trying to get away from this workflow as it is not very user friendly 08:42:32 robertl_: hadn’t thought of that. sounds like the best idea so far for the re-usable ones to me 08:42:36 ok, I agree with that 08:42:58 #idea have a confirm prompt when saving a textbox alerting user that it will change in other places - giving them options 'ok' 'no make copy' or 'cancel' 08:43:46 what about just having three buttons then instead of a popup which would be an additional click? 08:43:46 so, any action on this topic? 08:44:30 i guess it’s back to discussing a bit more on the forum / tracker to come up with the plan to untangle things. 08:44:45 Yeah, let's work it out on the bug tracker, now that we've had some discussion about it here 08:44:58 sounds good 08:45:01 ok 08:45:04 yes. 08:45:09 should this be a task for everyone interested? 08:45:12 i think we agree that there should be two different blocktypes and that the re-usable one needs some more usability work to make it clear that text will be replaced elsewhere if not copied. 08:45:42 that sums it up nicely I recon 08:45:59 ok 08:46:07 #idea there should be two different text blocktypes and that the re-usable one needs some more usability work to make it clear that text will be replaced elsewhere if not copied. 08:46:44 #action everyone have a look at discussion forum and bug listing https://bugs.launchpad.net/mahara/+bug/1296390 if anything can be added to the discussion 08:47:14 can I start working on the new block type or is that also subject to discuss? 08:47:27 it’s https://bugs.launchpad.net/mahara/+bug/1152441 08:47:30 #link https://bugs.launchpad.net/mahara/+bug/1152441 08:47:43 tobiasz: which blocktype? the simple text one? 08:47:54 yep, the simple one 08:48:15 if we agreed, that we need two blocktypes, why nor 08:48:21 tobiasz: Sure, I'd say go ahead 08:48:35 my opinion for that in terms of functionality: Title, Description, Tags. And then a way of migrating existing single “notes” to that. 08:48:37 ok, great 08:48:43 do I need to add this to actions? 08:48:45 I don’t think we need comments on the simple text 08:48:56 yuliyabozhko: i don’t think so. 08:49:06 ok, thanks 08:49:10 agreed, no comments 08:49:12 I don't think it really needs tags for that matter 08:49:14 unless you want to make tobiasz to report back next time ;-) 08:49:22 it would be good to see something in action as that will help clarify what we want 08:49:24 very tempting :D 08:49:34 Yeah, good idea 08:49:42 fine with me ^^ 08:49:46 tags: mhh. probably not since it’s just a line of text or so 08:50:00 also agreed, no need for tags 08:50:16 so, it won't have any attached files, etc? 08:50:33 that's the point of being "simple" I guess :) 08:50:44 ok, sounds good to me. 08:51:03 my idea of simple was about not being connected to an artefact, but I'm fine without the files 08:51:27 :) ah, right 08:51:39 any opinions? 08:51:59 although from an implementation perspective... in order to hook it into elasticsearch it may well need to be an artefact on the backend... just not an artefact that is viewable and editable on its own 08:52:04 tobiasz: so pretty much go back to what the textbox used to be back in the day. 08:52:11 sort of like how commenst are technically artefacts 08:52:26 aarow: are they? 08:52:31 yeah :) 08:52:37 yep, they are 08:53:30 that's for when you use the elasticsearch to search the pages? 08:53:34 Hm, actually I'll take a look at it 08:54:11 No, comments were written before the Elasticsearch stuff. I'm not sure why they're artefacts exactly, except that it's kind of a convenient way to store them 08:54:25 I haven't worked with elastic search so far, but other block types also have titles and such. I'll have a look at that as well 08:54:27 #idea in order to hook it into elasticsearch it may well need to be an artefact on the backend... just not an artefact that is viewable and editable on its own 08:54:41 Okay, I'll check into that tomorrow 08:54:52 ok, great 08:54:57 will it also appear in the notes section? 08:55:01 I think you're right, it would be easier and simpler to just store the text in the block 08:55:11 artefacts are mainly meant for reuse, and this will not be reusable 08:55:13 no, it won't appear in the notes section 08:56:07 anything else on this? 08:56:12 I'm done 08:56:13 but would you want to share them in some sort of stream maybe, yuliyabozhko? 08:56:13 not from me 08:56:14 ok. i think we're ok on this 08:56:53 i think we keep it simple. 08:57:15 what's next on the agenda, yuliya? 08:57:15 and the watchlist event should be triggered anyways 08:57:20 but if it’s simple to write, people will use it for longer things that they may want to share and not re-use. 08:57:24 anything we would like to check about this topic next meeting? 08:57:32 to add to actions 08:57:41 if not, moving on :) 08:58:25 nope, I think we're good. We'll hammer out further details in the bug tracker 08:58:33 ok then 08:58:40 #topic Yuliya on reviewing patches from Totara 08:58:45 I will be quick :) 08:58:52 as some of you hopefully know, Totara team is currently doing lots of work in social features area 08:59:03 so, I put this item on meeting agenda earlier this week when I felt that our progress has stalled a bit due to lack of feedback on the patches in review, but it seems that we did quite a bit of work on reviewing and merging patches today 08:59:12 thanks a lot everyone who participated :D 08:59:29 I guess all I want to ask is to prioritise when possible reviewing/feedback of the new features from Totara team (Nathan Lewis, Valerii Kuznetsov, Moises Burgos, and myself) while we are quite early in Mahara release cycle 08:59:38 We still have a lot of work to do and it is quite hard to work with patches with so many dependencies 08:59:46 that's it from me :) thanks 09:00:48 do you have a list of what's most important for you - while reviewing? 09:01:12 good to know more new stuff is coming 09:01:27 ghada: no. it might be a good idea TO MAKE A LIST 09:01:48 :) 09:02:30 I am not sure on how to communicate importance of some patches other than ask someone to review them directly 09:02:36 often if there are patches with dependencies it is the ones that things depend on that we need in 09:02:39 it was good to see some of the bigger patches merged as it opens up the reviewing of smaller child patches which should go quicker 09:03:13 eg they shouldn't need 30+ revisions 09:03:37 yeah, definitely 09:03:37 yuliyabozhko: i think in terms of priority: whether it’s activity stream or artefact level sharing etc. then within that it’s to look at all due to the dependencies. 09:04:07 anitsirk: yep, pretty much. that would be great 09:04:08 the three big ones at the moment are activity stream, artefact sharing and chat 09:04:15 we also have chat in review already 09:04:32 Valerii is currently splitting it into smaller patches for easier review 09:04:37 if I had to pick a priority it would probably be activity stream, then artefact level sharing 09:04:50 but they are both important because they touch on so many areas of mahara 09:05:17 some of the other features that are coming like questions and ideas are more independent 09:05:43 activitystream is separated into a topic 09:05:52 so, it's easier to find it in review 09:05:54 besides the likeability, or is that already merged? 09:05:56 we really appreciate all the effort and help so far! 09:06:23 tobiasz: only initial activity stream patch has been merged 09:06:27 likes is in activitystream topic: 09:06:28 https://reviews.mahara.org/#/c/3374/ 09:06:35 all child patches are still there 09:06:50 ok, thanks 09:07:35 Will try to dedicate some time to reviewing, though it is a bit difficult at the moment. 09:07:40 cool. if you have any questions, don't hesitate contact any of us in Totara 09:08:24 ok, next topic then :) 09:08:42 #topic aarowlaptop on allowing anonymous-author portfolio pages 09:08:51 #link  https://bugs.launchpad.net/mahara/+bug/548021 09:09:22 to be honest, I haven't looked at this one 09:09:53 looks like a pretty old bug 09:10:09 it’s a wishlist item. :-) 09:10:10 connected to the Ljubljana ideas, though 09:10:17 ah yeah I merged that one before fully realising the problems with it 09:10:27 aarowlaptop: would you like to talk about it? 09:10:43 the danger of anonymous pages 09:10:56 well, I was just wondering if anyone had any ideas on what the use case for this is 09:10:57 my fault, should have marked it as in-discussion 09:11:06 I see that the Ljubljana folks want it as well 09:11:12 oh, came across similar problem in bagdes 09:12:06 hm, although I guess specifically what the Ljubljana group says is that *public* pages should not show the author 09:12:34 in this case you need a way of verifying the author which might not be easy 09:12:37 whereas what the current patch does, is allow you to hide the page name from everyone? 09:12:40 Currently, people can already choose what name to display. It does not have to be the fullname. everywhere else (blogs, social networks etc.) you always have your name displayed. 09:12:41 I mean the author name 09:13:11 the patch hides the author to anyone, who couldn't see the authors profile 09:13:18 what the point of hiding user name? 09:13:28 what is the worry of having anonymous authoers 09:13:57 It's an accountability thing 09:14:06 if I am anonymous I can make an official looking page saying give me your c/card info 09:14:11 yuliyabozhko: that’s what we are trying to find out 09:14:15 so that's one aspect, creating phishing pages 09:14:16 the "report objectionable material" link is still shown i public pages, isn't it? 09:14:25 yes 09:14:34 but not everyone will report a page. 09:14:50 wait, isn't it only displayed to logged in users? 09:14:55 right, and admins may not check that frequently 09:15:05 but i can also put some obscure name on that page as an auther. I can be "Barack Obama"... 09:15:08 or is the problem more around the fact that you can currently see the person’s name and profile pic even when they don’t have access to the full profile? 09:15:09 hm, there's that too, only logged in users can report a page objectionable 09:15:40 tobiasz: Did you implement this patch because you need it at your institution? 09:15:52 ghada: yes, you can already have a display name if your institution / site allows for that. so you can be anonymous. however, that then goes for the entire site 09:16:09 while you can choose which name to display as author, around a site your display name is your primary name 09:16:14 no, I just looked at the proposals from the Ljubljana group and had the idea 09:16:48 Oh, okay 09:16:56 ok. so we need more input from gregor on what he actually means 09:16:59 so for me, it's ok to revert the patch. We should ask Gregor why he needs the feature, though 09:17:04 Yeah 09:17:16 Okay, I'll ask Gregor about it 09:17:34 I think it may be worth keeping, just as an optional feature 09:17:53 is it configurable on the site / institution level? 09:17:55 There's a fix for the institution link from robertl, though. Can we exclude that into a separate patch? 09:17:59 sorry, haven’t had the chance to look at it yet. 09:18:09 would it be better to display the author as text rather than link for public users? 09:18:19 instead of hiding it altogether 09:18:33 it would need to be a link when the profile is publicly viewable 09:18:34 Well, we'll have to see what the use-case is to know whether that's better or not 09:18:36 anitsirk: no, my attempt was that if you can't follow the link to the profile page, then the link is obsolete 09:19:09 I suspect that, if you want your users to create pages with no "author" line, you probably don't want their name printed on the page 09:19:20 so, if you're logged in and can view the user's info, the name appears? 09:19:26 yep 09:19:50 i still don’t like it because then it looks like the institution wrote the page 09:19:54 or the mahara install 09:19:58 right, we definitely need more info on this one from Gregor 09:20:12 aarowlaptop: will you contact him? 09:20:16 sure 09:20:28 we are dealing with user generated content here and if we don’t have any indiciation of author it falls back to the wider site which would not be good 09:20:31 thanks 09:20:39 yuliyabozhko: can you please make an action ite 09:20:41 item 09:20:54 anitsirk: yes, i see your point. 09:21:02 #action aarowlaptop contact Gregor to get more information/use cases on anonymous pages 09:21:18 done 09:21:46 anything else on this? 09:22:02 I guess we can't discuss much until we get more info 09:22:41 ok, then, moving on 09:22:46 #topic Next meeting and chair 09:22:59 what about Thursday, 10th of July 2014 at 8 AM UTC (9 AM UK, 10 AM Europe, 8 PM NZ)? 09:23:21 ok with me. 09:23:32 works for me 09:23:34 fine with me 09:23:35 okay 09:23:42 where do feature freeze etc happen? 09:23:50 Last week of July I believe 09:23:50 when do feature freeze etc happen? 09:24:00 last week of July 09:24:09 So 10th July will be the last meeting before the feature freeze 09:24:16 cool then having a meeting then should be good 09:24:16 yes. sounds good. 09:24:17 then technically yes 09:24:24 cool 09:24:26 fine for me 09:24:35 #agreed 34th Mahara dev meeting on Thursday, 10th of July 2014 at 8 AM UTC (9 AM UK, 10 AM Europe, 8 PM NZ) 09:24:45 and 6 pm Sydney 09:24:45 #link http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140710T08 09:25:10 who would like to chair? 09:26:20 I can volunteer someone :) 09:27:26 seems like a very scary question... 09:27:42 I can if noone wants 09:27:48 who has not yet chaireda meeting? 09:28:31 I have not yet chaired one - I'll do it 09:28:41 great. thanks! 09:28:42 thank you, robertl_ 09:28:48 thanks robertl_ 09:28:55 #info robertl_ to chair the 34th Mahara dev meeting 09:29:01 #topic Any other business 09:29:06 I have two 09:29:08 anything else? 09:29:21 cool, go on :) 09:29:56 #info please fill in the questionnaire for Moodle Mahara integration and pass it on to anybody you know who has an interest: https://docs.google.com/forms/d/1vyECf8s8lyEX6YJuf9SGe7sUN5flaROcfBF7mPxY9fc/viewform 09:30:10 it is for the MNet “replacement” 09:30:38 and use cases of what works well right now as well as what functionality you are missing would be great to have so that the solution that we are going to come up with keeps all those things in mind 09:30:47 is it aimed at developers or admins? 09:30:54 both 09:30:57 have you passed this onto the Sydney office? 09:31:08 ghada: not yet 09:32:05 the important thing is to get use cases and not i prefer oauth because… the technical side will be decided once we have all the use cases and know what the integration needs to cater to. 09:32:40 if you have a strong preference for a specific technology do say so as it might reveal any potential problems, but we don’t want the tech side to get into the way of the user side. dream a little… 09:32:49 number 2 09:33:34 The University of Canberra is funding major work for Mahara: archiving of pages and making the Mahara assignment submission plugin work over LTI. base specs are at https://wiki.mahara.org/index.php/Developer_Area/Specifications_in_Development/Moodle_LTI_integration 09:33:43 #info The University of Canberra is funding major work for Mahara: archiving of pages and making the Mahara assignment submission plugin work over LTI. base specs are at https://wiki.mahara.org/index.php/Developer_Area/Specifications_in_Development/Moodle_LTI_integration 09:34:11 that's great news 09:34:18 that work will be awesome because pages / collections that were submitted (groups or in Moodle) will be archived on the server 09:34:37 and it makes the plugin less moodle specific. 09:34:52 so big thanks to U of Canberra and esp. Shane Nuessler 09:35:20 and like usual, as much as possible will be put into core Mahara. 09:35:27 that’s all from me 09:35:30 sounds great 09:35:31 yep, big thanks from us as well 09:35:33 thanks, anitsirk 09:35:43 anyone else? 09:36:05 I have nothing :) 09:36:25 that's it from me... 09:37:04 ok then. thanks everyone for joining today :) 09:37:11 thanks for chairing, yuliyabozhko 09:37:26 thanks yuliyabozhko. Great job. 09:37:29 thanks, yuliyabozhko 09:37:36 :) 09:37:39 #endmeeting