14:00:50 #startmeeting Development IRC meeting 29 January 2020 14:00:50 Meeting started Wed Jan 29 14:00:50 2020 UTC. The chair is ashimema. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:50 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:50 The meeting name has been set to 'development_irc_meeting_29_january_2020' 14:00:57 #link https://wiki.koha-community.org/wiki/Development_IRC_meeting_29_January_2020 Agenda 14:01:03 #topic Introductions 14:01:12 #info please use "#info" in front of your introduction to have it show up in the automatic minutes 14:01:13 #info Owen Leonard, Athens County Public Libraries, Ohio, USA 14:01:22 #info Marcel de Rooy Rijksmuseum 14:01:26 #info Martin Renvoize, PTFS Europe 14:02:09 #info Thomas Dukleth, Agogme, New York City 14:02:26 #info Jonathan Druart 14:02:35 qa_team? 14:02:35 i guess qa_team is cait Joubu marcelr kohaputti josef_moravec tcohen kidclamp khall 14:02:39 rmaints? 14:02:39 i guess rmaints is talljoy, lucas, hayley 14:02:53 #info Tomas Cohen Arazi, Theke Solutions 14:02:54 #info Nick Clemens, ByWater Solutions 14:02:56 #info Joonas Kylmälä 14:03:38 oh 14:03:39 sorry 14:03:44 #info Katrin Fischer, BSZ, Germany 14:04:49 Moving along.. 14:04:59 #topic Announcements 14:05:28 We need to reschedule the GBSD day as I ran out of time to organise it :( 14:06:06 don't beat yourself up, let's set a new date 14:06:08 any volunteers to throw a wiki page together and send out a mail to organise one? 14:06:17 marseille is coming up end of march, some time before that would be nice 14:06:57 how much warning do people actually need.. 1 week, 2 weeks enough? 14:07:17 thinking next thurs/fri or the following week if we want to give more notice 14:07:18 2 weeks might be enough 14:07:33 2 weeks to maximise amount of participants 14:07:58 clear your schedule at work :) 14:08:06 good morning all 14:08:27 how about 13/14th Feb then? 14:08:28 just to say that I will be less on Koha for 3 month 14:08:45 good luck to you, long live the community 14:08:59 * fridolin is flying next week to Madagascar 14:08:59 14th sounds nice 14:09:12 see you on WattsApp 14:09:25 Send lots of photos fridolin! 14:09:31 +1 14:09:39 Enjoy fridolin :) 14:09:54 13/14 ok for me as well 14:10:04 I will ;) and he will learn Perl programming with math and french ;) 14:10:14 fridolin: save travels and all the best 14:10:39 ok.. lets organise GBSD for the 14th 14:10:56 #info GBSD rescheduled for the 14th February 14:11:31 #info Fridolin will be taking a break from Koha for a few months. He wishes us all the best and will be back :) 14:11:52 #topic Update from the RM 14:12:54 #info The master branch is moving along nicely at the moment with lots having been pushed over the past couple of weeks. Thanks go out the QA team who are diligently working through bugs. 14:13:37 #info I am paying close attention to some of the refactoring bugs that are currently making their way through SO/QA and I look forward to pushing them soon. 14:13:43 #topic Updates from the RMaints 14:13:50 rmaints? 14:13:51 it has been said that rmaints is talljoy, lucas, hayley 14:13:54 do we have any here today? 14:15:30 i think early for most of them :-) 14:15:44 fair enough.. 14:16:43 #info 19.11.02, 19.05.07 and 18.11.13 were all released since the last meeting 14:17:29 #topic Updates from the QA team 14:17:30 cait 14:17:56 not much more to say than ashimema did already 14:18:16 #info Queues are super full - please all balance your patch writing with sign-offs and QA a bit more! 14:18:34 we are almost touching 100 in Needs QA atm 14:18:44 and the hackfest is coming closer... 14:19:07 cait, on the good side most of those 100 are features and not bugs 14:19:22 indeed 14:19:26 [or write bugfixes] 14:19:34 #info Stilll over 100 major and critical - we need people working on those, retesting, confirming, fixing etc. 14:19:47 this number is not saying that much 14:19:54 includes failed qa etc 14:19:55 though there are 5 majors in the queue.. I'm sure we should be able to knock them off 14:20:09 yep, but maybe failed qa needs work too? :) 14:20:15 not only adressing the QA team here, i should say 14:20:22 in that list they make me ignore the number 14:20:28 testing/confirming can be done by anyone especially 14:20:43 indeed 14:20:57 could we recruit more qa? 14:21:03 kohaputti: always keen to 14:21:21 i think adding someone would not require much... finding the volunteers is the hard bit :) 14:21:22 we are more lacking testers than QA I'd say 14:21:29 kohaputti: thats not always the answer 14:21:40 we need both i'd say 14:21:42 you need good people 14:22:00 i am just highlighting a development here - the numbers are much higher which usually indicates longer waiting times too 14:22:54 we had QA around 30 pretty constantly a while ago - but in general bug activity is quite high right now (which is good :) ) 14:23:10 anyway, I think i shoudl stop here :) 14:23:17 30 is pretty low btw 14:23:30 yeah, that was a good number, harder to get lower 14:24:12 It would be nice to add one or two more to the team for next cycle.. so keep a look out for people who you think may be capable and willing.. 14:24:45 qa team tends to be 'by invite', though if someone wants to volunteer out of the blue it all goes to a vote anyways so we can assess 14:25:17 it's not formally by invite... it just happeens people seem to need a bit of a push 14:25:19 we have a few great people doing signoff lots at the moment.. David Nind, and Andrew Fuerste-Henry have been storming ahead on that front.. 14:25:27 indeed 14:25:32 yeah davidnind++ again :) 14:25:39 andrew too, but not here i think 14:26:21 but existing members of the team shouldn't be backwards in coming forwards if you feel there's someone out there who would be a good addition 14:26:29 gamification.. remember the leader boards https://dashboard.koha-community.org/ 14:26:33 if you remove active signoffers, you have a problem at the other queue 14:26:41 it's true 14:26:48 very true 14:26:58 but qa can still signoff 14:26:58 * oleonard agrees that signoffs have been more needed than QA lately 14:27:04 so we can balance that 14:27:42 ok.. moving on 14:27:45 #topic General development discussion 14:27:59 We didn't get through all the votes last meeting 14:28:14 it was a lot at once... and acq 14:28:56 #topic RFC /subscriptions endpoint 14:29:11 #link https://wiki.koha-community.org/wiki/Subscriptions_endpoint_RFC /subscriptions 14:29:29 noting that it wasnt on the agenda? 14:30:02 #info There are stll allot of blanks in the mappings table, so rather than vote this week I suggest we all try to find time to take a look at it before the next meeting and help fill in those fields. 14:30:45 I cloned them accross from last meetings agenda just as the meeting started marcelr 14:31:09 unfinished business from the previous meeting 14:31:11 #topic RFC /suggestions endpoint 14:32:31 er.. 14:32:42 whats the difference between suggestion_date and date_created? 14:35:09 all very quiet 14:35:23 suggestion_date is rather vague 14:35:32 especially if it gets updated or so 14:35:47 date contains timestamp 14:36:07 it is the last time the suggestion row was updated 14:36:23 3041 `date` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP, -- date and time the suggestion was updated 14:36:33 so date_created is a really bad name 14:36:34 3028 `suggesteddate` date NOT NULL, -- date the suggestion was submitted 14:36:45 date_updated would be better 14:36:53 so it's not 'date_created' at all 14:36:54 date => updated_on 14:37:01 agreed 14:37:41 date_created as opposed to creation_date is inconsistent with other dates as something_date . We should either have date_something or something_date if it is easy enough to be consistent. 14:38:15 Joubu, updated_on is used elsewhere? 14:38:34 just checked 14:38:45 it is used on other endpoints, so let's use updated_on here also 14:38:55 created_on and updated_on are used 14:39:00 it was not a suggestion, just saying what it does 14:39:04 we discussed the date vs date last meeting.. I think we came to the conclusion we should try to be consistently *_date 14:39:15 in the rest api we use *_date 14:39:27 sorry had to step out for a sec 14:39:28 Yes. 14:39:36 updated_date is not so nice btw 14:40:08 ashimema: not against people checking - but I tried my best to fill blanks 14:40:25 we have the patrons endpoint using updated_on 14:40:25 update_date may be nicer for that case. 14:40:28 it should be 'timestamp' I think 14:40:37 Joubu, timestamp of what 14:40:42 Joubu, not clear for me 14:40:43 for suggestions (sorry, slow reading back) 14:40:52 we have `updated_by` and `updated_on` in a few places elsewhere in the API.. so that seems sane enough to me 14:40:53 item already has "timestamp" 14:41:26 but it's not hte same is it? 14:41:30 date created and updated? 14:42:14 cait, it is not the same 14:42:16 ack.. we do indeed also have 'timestamp' in a bunch of places 14:42:31 883 `timestamp` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP, -- date and time this item was last altered 14:42:35 it's exactly the same 14:42:40 The fact that it has been previously done in some way does not mean that we should be stuck with what we did previously. We may want to revisit previous usage for consistency on a reasonable principle. 14:42:49 I don't like 'timestamp' on it's own as it's not clear whether it's an initial create or an update that's being recorded 14:43:13 if it#s both 14:43:21 timestamp seems not so bad 14:43:21 does _date also mean datetime ? 14:43:30 we have places where update/create are 2 things 14:43:32 or do we differentiate that? 14:44:35 good question 14:44:41 i think we have not been cehcking all the others so far 14:44:53 * ashimema thinks we should really always store timestamp and then reduce to date only if/when we want to.. 14:45:19 we really need to add some guidlines for these rather than voting on them per endpoint 14:45:58 there was some discussion ont hat last time 14:46:02 date_ vs. _date 14:46:12 or trust one dedicated and consitent person to do that for us ;) 14:46:17 consistent 14:46:20 and also using _id - when we actually store an id 14:46:21 and we sebtled on *_date I believe.. but didn't record it 14:46:34 I think we should have the whole thing/view and vote in one go 14:47:10 i think the only place where we need a decision is date date_created creaton_date updated_on 14:47:27 then we coudl say the last column counts 14:47:27 Even if we have only a date and not a time for some source a hypothetical time might be attached as 12.00.00 . 14:47:48 thd: i don't think we do or should do that 14:47:59 i think we should store datetimes 14:48:05 +1 14:48:10 and show date in presentation perhaps 14:48:24 reducing is easy, but we shoudl stay 'true' 14:48:33 yup 14:48:41 that's what I suggested 14:49:00 but back to this one 14:49:05 we have verified that it's not creation only 14:49:09 so the first 2 are out 14:49:22 and we have established that we like using _date if it's a date.. but it's a datetime 14:49:23 If we do not always have dates as date times then we should distinguish between them. 14:50:15 what about created_date and modified_date ? 14:50:29 to prevent updated_date 14:50:33 heh 14:50:48 what did we do on items? 14:51:01 `ed` on `ion` 14:51:02 hm items has timestamp 14:51:26 creation_date, modification_date 14:51:46 sounds nicer 14:51:47 looks like bilbio doesn't have anything 14:51:56 no it should 14:52:20 holds has timestamp too 14:52:25 i think stay consistent for now 14:52:26 timestamp 14:52:37 biblio has a timestamp yes 14:52:45 there are updated_on littered around too cait 14:52:57 there is no 'stay consistent' yet because we are inconsistent 14:53:08 hense me feeling we need to write a guideline properly first.. 14:53:12 yes 14:53:19 but sometimes that's just updated_on 14:53:20 then work on making them all consisntent 14:53:20 like borrowers 14:53:22 they have both 14:53:54 ashimema++ #guidelines 14:54:03 my feeling is we shoudl not hold this up forever for one small decision 14:54:06 we can still fix that 14:54:18 have tomas continue... and then go in and fix according to guidelines at hackfest 14:54:24 guidelines first, fixes later on 14:54:35 tomas can proceed 14:54:37 1.5+ months is a lot in a cycle 14:54:43 and those have been held up already 14:55:00 right.. I think so we don't run out of time we should schedule a guideline for next meeting and not vote this week 14:55:02 cait, but we cannot fix this without breaking backwards compatibility? 14:55:03 changing timestamp to something else in oen cylce is not hard 14:55:05 Certainly we do not come to understand what guidelines should be without struggling with the questions in a real world context. 14:55:15 i am saying fix according to guielines within this cycle 14:55:23 and maybe not backport before we have done that 14:55:30 well likewise.. but I don't feel it is being held up.. code is being written and we have time still in the cycle to correct the terms as per a guidline once the guidline it done 14:55:41 exactly 14:55:48 code is being written, that's correct 14:56:16 the sooner we sort things the better, but we passed the mappings on the development, we will remap if required 14:56:38 [off] sorry, grabbed by another meeting 14:56:57 i am not sure if discussiong things biweekly here is so helpful too - because people don't do homework on this 14:57:05 the rfc are open for commenting 14:57:12 indeed 14:57:14 we have had no additional comments added in the last 2 weeks 14:57:15 maybe 14:57:19 i feel it's unfiar to hold things up now 14:57:31 lets move on 14:57:34 we could have things moving on, and have a period of time in which people can counter propose 14:57:48 during the cycle 14:58:49 vote to vote? 14:59:06 communicate important decisions or guidelines on the dev list ? 14:59:27 wording will not block development anyway, it's a matter of 5min to adjust the patches to a new word 14:59:42 Joubu: yeah, but stuff doesn't get pushed before vote 14:59:43 indeed, that's my point 14:59:49 Joubu we can rename 12 times an hour 14:59:57 stuff is not developped :) 15:00:23 marcelr: I am sure we can do more, it's 5 for the first one, but then we will automate that 15:00:26 I do not see much lack of homework but it may be difficult to elicit proper engaged interactive discussion of nomenclature in this context outside of something as real time as an IRC meeting. 15:01:28 i agree that doing this on a meeting is not very productive 15:01:55 lets skip this, and we will think of a better workflow for this guidelines 15:02:03 * oleonard leaves for another meeting, test 22880! 15:02:05 I will think about it 15:02:33 development is not held by this, the only problem is if things didn't get pushed/integrated because of this 15:02:38 but such is not the case 15:03:01 so, lets move on and I will propose something in the lines of what marcelr said about announcing things on the lise 15:03:03 list 15:03:21 #info votes are not holding up development and as such will be postponed untill we have written clear guidlines for the contentious field names (date vs date and timestamp vs date consistency) 15:03:31 we also need to be consistent, that's certainly the most important bit 15:03:34 #topic Moving on with Bug 22407 15:03:34 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22407 enhancement, P5 - low, ---, koha-bugs, NEW , OMNIBUS: Use DBIC relations to fetch related object rather than searching for the object 15:04:08 was this tcohen or Joubu that raised it? 15:04:17 was not you? 15:04:25 it was all of us 15:04:29 my agenda didnt contain this point too? 15:04:44 marcelr: refresh 15:04:53 i would suggest to copy stuff from the previous meeting directly after that one 15:05:00 and not just before starting 15:06:01 ashimema: is there a "replace them all" plan, or it only applies for the new ones? 15:06:44 ie. are all the related an exhaustive list? 15:06:44 I think that's the question.. I feel like we should plan to replace them all 15:06:56 i would agree with the principle but it might be a major refactor ? 15:07:07 it's not 15:07:11 ok 15:07:13 should be quite easy 15:07:16 even better 15:07:45 at least dont allow new ones to come up again 15:07:52 qa tools? 15:08:08 I do not think it will be possible to write such rule 15:08:23 hoped you could 15:08:54 indeed.. I tried to work out if it was possible but failed 15:09:11 yeah it does not sound easy 15:09:27 but easy to eyeball :) 15:09:29 OK, I'm happy to work with someone on a bug to catch outstanding cases.. 15:09:39 I do tend to catch them in new code as QA or Push time 15:09:40 I will too 15:09:54 add a guideline too 15:10:07 the guideline already exists I believe 15:10:23 PERL15 15:11:11 it is a bit hidden in the examples 15:11:56 feel free to reword it.. I think we voted on it months ago and didn't come up with better 15:12:35 moving on then? 15:12:42 yeah. 15:12:48 ok i will spend 5 mins on rewording ;) 15:13:23 #info We will clarify the wording of PERL15 (perhaps even splitting it out into it's own guidline) for Koha::Object relationships 15:13:30 #topic Review of coding guidelines 15:13:49 #topic PERL27: Return values consistency. If a method returns a list, and there are no items, it should return [] (empty list). If it is a scalar, undef. 15:14:11 do we mean to write return undef; ? 15:14:16 this is not recommended 15:14:30 remind me where this came from 15:15:07 ProhibitExplicitReturnUndef in best practices 15:15:27 and obivously [] is not empty list but () 15:15:52 but a return; in list context does the same ? 15:16:00 * ashimema reaches for the book 15:16:03 where does come from PERL27? what was the context? 15:16:13 who submitted it? 15:16:16 indeed.. that's what I want to know 15:16:21 where's the context.. 15:16:43 in my opinion it should reply in caller context 15:16:50 as a reference https://perlmaven.com/how-to-return-undef-from-a-function 15:17:30 PERL27 15:17:35 I think it was me 15:17:42 lol 15:17:56 never do that again tcohen ;) 15:18:08 the problem is I'm not on the meeting 15:18:09 haha 15:18:31 we are building a framework for simplifying retireval of data for rendering on the API 15:19:02 and we need conventions so we can nicely prefetch related stuffs, and there will be a need for consistency on function call results 15:19:37 that one, was a trivial one, so we don't need to check for defined on the result, and just pass the result to the rendering party 15:20:10 the OpenAPI plugin will reject things that are supposed to be lists and are undef instead 15:20:18 so, to avoid manual handling I proposed a guideline 15:21:16 for the next meeting, could you provide existing examples, good and wrong? 15:21:19 so it needs a bit more context 15:21:27 +1 15:21:57 to be honest, I planned to explain it on the previoius meeting 15:22:09 and didn't notice there was a meeting today 15:22:11 sorry for that 15:22:12 * Joubu vote yes for rule MEETING01 "Provide a new item with context and example, as well as a full guideline" :D 15:22:30 +1 15:22:36 +1 15:22:52 dont_do_things_too_fast++ 15:23:02 haha 15:23:13 shall we move on again then 15:23:37 #topic Reinforce good commit messages guideline 15:23:45 that was me 15:23:48 #link https://wiki.koha-community.org/wiki/Commit_messages#Examples Guidline 15:23:51 note the diff between bug and enhancement here 15:23:53 it was indeed 15:24:05 I tried to enforce this rule when I was RM. And we voted the guideline. The rule is no longer enforced 15:24:18 I'd like to know if we should get back to that or not 15:24:31 You don't always follow it :-P 15:24:37 like: do not c/p the bug title in the commit message, that's 2 different things 15:24:46 yeah, I hate that 15:24:58 I had to raise it because kohaputti FQA one of my patches for that reason :) 15:25:23 ah 15:25:33 selective reinforcement 15:25:41 it should be done at QA level and RM, not necessarily FQA 15:26:01 agreed I think 15:26:05 I vote to definitely enforce it 15:26:12 I do sometimes clean up commit messages on push.. though I'm inconsistent 15:26:12 it is always hard to fail a patch for title only 15:26:14 Have we recently passing patches which match examples of the worst commit messages? 15:26:24 and FQA if author stick to their bad habbits ;) 15:26:34 yes, a lot 15:26:35 I agree with Joubu 15:26:41 me too 15:26:49 It is just one time to fail the patch, the author should learn for the next times 15:26:59 so email to koha-devel ? 15:27:07 exception for new authors perhaps 15:27:07 use social skills and don't be too hard on people, unless they keep their wrong habbit 15:27:12 Joubu++ 15:27:27 new authors are allowed to do a lot 15:27:35 when I was RM, I fixed them on push too 15:27:40 but only the first time ;) 15:27:45 right 15:28:05 having a quick scan of the commitlog we're not straying too far from it all that often 15:28:30 as a qa person I have no idea how many times this person has made non-descriptive patches, so quick fail or no fail is better in my opinion 15:28:40 so, enforcement at QA level isn't terrible.. but equally use a bit of judgement and generally opt on the side of 'be nice'.. 15:28:55 so actually there is no problem? 15:28:56 #action Joubu will send an email to the list to remind devs about good/bad commit messages 15:29:09 I would never FQA a bug on just the title without having looked at the rest of the code first.. I would usually fix it for them and bring it up as a point that they should learn from my change 15:29:29 you always change my titles lol 15:29:36 a reminder is good now and then.. so that would be great Joubu 15:30:05 Without checking I presumed that the issue was more about excessive reference to bug report discussion in commit comments where irrespective of the simplicity of making a simple in comment description. 15:30:40 for me the issue with non-descriptive commits is I have to use more time to understand the patch 15:30:55 I don't want to reverse engineer the patch 15:31:25 that is also about more comment in the code 15:32:03 * ashimema is really struggling to find a bad one going through master 15:32:06 but leaving scope here 15:32:30 "Column Configuration for pay-fines-table does not hide Account Type properly" 15:32:37 it's the bug, not what does the patch 15:33:44 the following sequence of patch does not tell what the patchset does: 15:33:46 24478: Add `EnablePointOfSale` system preference 15:33:54 24478: Use `EnablePointOfSale` preference 15:33:59 24478: Fix sequence in sysprefs.sql and add missing comma 15:34:08 to me.. the really bad ones are 'Address comment #42' and 'follow-up' 15:35:03 {QA follow-up) Some changes 15:36:03 I think we are done :) 15:36:06 yeah 15:36:11 I'm confused.. are you highlighting 24478 as bad or good.. 15:36:17 bad 15:36:26 for me those 24478 ones are really clear 15:36:29 Fix sequence in sysprefs.sql and add missing comma is not that bad 15:36:48 how would you have worded them? 15:36:50 it describe what you do 15:36:52 The main patch is "Use `EnablePointOfSale` preference" 15:37:12 Joubu, read the body if you wanna know more details why it is used 15:37:13 Add a global switch to turn POS off 15:37:26 body is for more explanation 15:37:35 what.. for all three patches you would use that single title? 15:37:44 or you would submit it as one bigger patch 15:37:47 Introduce pref X to allow enabling or disabling 15:38:12 Use pref X is a bit cryptic 15:38:28 * ashimema is looking at this as constructive criticism.. I like :) 15:38:39 fair 15:39:00 I tend to break down bugs into small commits to ease rebasing and backporting personally.. 15:39:08 which is great 15:39:21 it is just about the title 15:39:21 I do not understand that one: "Dobbie is a free elf" 15:39:23 what did you mean? 15:39:25 ;) 15:39:38 next meeting? 15:39:38 next meeting is https://wiki.koha-community.org/wiki/Next_IRC_meetings 15:39:43 ashimema, here it would have been better to make use of the syspref in the same patch it is introduced 15:39:43 your latest patch, Joubu ? 15:39:50 ok.. I think we can probably move on. 15:39:52 lol 15:39:54 'Guess the RM' 15:39:59 ashimema++ 15:40:12 #topic Set time of next meeting 15:40:20 same schedule as ever.. 15:40:30 kohaputti: no, 1 patch for the new pref is good 15:40:45 so, 5th 15:40:48 you can spot omission easily 15:41:02 Joubu, not for reading a story or reverting feature 15:41:19 it does not happen often 15:41:19 Joubu, what omission you are talking about? 15:41:26 what time shall we make it.. 15:41:40 add a pref is: atomicupdate, sysprefs.sql, pref.inc 15:41:44 anything fine for me 15:42:06 That is one week? 15:42:15 2pm or 8pm UTC is the usual switch 15:42:17 no it should be two weeks 15:42:35 oops 15:42:49 you're right.. i read the wrong line 15:42:51 it always toggles, good for NZ bad for Europe 15:42:55 12th.. but that's also a general meeting on the 12th 15:43:08 the general should be on the 5th ? 15:43:12 8pm on the 12th is the general meeting.. 15:43:55 1 or 3 weeks then 15:43:58 how about 11th 8pm 15:44:08 We have been on a second week of month or so pattern for general meetings recently. 15:44:09 so same time as general meeting, but a day early 15:44:51 or.. 15:44:57 we need to resync, otherwise you will have the same problem next month 15:45:19 do we want 1 or 2 dev meetings a month ? 15:45:28 every 2 weeks 15:45:31 ok 2 15:45:58 second tuesday fourth wednesday ? 15:46:31 I would pick Wed 19th 15:46:39 I'm thinking 5th.. to keep the ball rolling on getting those API guidelines done and bringing us back to the off week for general meeting. 15:46:45 it can be a nice short one with just a vote on that guidline I'll draft this afternoon 15:46:46 or 5 yes 15:46:54 5th and 19th and sticking to first and third 15:47:20 also.. 5th gives us another week to remind GBSD on 14th :) 15:47:20 twice a month means every 2 or 3 weeks 15:47:51 Yes, months are not evenly divided by weeks. 15:47:54 that's why I answered you 1 every 2 weeks 15:48:03 Joubu that could be confusing too 15:48:07 endmeeeeeting 15:48:10 heh 15:48:21 #info Next meeting: 5 February 2020, 20 UTC 15:48:41 #endmeeting