07:34:17 #startmeeting 07:34:17 Meeting started Wed Nov 10 07:34:17 2010 UTC. The chair is dobedobedoh. Information about MeetBot at http://wiki.debian.org/MeetBot. 07:34:17 Useful Commands: #action #agreed #help #info #idea #link #topic. 07:34:20 #chair lamiette 07:34:20 Current chairs: dobedobedoh lamiette 07:34:40 awesome :) 07:34:57 are we waiting on others? 07:34:59 do we know who is in the room right now as some have their computers on at all times but may not be sitting in front of them? 07:35:04 i'm here! stop panicing! 07:35:13 hehe 07:35:14 hi Mjollnir` 07:35:18 Morning 07:35:27 <-- is here in the UK 07:35:31 hehe, and you are even shown as away, Mjollnir ;-) 07:35:39 still? 07:35:44 The agenda items we have submitted are: 07:35:46 yep 07:35:46 1) What should go into 1.4 (e.g. fully-separate institutions?) 07:35:47 2) Release policy 07:35:47 3) Commit access policy 07:35:47 4) Testing and code review 07:35:49 5) Sanitisation of language packs 07:35:52 6) Forum code of conduct 07:35:54 7) Next Meeting 07:35:57 8) Any Other Business 07:36:05 show of hands for the logs ? 07:36:29 i'd like to propose that we close the meeting in an hour and defer anything we haven't talked about to the next meeting 07:36:36 seconded 07:36:38 good idea 07:36:56 agree 07:36:57 except for (7) of course :) 07:36:57 fast game's a good game 07:36:58 yup 07:37:20 #topic What should go into 1.4? 07:37:52 Walled Garden ;) 07:37:59 so the main thing that Richard and I are working on at the moment is usability enhancements 07:38:49 another thing that I want to get to is to review the patches from luns related to separating institutions 07:39:10 Both of those sound good to me :) - especially the walled gardens 07:39:46 i personallly dislike the term walled garden because it makes me think of toxic DRM-filled ecosystems :) 07:40:06 Do we have any target date for 1.4? 07:40:07 but i have nothing against the feature of course :) 07:40:13 is http://wiki.mahara.org/index.php?title=Developer_Area/Specifications_in_Development/Walled_Gardens&highlight=walled+garden still the best place to check upon what you mean by "walled garden"? 07:40:16 heh I'm sure that we can rename it 07:40:16 http://wiki.mahara.org/Roadmap/1.4/1.4_Wishlist 07:40:20 is there a public spec for the usability stuff ? 07:40:27 excuse my out-of-touch-ness 07:40:27 fmarier: better than "creepy treehouse effect" ;-) 07:40:28 One thing we should also point out it that we don't really officially get to decide what goes in at all 07:40:29 Mjollnir`: not sure 07:40:43 richardm: que? 07:40:52 It's supposed to be decided by the 'steering group' 07:40:56 Mjollnir`: http://wiki.mahara.org/Roadmap/Usability - from the wiki 07:41:04 Don reminded fmarier & me of that recently 07:41:23 Who is the steering group composed of? 07:41:32 does the steering group actually meet regularly though? 07:41:42 Nope they never meet 07:41:42 is that different ffrom the governance group? 07:41:51 the governance group is richard wyles, nolen smith, don christie and mike o'connor 07:41:56 er sorry i mean the governance group 07:42:06 i used to be on the governance group, i think my membership silently lapsed 07:42:19 but more importantly, what are people looking at pushing into 1.4? 07:42:39 http://wiki.mahara.org/Contributors 07:42:40 we were thinking of a release in the first half of next year 07:42:51 (obviously really vague) 07:43:01 richardm: that being so, i think the governance group are very reliant on the developers giving them good advice to make decisions 07:43:08 and part of it depends on what goes into the release 07:43:10 Well, as per the commit access policy, we're can only submit new features when they're signed off by fmarier, richardm or Mjollnir` 07:43:12 Mjollnir: the last i had seen it was those plus nigel 07:43:17 aguri: yes, as dm pointed out they never meet 07:43:39 But they can veto stuff i guess 07:43:46 yep 07:43:57 practically speaking that means richard wyles can veto stuff 07:44:03 no one else really cares 07:44:16 well - he can only veto if the others in the gov group agree 07:44:17 i wouldn't say so, richardm 07:44:19 dobedobedoh: that's one of the things i was hoping to talk about in "testing and code review" 07:44:42 so the commit access policy would need to include this extra level where things might not make it through 07:44:53 Regarding walled garden, we have updated it with upstream version last time in June. Our idea was, when you guys have resources to review it, we can allocate the time to have it up to date with master again and then we can proceed with revision. 07:45:17 rkabalin excellent 07:45:28 it will certainly help 07:45:59 so was there anything else that people were planning/hoping to get into 1.4? 07:46:11 We have nothing else at present that I'm aware of 07:47:09 I'm tempted to say Gregor Anzelj's skins stuff too 07:47:10 richardm: i think you were also hoping to get to the skins patch? 07:47:14 :) 07:47:23 adi and i were hoping to use some of our innovation budget for leap2a import for normal users 07:47:25 Yeah I don't know if I'll get time 07:47:26 we certainly can't do that this year, but maybe if se 07:47:37 richardm: wasn't that close to getting in anyway? 07:47:41 fmarier: we have PDF export proposed to go in at some point http://wiki.mahara.org/Developer_Area/Specifications_in_Development/PDF_Export 07:47:44 we start planning we could get it in next year, depending on what you mean by "early next year" 07:47:51 Oh btw, Feb is more likely when 1.4 will come out 07:48:01 then no 07:48:19 That's when we're expected to have to release the usability stuff 07:48:42 in time for the new school year in NZ 07:49:06 Mjollnir`: how much more time would you need to get your stuff in? 07:49:25 well we basically have to pitch for budget and time off projects to do it 07:49:37 and we're both very busy with a big project until probably .. end of feb at least :( 07:49:47 uless we can find a way to do a day a week on it or something.. i'm not sure 07:50:06 adi_b: ? are you here ? 07:50:16 yes 07:50:26 aguri: is the PDF export stuff started or is it in the planning stages at this point? 07:50:34 do we think this is at all possible? 07:50:35 I�don't think we'll be able to do it before march 07:50:39 ok 07:50:51 fmarier: planning now although there is budget. have been discussing with richardm 07:50:55 So usability is definitely in for 1.4; and WG is a hopeful. Innovation is unlikey given the Feb timescale 07:50:56 we should discuss this internally 07:51:32 bah - I meant leap2a import 07:51:35 fmarier: we will be looking for feedback/refinement on that spec from the wider community - baring in mind we have limited budget for great ideas 07:51:46 innovation is where budget comes from ) 07:52:39 * aguri likes the sound of this "innovation" feature :p 07:52:43 what about Gregro's skins patch? Likely for 1.4? 07:53:22 I'd like to do it, but I'm not sure. it's a monolithic patch that doesn't merge cleanly 07:53:30 what's the skins patch ? 07:53:47 lets you choose colours & fonts for views 07:53:49 very cool 07:53:55 nice 07:54:17 sounds interesting 07:54:35 basically it's like view themes but the way wwe should have done it 07:54:43 why didn't we d... oh nevermind 07:55:25 So is the general consensus that pdf won't be ready, nor will leap2a import; institution separation and usability will be and skins are on the fence? 07:55:26 yeah i'll try to get a working version of it up somewhere where you guys can check it out 07:55:44 that'd be great 07:56:01 dobedobedoh: there's a good chance PDF will be ready 07:56:03 richardm: was the Usability link I pasted earlier - on the Roadmap - an adequate outline for the changes .nz is working on atm? 07:56:29 lamiette: no it's the first 3 items on that 1.4 wishlist page 07:56:33 is pdf export a proper export plugin ? 07:56:35 more if we get time 07:57:13 Mjollnir`: that idea is being circled. 07:57:16 http://wiki.mahara.org/Roadmap/1.4/1.4_Wishlist <- those 07:57:21 er 07:57:29 not making it an export plugin seems .. kind of wrong 07:57:41 even if you're only going to initially allow view exports 07:57:46 it should still be a plugin imo 07:59:35 So can we #agree some points that we'd like to see in 1.4 then? 07:59:39 * dobedobedoh is conscious of the time 07:59:46 Hi 07:59:59 hi iarenaza :) 08:00:04 Mjollnir`: i know lamiette was discussing doing it that way - can't quite remember where we left it on last discussion. but your view noted. 08:00:23 dobedobedoh: i think: usability, institution separation are in; skins, pdf export hopefully 08:00:41 adi and i are talking about leap2a tomorrow morning and will report back on how possible it is 08:00:55 Mjollnir`: cool 08:01:03 Great :) 08:01:04 #agree Usability enhancements, and Institution Separation for 1.4 subject to governance group agreement. Gregor's skins patch and PDF export my go in dependant on time 08:01:12 #topic Release Policy 08:01:35 so basically i put that topic in just as a reminder that now is the time to get your new features in :) 08:02:01 heh :) 08:02:08 but also, to let people know that if you've fixed an important bug on master, please propose it for 1.3 as well 08:02:22 we do want to fix important bugs on the stable branch as well 08:02:31 are we still supporting 1.2 ? 08:02:45 Mjollnir`: yes, but only for security stuff 08:02:49 ok 08:02:55 i will stop putting leap2a patches there then :) 08:03:13 Do we have any documentation on the release policy? 08:03:14 as in, feel free to put a major bugfix on there too, but we make no guarantee other than security fixes 08:03:40 dobedobedoh: http://wiki.mahara.org/Developer_Area/Release_Policy 08:03:45 * dobedobedoh finds it :) 08:03:53 (scroll down to Point Release) 08:04:11 I don't know if this is related to release policy but, what's the policy on (non-english) languages? 08:04:25 iarenaza: what do you mean? 08:04:50 I'm not really sure :) 08:05:24 heh 08:05:52 Right know non-english languages look like something "apart"m that have an indepedent life 08:06:02 There's no tie between language pack versions and mahara versions at present is there? 08:06:19 dobedobedoh: there is, we have different branches in the git repos under mahara-lang 08:06:25 ah right 08:06:51 iarenaza: I'd like to see if we can get AMOS to do Mahara lang as well 08:06:57 dobedobedoh: you can see that a bit also at http://wiki.mahara.org/Language_Packs 08:07:03 just need to wait for David to get it all sorted for 2.0 08:07:12 how embedded in to moodle coe is amos? is it being managed in its own project somewhere ? 08:07:21 antisirk: Cheers - I wasn't aware of the version in there 08:07:23 its's a moodle plugin 08:07:32 but we could run a moodle site that created mahara langs 08:07:44 have you seen amos? 08:07:45 what sort of plugin ? 08:07:53 dm: i haven't seen it but i read the technical spec 08:07:59 since we're talking about translations, i think it might be time to move the #topic to (5) 08:08:04 can't remember - might be in local 08:08:11 #topic Sanitisation of language packs 08:08:19 I did have a look at it/install it a while back 08:08:19 dobedobedoh: thanks :) 08:08:34 but we'd run our own Amos install which would be a mahara site 08:08:36 sorry 08:08:37 moodle site 08:08:41 pointing at mahara git repo 08:08:54 yeah it'd be very cool to have some site where people can translate strings 08:09:24 i think the old translation tool of davids is quite hard to install currently 08:09:30 Mjollnir`: I think David M has a repo on github with AMOS code 08:09:36 yeah 08:09:42 iarenaza: yes 08:10:04 It might be easier for us to use when David does the work to support contrib modules 08:10:14 at the moment it only supports moodle core 08:10:33 also, i think it's worth pointing out this tool that richardm wrote: http://langpacks.dev.mahara.org/ 08:10:35 richardm: we keep up to date patches of the old tool in a git repo, so we can use it internally (we maintain the Basque lang pack) 08:10:59 it cleans up language packs and makes sure that there is nothing else but strings in them (for security reasons) 08:11:07 fmarier: You raised language pack sanitisation - what else did you have in mind? 08:11:08 cool 08:11:40 iarenaza: ah right, that's awesome, but most of the translators find it too hard to install i think 08:11:45 i think it checks for general brokenness as well (like invalid utf-8 characters and syntax errors) 08:11:55 great! 08:12:04 dobedobedoh: i just wanted to point out richard's tool 08:12:12 we link to these tarballs from the wiki now 08:12:16 richardm: that's true (and doesn't help with help files translations) 08:12:37 fmarier: yeah, there's nothing to stop people installing the originals though 08:13:01 richardm: true, but we're no longer linking to the raw unsanitised ones 08:13:10 so they're harder to find 08:13:23 we only have about 15mins left btw 08:13:30 is there anything more to discuss on language packs? 08:13:32 surely we could go for 1.5h 08:13:38 i will be on the train until 10 :) 08:13:52 Mjollnir`: you've got interwebs on the train? 08:13:56 richardm: maybe it's time for a language pack "release policy" (aka, telling translators not to publicise non-blessed sites) 08:14:27 iarenaza: can you draft it? 08:14:47 Ok :) 08:14:49 fmarier: tethered, yes 08:14:51 #action iarenaza to draft language pack release policy 08:14:56 :) 08:15:31 ok, so do we want to extend the meeting to 1.5 hours to cover the remain agenda items or stick to 1 hour? 08:15:44 +1 for extend 08:15:47 +1 08:15:51 +1 08:15:52 NZ people can call on that one 08:15:54 sure +1 08:15:55 +1 08:15:58 +1 08:16:04 AOL! 08:16:06 +1 08:16:11 +1 08:16:26 alright, let's move to (4) ? 08:16:29 #agreed 1.5 hour meeting 08:16:36 #topic Commit access policy 08:16:49 ah we skipped (3) as well :) 08:16:54 fair enough 08:17:00 heh - I assumed that you'd renumbered ;) 08:17:15 so, the existing "commit policy" is not really a policy and is a bit random 08:17:26 what do people think we should have to make sure it's fair? 08:17:57 do you mean "who to give commit access" to? 08:18:10 or do you mean what type of commits are allowed? 08:18:23 I was going to ask about that - for contributing in terms of bug fixes, medium sized modifications and larger pieces of contrib/features etc 08:18:37 I assume the bug tracker, forum and wiki of course 08:18:52 dm: i meant write access to the main repo 08:19:03 And how can we track those submissions - the status etc. Ensure that they're not forgotten 08:19:15 dm: the other one i suppose is kinda covered in the release policy? 08:19:19 dobedobedoh: yeah 08:20:06 dobedobedoh: i'm experimenting at the moment with a code review tool called gerrit. it seems better than the merge request stuff on gitorious 08:20:14 The way Moodle "used" to work was - a new dev comes along - suggests a bunch of patches in the tracker....the existing devs get sick of cherry-picking small stuff - give dev access to commit 08:20:22 are we generally happy with gitorious ? 08:20:23 that works quite well with smaller numbers of devs 08:20:25 fmarier: Great. The merge request stuff on gitorious is a pain to use 08:20:28 Apart from the lack of CIA 08:20:48 dm: i htink that model worked pretty well, no ? 08:20:50 dm: I quite like that way myself 08:20:52 maybe a topic for next meeting could be "contributing" - for general stuff, contrib etc 08:20:59 yeah - worked well for a long time 08:21:03 yeah i don't like the gitorious merge requests either 08:21:05 has it changed then? 08:21:11 fmarier: gerrit is cool stuff BTW, I saw a presentation on UKUUG 08:21:11 moodle? 08:21:12 mahara is still way way small enough for this to work, imo 08:21:13 it's changing 08:21:15 lamiette: can you create a new wiki page for the next meeting and add it there? 08:21:17 the problem with moodle is just that of scale I think 08:21:28 we don't have that problem yet 08:21:30 I wonder if having partial commit access is a good thing (i.e., being able to commit to auth plugins only, or just a single plugin, etc.) 08:21:46 Would it be worth it? 08:21:51 it doesnt' seem like we have a particularly large ocntrigb at the moment: http://gitorious.org/mahara-contrib 08:21:51 That's probably only possible using the contrib repo 08:21:56 (sorry all, slow irc problems) 08:22:08 probably not - if we don't want to give full access -we should be cherry-picking 08:22:16 iarenaza: we have separate access for contrib and core, but nothing more granular 08:22:34 I think splitting stuff out is probably overkill at this point 08:22:38 definately 08:22:42 agreed 08:22:43 yeah is it easy to make it granular on gitorious? 08:22:44 Mjollnir`: agreed 08:22:45 if we do'nt trust someone enough to have full acess, cherry pick or merge like dan says 08:22:54 ARGH TUNNEL 08:23:24 I don't think git gives that sort of granularity on a per-directory level. It's not svn ;) 08:23:37 yeah thats what i thought 08:23:43 you can do it using some hook architecture I think 08:23:43 yeah i would tend to agree with dobedobedoh, but i might be wrong 08:23:43 dobedobedoh: yes, you can do it (using the hooks) 08:24:00 gitorious doesn't support hooks 08:24:00 moodle/petr was looking at it 08:24:03 anyways, sounds like overkill right now 08:24:13 you can do it with hooks 08:24:22 oh sorry, lag 08:24:31 e.g., gitosis can do it out of the box 08:25:20 do we have an actual case where this would have been useful or are we just talking hypothetically? 08:25:50 hypothetically i tink 08:25:54 in which case we sould move ov 08:25:55 on 08:25:57 yeah we haven't had problems with badly broken stuff yet, hypothetical 08:26:12 So the general consensus is to accept patches and cherry-pick commits, and give access as appropriate? 08:26:27 #yes 08:26:27 how do we define "as appropriate" ? 08:26:35 voting ? 08:26:40 #yes 08:26:41 Who gets to vote? 08:26:41 yep, i'm happy to try out gerrit though if fmarier sets it up! 08:26:43 #yes 08:26:54 dobedobedoh: existing people with commit acces s? 08:27:01 should we propose giving commit access at developer meetings for example? 08:27:11 good idea 08:27:14 i propose the lead developer decides 08:27:14 (assuming we do them regularly) 08:27:15 Yeah good idea 08:27:17 if we have them regularly enough 08:27:21 i.e. person with the biggest headache when it goes wrong 08:28:09 ubuntu has a nice system where new members create a wiki page pointing to their commits / contributions then that is taken to the community board meetings 08:28:12 and voted on 08:28:24 If we're moving to granting access based on these meetings, will that affect Catalyst's internal work? 08:28:25 that sounds good to me - having one person decide seems like a bottleneck 08:28:39 I wouldn't think so 08:28:50 cause of the thousands applying 08:28:54 internal work happens on seperate git branches 08:29:05 review happens before upstream commit 08:29:07 yeah apart from small bug fixes 08:29:08 dobedobedoh: i think catalyst people are competent enough to pass the test :) 08:29:23 heh cool :) Just thought I'd best raise it 08:29:35 aguri: i don't think there's anything wrong with being optimistic 08:29:39 and avoiding double standards is good 08:30:26 so we should call a meeting from now on if we need to give commit access to someone new? 08:30:43 richardm: i think we were assuming regular meetings 08:30:47 like monthly 08:30:50 i wouldn't do that but schedule it during the regular meeting 08:31:00 I was thinking monthy meetings 08:31:04 second fmarier 08:31:22 right, just mentioning because i (possibly rahsly) gave commit access to eugene & alan from catalyst recetnly 08:31:30 better change my policy ") 08:31:37 hehe 08:31:44 Do we need to propose and find a seconder? That's probably a bit OTT for the moment 08:31:47 that's mcnatty eh 08:31:51 that's awesome 08:31:55 richardm: alan! yeah i retract my earlier proposal ;) 08:32:00 Oops, looks like pidgin crashed on me... 08:32:07 I don't think there's a problem - as long as the person that "vouches" for the person that gets access monitors their commits for a bit to make sure 08:32:18 iarenaza: The minutes will be online at the end of the meeting 08:32:35 thx 08:33:20 would anybody have any objection to moving to commit access and developer status expiring after a year, but renewable indefinitely by the developer? 08:33:22 i think monitoring is a good idea 08:33:33 dm: shouldn't that happen anyway also for those who are being voted on, e.g. for a bit of time before they are up for voting to get commit access? 08:33:36 If we can do that, that'd be a good idea 08:33:39 basically this is to reduce inactive developers who don't care 08:33:56 as long as people want to hang on to their credentials, they can 08:33:58 sounds reasonable to me 08:33:58 fmarier: i think that's a good idea 08:34:04 anitsirk: yes - but after giving access we should still monitor for a little bit 08:34:11 dm: Definately 08:34:25 dm: sure. 08:34:28 otherwise you can end up with dozens of inactive accounts (and the potential risk of being compromised) 08:34:35 fmarier: +1 08:34:40 ok, so to sum things up: 08:34:43 moodle suffers with this problem 08:34:52 will hopefully be cleaned up with 2.0 changes 08:34:53 1) new developer proposed at developer meetings 08:34:59 (changes after 2.0 release I mean) 08:35:08 2) people get to vote based on contributions 08:35:17 #agrere fmarier> 1) new developer proposed at developer meetings 08:35:19 3) the sponsor monitors commit for a bit afterwards 08:35:22 #agree fmarier> 1) new developer proposed at developer meetings 08:35:40 heh - does everyone agree before I #agree those ;) 08:35:46 4) developer status expires after a year but is renewable indefinitely 08:35:57 agree 08:36:03 yep 08:36:14 I know this is a bit controversial, but will there be a policy to remove commit access before the account expires? 08:36:18 agree 08:36:29 and 5) ultimate decision is with the lead developer ? 08:36:47 iarenaza: do you think we need one? 08:36:54 I hope not so 08:37:08 i think we just handle that on a case by case basis if it comes up 08:37:13 ok 08:37:41 well, wouldn't you need a policy and if it is "handled case by case" if an account is for indefinitely after the first year of trial period? 08:37:56 "people get to vote based on contributions" does this == people already with commit 08:37:59 anitsirk: actually i meant you can renew every year 08:38:10 aguri: Yeah - that's what was suggestee 08:38:14 but you can always renew 08:38:24 ah. that makes more sense. thanks fmarier 08:38:37 aguri: i'm not sure i understand your question 08:38:54 you mean "who are the voters" ? 08:39:38 fmarier: yeah, perhaps i misunderstood your intent 08:39:38 let's get all our mates to stack the irc meetings! 08:39:39 who decides on whether the lead developer's developer status is renewed or not if the lead developer always has the last word? (just hypothetical) 08:39:57 governance group 08:40:17 anitsirk: any developer can renew their status 08:40:21 and above them, president bush 08:40:34 we're talking self-renewal 08:40:49 this is just so that inactive people will let theirs expire 08:41:22 And are we talking about only those present at a meeting get to vote - we're missing a few today after all 08:41:54 i would say only those at the meeting because otherwise you may be chasing people 08:41:58 dobedobedoh: i think that makes sense 08:42:08 Okay. I've got 6 points for agreement. Any more to add? 08:42:17 if somebody objects, they can raise an agenda point for the next meeting 08:42:28 the people that will be running for it will be on the agenda so anybody can voice their objections prior to the meeting to another developer 08:42:29 anitsirk: good idea 08:42:44 #agree 1) new developer proposed at developer meetings 08:42:44 #agree 2) people get to vote based on contributions 08:42:44 #agree 3) the sponsor monitors commit for a bit afterwards 08:42:44 #agree 4) developer status expires after a year but is renewable indefinitely 08:42:48 #agree 5) ultimate decision is with the lead developer 08:42:50 #agree 6) those present at a developer meeting with commit access are entitled to vote. 08:42:59 Anything more to discuss on commit access policy? 08:43:01