09:16:54 #startmeeting Koha General IRC Meeting, part1 09:16:54 Meeting started Wed Dec 17 09:16:54 2014 UTC. The chair is cait. Information about MeetBot at http://wiki.debian.org/MeetBot. 09:16:54 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 09:16:54 The meeting name has been set to 'koha_general_irc_meeting__part1' 09:16:57 ha you have not started^^ 09:17:16 sorry for the dealy, i was doing some tricky sql updates (end of year things in acq) 09:17:19 forgot the time a bit 09:17:28 #topic introductions 09:17:29 #info wahanui, a bot that has become sentient 09:17:34 please introduce yourself with #info 09:17:55 #info Mirko Tietgen, Berlin 09:17:57 #info Katrin Fischer, BSZ Germany 09:18:46 #info Thomas Dukleth, Agogme, New York City - via California for the next 10 days 09:18:48 that's a small meeting :D 09:18:49 we could hold the meeting in german 09:18:53 ah, maybe not then :) 09:19:06 #info Jonathan Druart, BibLibre 09:19:25 I think ashimema will probably be back once i change topic :) 09:19:38 #topic Announcements 09:20:31 I can see a note from chris_n on the wiki 09:20:34 oh we could have tried this as a video conference to test my webinar server ;) 09:20:48 but i think the issue has been resolved since 09:21:05 #link agenda http://wiki.koha-community.org/wiki/General_IRC_meeting_17_December_2014 09:21:52 #info bug 10821: For all interested parties, the fix for this has been applied in Library::Callnumber::LC 09:21:53 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10821 major, P1 - high, ---, cnighswonger, CLOSED WONTFIX, label pdf adding in strange breaking 09:22:06 i assume voting up that bug requires a google account 09:22:15 ah it's done already \o/ 09:22:15 i think it's no longer necessary now 09:22:20 but it seems you need to be registered 09:22:27 #topic Update on releases 09:22:28 #info Martin Renvoize, PTFS Europe 09:22:36 any release maintainers awake and around? 09:23:27 from the info i have the releases are still scheduled to happen on 22nd 09:23:45 we can only hope ;) 09:24:10 and we had an unscheduled security release 09:24:15 release_maintainers++ 09:24:36 #topic Discussion: Road Map for Koha 09:25:21 I like the idea of a Roadmap.. 09:25:23 I think the goal was to discuss more about the contents this time 09:25:38 or the review bit for 3.18? 09:25:41 also happy to be not time baed.. just a sort of project directional aid 09:25:56 yeah i think general goals are good to write up 09:26:03 and update the status of them regularly 09:26:26 will people around now be able to make it to the second meeting tonight? 09:26:43 i will probably 09:26:43 tonight/today 09:26:52 A roadmap of arbitrary depth and detail could be maintained easily in the wiki. 09:27:41 Maintaining a summary on the website would be a greater task and would necessarily be out of date. 09:27:47 yeah, I think the wiki will be a good place 09:27:50 hoepfully will be around 09:28:11 wiki++ 09:28:18 as we are not so many people... maybe we can postpone deeper discussion to the second part today? 09:28:25 I think it would be better to point a roadmap page on the website to some suitable set of linked pages in the wiki. 09:28:28 agreed 09:28:49 #idea use the wiki, point from the website to the wiki - easier to keep updated 09:28:58 However, if anyone wants to maintain a summary on website, great. 09:29:25 wiki's can export to html given the right tools.. 09:29:39 I'de maintain in the wikie and pull data from it on the website if it were me 09:29:58 #idea pull the data for the website out of the wiki 09:30:28 anything else? 09:30:39 ashimena: Certainly, however, the useful content for a summary from the wiki is liable to be multiple linked pages which may be different from the preferred presentation of a summary on the website. 09:31:30 yup.. hence there would need to be a small amount of manipulation website side.. 09:31:41 I've done things like that before.. 09:31:43 i think maybe a link to the wiki is all we need 09:31:54 grabbing links and trasnforming them into title for instance. 09:32:07 but a link is deffo suffice for the start 09:33:01 #idea use a link and leave content on the wiki 09:33:45 are we ok? 09:34:12 I will switch to the next topic 09:34:15 #topic Election: wiki curator 09:34:28 #link http://wiki.koha-community.org/wiki/Proposal_for_Wiki_Curator_3.20_Thomas_Dukleth 09:34:33 A summary even from linked wiki pages might be created from a script but the effort is probably better applied to creating and maintaing useful content in the wiki. 09:34:44 agreed 09:34:50 ++ 09:35:19 I've expressed my thoughts on the curator proposal discussion page. 09:35:22 I posted a list of candidates for holding the position collectively for the previous meeting. 09:35:37 thd: do you have a link or can repost? 09:35:44 I'de rather a more open procedure for chsooing extensions etc.. 09:35:53 checking 09:35:57 http://wiki.koha-community.org/wiki/Talk:Proposal_for_Wiki_Curator_3.20_Thomas_Dukleth 09:36:08 I tend to agree, I am worried about missing security updates etc. it seems we already fell behind quite a bit 09:36:30 we are at .16.. mediawiki was at .22 last I looked 09:36:38 maybe it's worth taking the chance to simplify our setup a bit 09:36:49 .24 in fact 09:37:26 I also tend to feel we're over complicating the wiki.. I've been wanting to nuke half the extensions for a long time now 09:37:33 We have very good backups in version control. 09:37:38 #info a discussion has been started on the wiki - http://wiki.koha-community.org/wiki/Talk:Proposal_for_Wiki_Curator_3.20_Thomas_Dukleth 09:37:56 Do we actually have many extensions? 09:38:11 I suspect that most people want more extensions. 09:38:33 I think while some of them are generally useful, we might not make use of them 09:38:50 The problem with updating is that it breaks things unless planned carefully. 09:38:51 we have like 6 category based extentions.. 09:39:02 that make adding/editing the wiki plain hard. 09:39:44 We're using postgres, which isn't well supported by mediaiwiki or it's extensions either.. 09:39:45 ashimena: Some work together with dependencies. 09:39:54 which is one of the issues preventing easy upgrades 09:40:16 personally.. I would remove all the category extensions.. 09:40:33 and then choose a elected set to use 09:40:39 Upgrades are not prevented. Upgrades require planning and testing. 09:40:59 removing the ability to add categories in the markup is a step backwards 09:41:12 they are prevented.. as they're in the hands of one or two people with no time.. 09:41:15 We did that once without planning and testing and then I had to spend some days fixing things. 09:41:18 hense planning and testing is prevented.. 09:41:46 I would prefer this convesation took place with more parties.. 09:41:59 I think that's where being closer to a standard version could help us - making updates easier 09:42:10 I'm not against you here thd.. but I think we have very differeing opinions which could do with someexternal thoughts going forward 09:42:27 The implementation is under git version control for which anyone can obtain a copy. 09:42:31 I am helping to maintain our dokuwiki here - and moving away from our customizations have helped a lot to increace maintainability 09:42:44 Thus, anyone could test. 09:42:49 that's not public knolledge as far asI'm aware 09:43:17 not being familiar with the technical aspects of our wiki, what customisations are we talking about? 09:43:18 gmcharlt, might need to facilitate some access as it is hosted at Equinox. 09:43:45 #link http://wiki.koha-community.org/wiki/Website_Administration#wiki.koha-community.org 09:43:52 we culd put the information there 09:44:01 We had previously used DokuWiki. 09:44:17 #idea add information about installed plugins, changes to standard wiki to the wiki 09:45:08 The problems that had is with no authority control over suggesting categories most content had no categories and could not be found systematically. 09:45:08 thd: i know - just using it as an example. We encourage people to not change koha in ways that hinder update, but we seem to do just that with our wiki 09:45:59 The "cumbersome" category extensions make content findable in a systematic manner. 09:47:04 Yes, a burden is added to the user when creating a new page. However, every later user of the page benefits from the initial effort. 09:47:08 ack.. my other call is getting busy.. 09:47:11 dropping out again for a bit. 09:47:13 sorry 09:47:14 I think there are some valid concerns here - maybe we should gather some more info and try to rethink this together? 09:48:04 Mostly, maintenance has been neglected. 09:48:54 That is significantly my fault but I know how to remedy the situation. 09:49:15 I think the idea we propose is mostly making this more easy in the future 09:49:30 time is the single resource we never have enough of 09:49:39 more important than funding or anything else I think 09:50:04 The wiki should have content linked from the front page explaining good use and its advantages as I did for the former wiki before we lost that to PTFS/LibLime trouble. 09:50:30 s/did/had created/ 09:50:44 I think we should not create too many rules/barriers 09:50:57 They were never rules. 09:52:01 The only rule that might be enforced is assigning at least one category to a newly created page to keep it from becoming lost. 09:52:06 i hop this didn't come across too negative - I appreciate that you want to take this on and hope we can have some discussion on how without being discourating 09:52:38 I had taken it on in the past. 09:52:53 Most of my work on the former wiki is sadly lost. 09:53:28 I also pushed for MediaWiki over DokuWiki. 09:54:40 The choice of wiki software was meant to be a contest. However, LibLime took down the earlier DokuWiki wiki which had held most all of the content at the time. 09:54:43 do we have usage statistics for the wiki? like, how people actually use it? maybe it's just me, but i hardly ever use anything but the search function 09:55:10 s/LibLime/PTFS\/LibLime/ 09:55:50 that's all right 09:55:59 I didn't mean to question the mediawiki choice at all 09:56:07 drojf: Google has brainwashed you into thinking that libraries and curation are unnecessary when you have full text indexing :) 09:56:20 i personally prefer dokuwiki as we are using that here - but that doesn't mean i would want to propose a change .) 09:56:46 thd: i don't want to imply it is not needed! not at all. i just wonder if there are statistics. i have no idea what other people do :) 09:57:23 MediaWiki is a larger and necessarily more complex project as it has to support whatever people want for Wikipedia. 09:57:24 I can only speak for myself, but i use the search feature too :) 09:57:25 i don't think i am the regular wiki user. also i have bookmarked most of the stuff i use often ;) 09:58:26 thd: i think we are using mediawiki for the koha project - noone questions that 09:58:38 Categories allow finding RFCs for what people are working on, etc. in a systematic manner. 09:59:00 i think the problem here is maintenance, as those don't get updated, so the categories are not correct 09:59:17 and some rfcs are not marked, although they won't be implemented or have never implemented in the way written up on the wiki 09:59:48 cait: There was meant to be a question and a vote but the issue became somewhat moot when PTFS/LibLime took down the DokuWiki implementation. 09:59:53 but that's content we need to fix and maintain 09:59:54 personally i am more concerned with outdated contents than categorisation at the moment 10:00:16 i can't pass a link to a library that wants to switch to dom, because the information on the wiki is not accurate 10:00:36 drojf: We should tag the content as outdated but then encourage people to update it. 10:02:10 Some Wikipedia editors have a habbit of deleting pages which I think is a bad idea for a library software. We should preserve it but mark it. 10:02:11 is that possible at the moment? (tagging it outdated) 10:02:18 i think a 'how to' with hints on how to use the features might be good 10:02:33 like a note on how to add something to mark it 'outdated' most effectively 10:02:39 and in a searchable way 10:03:26 I had created a good tutorial for DokuWiki and was taken aback when it all went down. 10:04:25 At the time, it was a tit-for-tat response over starting an independent bugzilla instance. 10:04:31 I'd like to give the second part of the meeting the chance to contribute to this before we vote 10:05:04 Certainly. 10:05:05 certainly is confusing.. thanks for bringing ashimema's attention to it. 10:05:19 I will not be around for the second part. 10:05:48 hm ok 10:05:49 maybe the wiki? 10:06:05 We should at least consider in this part whether the more the merrier bug wrangler concept applies. 10:06:53 I favour that concept which has certainly contributed to and not lessoned the level of maintenance. 10:07:19 so the question is if we will have more than one wiki curator for the content? 10:07:28 or is this also about the technical side/server access? 10:07:32 li#patronbasics img[src$="blank.png"] { display: none !important; } 10:07:43 ^ hide the patron image if there is no image set 10:07:44 There have defacto been multiple wiki maintainers working simultaneously. 10:08:35 i don't think it is possible for one person to maintain the whole wiki (speaking of accuracy contents) in their spare time 10:08:35 There is a list in the candidates page but others should be free to join. 10:08:42 I think i'd leave the role open to everyone who wants to contribute 10:08:43 +1 10:08:45 (contents accuracy) 10:09:00 and we also have people with different areas of expertise 10:09:07 (if that works as an english word :) ) 10:09:32 Maintenance has a very broad scope. 10:10:14 I had concentrated on the backend and trying to avoid orphan pages. 10:10:19 I am not sure how to proceed - i think what i see is a general agreement that curating is a multi-people thing? 10:11:00 i'd agree to that 10:11:01 can i get a quick indication if that is right? 10:11:02 +1 10:11:06 +1 10:11:07 +1 10:11:11 +1 10:11:38 #agreed Curating the wiki content should be a multi-people approach 10:11:47 hope that will make sense to the meeting later 10:11:57 right.. 10:11:59 I'm back.. 10:12:00 reading up 10:12:06 as we run out of time a bit, I'd like to move on more quickly now 10:12:21 #topic Communication manager 10:12:34 to my information noone has stepped up yet willing to fill the role 10:13:17 I am not certain that the scope of communications manager has been well defined. 10:13:37 yes, that might be the problem 10:13:40 However, no one has stepped forward for any definition. 10:14:13 I think maybe this would be better to bring up to the mailing list agan 10:14:36 +1 10:14:43 for the mailing list 10:14:49 +1 10:15:54 #agreed bring up the communication manager role on the mailing list again 10:16:02 #topic KohaCon15 10:16:10 hi all. (jo ransom, hlt - nz) 10:16:16 hi jo :) 10:16:31 quite late for you! 10:16:51 you can add #info in front, then it will show up in the meeting minutes 10:17:17 I think today there is noone fromt he organisers around -maybe it's a bad time 10:17:21 i will move on 10:17:36 #topic Actions from the last meeting 10:17:43 #info jransom 10:17:57 I'll add more thoughts on the wiki propositions to the discussion page rather than pollute further here 10:18:00 hm i think we have an old link on the wiki, one sec 10:18:39 the correct link to the last meeting: 10:18:41 #link http://wiki.koha-community.org/wiki/General_IRC_meeting_19_November_2014 10:18:46 I did allot fo the work on https://wiki.openstreetmap.org/wiki/Main_Page back in the day.. and that wiki is now happily self sustaining... I also install, maintian and train mediaiwki for a series of customers.. 10:19:05 just so thd has some of my own background 10:19:31 #info the community website has been updated with information about kohacon15 10:19:59 #link http://koha-community.org/kohacon/kohacon15/ 10:20:23 @later tell wizzyrea can you update http://koha-community.org/kohacon/ please to list Nigeria as upcoming? thx! 10:20:23 cait: The operation succeeded. 10:20:54 and i think BobB emailed the list about the roles, but as said earlier we need to bring that up again 10:21:12 anything else? 10:21:59 #topic Set date and time for next meeting 10:22:09 I thik maybe we shoudl leave that to the second part 10:22:14 as we have only very small attendance today 10:22:16 i'd vote for only one date 10:22:23 that ok? 10:22:30 this split does not really seem to work well 10:22:47 #idea go back to 1 meeting instead of 2 10:22:51 has the koha fundraising idea been discussed at all? 10:23:00 jransom: nope 10:23:00 jransom: it hasn't been on the agenda - not sure about the state 10:23:01 Presumably the second part would be more interested in a later time. 10:23:04 nobody showed up 10:23:11 drojf: jo did :) 10:23:14 ah 10:23:17 sorry :)) 10:23:25 but i think maybe the time is bad for california/bag? 10:23:46 I am in California at the moment. 10:24:08 However, it is not a great time for California. 10:24:13 jransom: i think probably the second meeting - but it would have been good to add to the agenda - guess we forgot 10:24:24 about splitting the meeting, i think we get more out of one meeting followed by mailing list discussions if necessary than with two seperate parts of one meeting 10:24:41 I have a feeling too that the experiment has not been successful 10:24:50 there is always one meeting with only very few attendees 10:24:51 the fundraising idea is being discussed via email. 10:25:06 Nor is it a great time presently for the US in general. 10:25:09 #info leaving setting date and time to second part of the meeting 10:25:15 #endmeeting