16:00:48 #startmeeting Documentation IRC meeting 6 January 2022 16:00:48 Meeting started Thu Jan 6 16:00:48 2022 UTC. The chair is davidnind. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:48 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:48 The meeting name has been set to 'documentation_irc_meeting_6_january_2022' 16:01:03 #info Agenda https://wiki.koha-community.org/wiki/Documentation_IRC_meeting_6_January_2022 16:01:13 #topic Introductions 16:01:23 #info David Nind, New Zealand 16:01:48 #info Caroline Cyr La Rose, inLibro, Quebec (Canada) 16:01:58 #info Aude Charillon, PTFS Europe, UK 16:01:59 #infor Kelly McElligott, ByWater Solutions 16:02:01 #info Katrin Fischer, BSZ, Germany 16:02:02 #info marie-luce, inlibro Montreal, Canada 16:02:14 #info Lucy Vaux-Harvey, PTFS Europe 16:03:11 Great to have so many people here! 16:03:24 and Hi everyone 16:03:30 davidnind++ for reigniting this :) 16:04:01 davidnind++ 16:04:01 I eventually get there, sometimes... 16:04:12 #topic Review of action points 16:05:25 Not too many so far, I've addressed tow of mine but one still to do 16:05:44 #action davidnind to look at previous meetings and add any current or still relevant items as tasks to Bugzilla 16:06:16 ashimema is not here I think to update us on his one, so I will carry forward 16:06:45 #action ashimema to look at adding docs tasks to the dashboard https://dashboard.koha-community.org/ (bug 29752) 16:06:45 04Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29752 enhancement, P3, ---, martin.renvoize, ASSIGNED , [DOCS] Look at adding documentation tasks to the dashboard 16:07:40 #topic Project updates 16:08:34 Nothing from me to report on any of the projects, still adding as tasks to Bugzilla 16:08:44 #link https://wiki.koha-community.org/wiki/Koha_Documentation_Team#Projects 16:09:51 #topic What's been done so far 16:10:30 It's been pretty quite of the holiday period, so not too much to report in the way of updates 16:11:18 congratulations to aude_c - first change pushed to the manual! 16:11:29 aude_c++ 16:11:32 Haha, thank you! 16:11:33 aude_c++ 16:11:37 aude_c++ 16:11:42 aude_c++ 16:11:51 aude_c++ welcome! 16:11:59 hope the process wasn't too daunting and that there will be more! :) 16:12:13 Thanks; lucyvh picked a very easy one for me to start with. 16:12:29 lucyvh++ 16:12:36 I'm good at spotting the easy ones! 16:12:45 Thanks lucyvh! 16:12:46 lots of small steps are great :) 16:13:00 I tried to follow your instructions from the last meeting's agenda too davidnind (regarding Bugzilla); hope that's how you thought it should work 16:14:05 it was mostly there - I ended up merging all the commits into one and changing the commit message slightly 16:14:40 thanks for updating the bug as well, I think that is the first using the new way! 16:15:04 could yo ushare the bug number as an example? 16:15:17 Should I be merging all the commits into one before creating the merge request, then? 16:15:44 I think there is a checkbox on gitlab that might achieve that when doing the merge request 16:15:55 i have set it a few times, but didn't check the outcome 16:16:01 Anyone got anything else to share on what they've been working opn - nothing from me (apart from everything seems to be work in progress, and nothing finalised) 16:16:02 cait: Bug 29180 16:16:02 04Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29180 normal, P5 - low, ---, jonathan.druart+koha, RESOLVED FIXED, System preference RequestOnOpac should be renamed 16:16:12 I used your new keyword! 16:16:38 :) 16:17:05 cait: thanks for the gitlab tip 16:17:33 cait: there is in GitLab, it is a tick box to say merge the commits so that there is just one commit for the history - it made it much easier than doing manually from the command line 16:18:10 I tihnk it might be on both sies then - when making the merge request and when merging it? 16:18:17 the tickbox 16:18:31 Will do that in future too 16:18:48 We were not sure what needed going regarding the google spreadsheet? It's read only, so will you update that davidnind? 16:18:50 is it called squashing or is that something else? (Sorry, not used to the terminology!!) 16:19:37 I will have a look and document it next time I do a change 16:19:50 thanks 16:20:01 aude_c: couldn't find a picture yet, sorry 16:20:06 thanks davidnind 16:20:19 is there a link with the new procedure? Some of these things are new to me 16:20:23 the spreadsheet should be writable, so I will check that out 16:20:46 davidnind++ 16:20:48 hm so should we update bugzilla and spreadsheet then? 16:21:15 #action davidnind make sure spreadsheet for release changes (22.05 and 21.110 is editable by others 16:22:14 #action davidnind to write up changed workflow processes on the Wiki - using bugzilla for managing documentation tasks 16:24:07 just trying to find where we discussed this 16:24:12 one sec... 16:24:29 I used https://wiki.koha-community.org/wiki/Documentation_IRC_meeting_2021-12-16 16:24:40 aude_c++ 16:24:41 thanks 16:25:58 I'm afraid I have another "newbie" question... Will the updates to the manual be in previous versions too? 16:26:12 bye 16:26:33 Like, for the one I did the sys pref name changed in 21.11 - so will the 21.11 manual be updated? 16:27:09 I generally try to - master is updated, then I "cherry pick" the change for the previous version 16:27:36 Ah, great :) 16:28:29 mostly that works okay, but h=if there are a lot of other changes it may need to be done manually.. 16:28:36 not sure if this topic will still come up - is there any progress on translations, more so updating the po files for 21.11? 16:29:29 It's on the agenda so will cover next 16:29:36 sorry ok 16:30:45 no problem! 16:31:35 was trying to add a summary of the workflow change... 16:35:05 summary of work flow change- using Bugzilla for managing documentation changes: 16:35:06 1. Bugzilla task for release change has 'Manual' keyword added 16:35:06 2. When the manual is updated: add a note to the bug saying the change to the manual was made, here it is for review, and that comments are welcome 16:35:06 3. Add Manual-updated keyword (and remove Manual keyword) 16:35:27 I hope I've got that right! 16:36:56 Also, there are queries for Bugzilla for 22.05 and 21.11 to list items for a release with the 'Manual' keyword = see the agenda for the link 16:37:06 #topic Content development guidelines 16:37:53 Not too much here, I will cover the translation issue first 16:38:37 #link Process for translating the manual: https://wiki.koha-community.org/wiki/Documentation_management#Translating_the_manual 16:39:05 I've documented the process, so any any comments welcome 16:40:07 the only think I'm not sure of is updating the strings on Pootle - I think I need to send a message to the Translation Manager (Bernado) 16:40:38 on first glance the docs look good - some details like updating the po on pootle I don't know about either 16:41:28 it doesn't seem to have happended in a while 16:41:29 I haven't sent a message to the translation manager (Bernardo) yet, so I will do that after this meeting 16:41:40 recent changes didn't shop up for translatoin on the olders ones 16:43:20 I think the other change I was going to make was to get the strings updated once a month - see bug 29647 16:43:21 04Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29647 enhancement, P5 - low, ---, david, ASSIGNED , [DOCS] Update po files in manual repository 16:44:29 #action davidnind to work on getting the po files for the manual updated (bug 29647) 16:44:36 +1 16:45:42 anything else on translation - the mystery bit for me is how Pootle gets updated with the recent manual changes 16:46:14 apologies, am a bit slow this morning... 16:46:15 i think we need Bernardo to clear up some steps of th eprocess ultimately 16:47:38 hopefully we can get it fixed up reasonably quickly, so those who translate can translate! 16:48:59 I added commit messages as an agenda item, does anyone have any questions about this? 16:50:48 The main thing (and an update to https://wiki.koha-community.org/wiki/Git_guide_for_documentation#Commit_messages is required) is to used the format: 16:50:48 - Title = Bugzilla number: Short title 16:50:48 - Description: Explain briefly what has changed and why 16:51:35 This is basically similar to how Koha does things 16:51:43 Any comments/questions? 16:51:58 not from me 16:52:31 If we do it this way then the commit history should be relatively clean, see https://gitlab.com/koha-community/koha-manual/-/commits/master 16:52:51 Is it useful to know which versions the change is for? 16:53:14 To help with cherry picking to previous versions? 16:53:30 Or does that overcomplicate things 16:54:15 If it helps you can add it to the commit message, otherwise add as a comment to the merge request 16:55:34 Will do, thanks 16:55:38 so either add something along the lines that "This change was made in Koha XX.XX", which will act as a prompt for me 16:56:03 I normally try and check, for release related changes, which version I need to go back to 16:56:40 #topic Next steps 16:57:46 I'm still updating Bugzilla with the manual keyword for 21.11 release changes, 22.05 was up-to-date last week... 16:58:59 I don't have any particular priorities at the moment 16:59:22 I will update the list of easy, medium and hard tasks (https://wiki.koha-community.org/wiki/Koha_Documentation_Team#Easy.2C_medium_and_hard_tasks) 16:59:56 feel free to add anything you would like there 17:00:35 if anything the priority should be on updating new features for past releases 17:01:16 If anyone would like something to work on, using the manual keyword Bugzilla queries would be the place to start, and pick something 17:01:29 Otherwise, I'm, happy to suggest something 17:01:56 Do any of you have any particular areas you want to work on? 17:02:40 Also, where has the last hour just gone! :-D 17:03:44 I'm still finding that I can't edit some of the larger rst files using gitlab in a browser - the edit page just hangs. Not sure if anyone else finds this or has any advice? 17:03:53 No particular areas I want to work on; but certainly some I'll try to avoid!! 17:04:54 :) 17:05:57 lucyvh: I think the only solution there is to work on them locally (which is a more complicated work flow intially) until we can break things up into smaller files 17:06:26 I think I try to avoid cataloging (and MARC things) :-D 17:06:53 I hope to just get sth done right now tbh 17:07:08 but it's also good to keep docs in mind when doing QA 17:07:22 Thanks davidnind - 'complicated workflow' sounds bad!! 17:07:26 lucyvh: which are the files most problematic right now? 17:07:33 cait++ 17:07:59 lucyvh: not super bad, but involving git instead of only the gilab website 17:08:13 it's not too bad, once you get the hand of it - clone the repository locally, 17:08:14 I haven't been doing much lately but tried circpreferences.rst this afternoon and couldn't work with it 17:08:31 :( we had already split that one up 17:08:46 i was hoping it would be enough 17:08:53 cait: I know sorry!! 17:08:58 not your fault at all 17:09:07 just was hoping it was something that I had an idea abou thow to solve :) 17:09:57 OI'll have a think about how to organise the system preferences section a bit better - am open to ideas if anyone has any... 17:10:20 and my spelling is atrocious this morning! 17:10:25 I'll look into the local repository approach 17:11:19 No worries if it's only me - I probably need a new laptop :) 17:11:35 the thing is that when we split sections, they are also split as different pages in the manual, so we have to be mindful of that 17:12:06 yes, best is to make the split 'logical' in some way... 17:12:16 so it also caters to the structure of the manual 17:12:43 I know we're way overtime, but do we still have plans of going in a less linear manual? 17:12:50 its not you, just a limitation using GitLab and large rst files - you can generally click on the raw link 17:13:05 I do 17:13:16 we also had discussed having a video meeting - maybe that could be a first topic to gather ideas? 17:13:40 excellent idea cait! 17:13:49 cait++ 17:14:24 I will add a Bugzilla task for reorganising the manual, and add some ideas there as a starting point - everyone is welcome to comment 17:14:31 just glad the video meeting was not today, but wlil be ready next time :) 17:15:05 #action davidnind to add a Bugzilla task for reorganising the manual so that it is less linear 17:15:25 I was going to test Jitsi, but will leave to next time.. 17:15:53 I've used Jitsi before; very easy to use 17:16:56 Is everyone okay to make the next meeting a video conference one? 17:17:07 Yes sure 17:17:10 sure 17:17:18 +1 17:17:41 #topic Set time of next meeting 17:18:00 +1 17:18:08 Okay we will go with having a video conference meeting for the next meeting 17:19:06 Same time if that suits everyone, and the first week of the month? 17:19:20 yes 17:19:26 which would be 3 February 2022, 16:00 UTC 17:19:56 #info Next meeting: 3 February 2022, 16:00 UTC 17:20:06 #endmeeting