14:00:24 #startmeeting 2014-04-10 - DIG Monthly Meeting Evergreen Documentation Interest Group (DIG) Monthly Meeting. 14:00:24 Meeting started Thu Apr 10 14:00:24 2014 US/Eastern. The chair is yboston. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:24 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:00:24 The meeting name has been set to '2014_04_10___dig_monthly_meeting_evergreen_documentation_interest_group__dig__monthly_meeting_' 14:00:42 #topic Introductions 14:00:44 eeevil: dkyle: sounds fine to me 14:00:59 welcome everyone, please start introducing yourselves 14:01:17 #info remingtron is Remington Steed, Hekman Library (Calvin College) 14:01:42 * rsoulliere is Robert Soulliere, Mohawk College 14:01:55 * yboston is Yamil Suarez @ Berklee college of Music - DIG meeting facilitator 14:02:01 #info jihpringle is Jennifer Pringle, Sitka (BC Libraries Cooperative) 14:02:03 BTW, The agenda can be found here http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:dig_meeting_20140410-agenda 14:02:05 #info kmlussier is Kathy Lussier, MassLNC 14:02:21 #info akilsdonk is Angela Kilsdonk, Equinox Software 14:02:27 #info rfrasur is Ruth Frasur, Hagerstown Library, Evergreen Indiana 14:02:28 #info kbutler is Kate Butler, Rodgers Library 14:02:36 #info ericar is Erica Rohlfs, Equinox Software 14:02:54 #info terranm is Terran McCanna, PINES 14:03:03 #info CarrieC is Carrie Curie, PALS 14:03:10 #info dluch is Debbie Luchenbill, MOBIUS 14:03:49 Wow! Nice turnout today. :) 14:04:02 lets wait anothre minute, before we start 14:04:16 welcome everybody :) 14:04:20 Here is the agenda again: http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:dig_meeting_20140410-agenda 14:04:34 #info denials is Dan Scott, Laurentian University 14:04:38 (mostly lurking) 14:04:50 * rfrasur is mostly lurking as well. Sorry. 14:05:26 I think we can start, remingtron do you want to start off with your proposal? (BTW< do you know the meetbot syntax?) 14:05:34 (I can take care of it if you want) 14:05:45 hmm, I can try 14:05:55 just type #topic _name_ 14:06:13 or tell me what topic name to sue 14:06:16 *use 14:06:24 #topic Proposed goal: Document all new 2.6 features by July 1, and all new future version features by the time the version is released. 14:06:44 remingtron: http://evergreen-ils.org/dokuwiki/doku.php?id=community:using-meetbot is helpful. 14:07:21 #info I mostly explain this on the agenda, so in summary, I think DIG should adopt a more formal workflow to ensure that all new features get documented by the time each new version is released. 14:07:32 kmlussier++ #thanks for the link 14:08:11 I like the proposal 14:08:24 I think a more formal workflow would be useful. 14:08:27 remingtron: +1 to 2.6 documentation by July 1. 14:08:53 I like it, too. 14:09:14 +1 14:09:17 For future versions, I like the goal of getting the documentation done by release time and think we should work toward it. And if we continue to get this much participation in DIG, I think we can reach it. 14:09:29 kmlussier: I agree 14:09:35 But if we go back to 3 or 4 active participants, it's not as likely. 14:10:01 if we had 3 remingtron we would :) 14:10:15 And in relation to agenda item II.d., I suppose depending on how many active DIG participants we have, maybe there could be a group working on older feature updates, in addition to making sure the new versions are ready for release date. 14:10:21 yboston: how kind :) 14:10:22 That's true. So, remingtron, can you clone yourself? 14:10:36 hmm... 14:10:39 @clone remingtron 14:10:39 remingtron: Try restarting apache. 14:10:45 nope, sorry 14:11:03 I have doen some work on older versiosn, I could keep a focus on that 14:11:14 while others focus on new features 14:11:46 I think remingtron's approach to focus on new features at alpha time makes a lot of sense. 14:11:49 dluch: do you mean features not previously documented, or updating now out-of-date documentation for new versions? 14:12:06 Once the .0 release is out, there shouldn't be many new features to document, As long as we stick to the schedule. 14:12:19 kmlussier +1 14:12:48 +1 14:12:49 Hmm...both, I suppose, but I was especially thinking of features that exist already but haven't been documented 14:12:58 kbutler: I keep focusing on older features that need updates, I keep forgetting about features that have never been docuemtned 14:13:15 (need to remeber those too) 14:13:40 would be nice to have something like "...if you encounter this..." 14:14:19 tonyb_ohionet: do mean like a tip of what to do if you encounter errors? 14:14:38 Yes...that would be great...pointers for new users.... 14:15:16 I think there are definitely things that could be added, but it seems that documenting both new features and never documented features should be priority...at least in my mind. 14:15:16 yeah, it can feel like DIG has a mountain of work to do, which is why I think focusing on the upcoming features first will help us gain traction and then work on the backlog of undocumented stuff as we can 14:15:22 Who here can commit to documenting 1-3 features a month? I can. 14:15:31 I can too 14:15:32 I can 14:15:51 I can try...just still lost figuring out how to get started... 14:15:54 sorry guys.... 14:15:55 remingtron: I think the 1 to 3 features a month makes it feel more manageable too. You aren't looking at the entire mass of docs that need to be done; just focusing on your bit. 14:15:55 i can, now that the conferece is over :) 14:15:58 I can commit to documenting one...if someone tells me which one to do. 14:15:59 I can, with the caveat that I'm off for the entire month of May for surgery recovery. 14:16:14 also, Galen's Git tutorial helped me get better at Git 14:16:25 I think the focus on new features are good, but it's also just as important to keep the existing documentation up to date. 14:16:27 (also the lynda.com Git tuttorial) 14:16:29 (and it's in my skill set...which is not particularly good at anything) 14:16:55 kbutler: that's true 14:17:01 tonyb_ohionet: What would help you get started? Identifying features to document? 14:18:02 The Update Expire Date button one should be a nice bitesize feature to document for somebody just getting started. 14:18:07 Well...yboston and I have been working on the basics...(he's awesome) 14:18:22 I concur. yboston is awesome! :) 14:18:26 and I have some 2.6 stuff bit size to try but we're still at 2.4 14:18:33 yboston++ 14:18:33 * yboston blushes 14:19:01 ESI has a 2.5 server that can be used for updating docs 14:19:15 Eventually they can provide a 2.6 test server 14:19:27 eeevil: will sign off... trying to figure out how, i haven't used git much lately 14:19:46 yboston: the Sitka 2.6beta server can still be used at the moment 14:19:46 gotcha...I could start with that then... 14:19:49 yes, the ESI test server will be upgraded for 2.6 14:19:58 akilsdonk: cool 14:20:47 so should those that can commit to the July 1st deadline add ourselves to one of the wiki pages, then we can start assigning stuff to ooursleves or each other? 14:21:07 Let's start with the 2.6 wiki page to make sure those features are done. 14:21:07 I can focus on old stuff with abother volunteer 14:21:23 *another 14:21:30 yboston: I can help you 14:21:50 I think people should claim features to document by either adding their name next to the feature on the TODO page or emailing the DIG list (if they don't have a wiki account) 14:21:52 dluch: thanks 14:22:06 here's the current TODO page: http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:2.6_needs 14:22:09 yboston, dluch: I can help too. Maybe one of us can be revising and one can be looking for missing stuff? 14:22:11 BTW, I can provide wiki accoutns for anyone that wants one 14:22:33 when is the 2.6 server going to be available? 14:22:38 I'm curious about documentation for WCAG compliance. Is that something that needs to be documenated or is it something that should just work? 14:22:43 * rfrasur reads up to make sure she didn't miss it. 14:22:47 sounds like we have a "Focus on older docs needs" team forming 14:23:15 so far I have dluch , kbutler , yboston for older stuff 14:23:25 which should be fine 14:23:54 yboston, I can still work on this: https://bugs.launchpad.net/evergreen/+bug/1294269 14:23:54 Launchpad bug 1294269 in Evergreen "Small documentation formatting bugs" (affected: 1, heat: 6) [Low,New] 14:24:21 and this: https://bugs.launchpad.net/evergreen/+bug/1294299 14:24:21 Launchpad bug 1294299 in Evergreen "Small documentation punctuation bugs" (affected: 1, heat: 6) [Undecided,New] 14:24:36 tonyb_ohionet: yes, continue with that, then maybe when you are done you can choose to switch to newer stuff, or do older stuff 14:24:43 kmlussier: I'd say we should mention WCAG compliance somewhere, but I don't think it needs any configuration 14:24:48 OK.....thanks! 14:25:19 kmlussier: for WCAG compliance, there is nothing to document for end users. I'm not sure if there is information about the code that might be helpful to include in the technical docs though. 14:25:53 so before next meeting, all who are willing should assign themselves to a feature or two on the TODO list 14:25:57 It might be useful to add a sentence to the tpac documentation that it meets WCAG guidelines. One we have end-user tpac documentation, that is. 14:26:06 so for new features I see remingtron , kmlussier , and I think one mroe person that I am missing 14:26:07 if you get stuck or find it's harder than you expected, just email the DIG list and ask for help 14:26:18 * jl- Benjamin Wiens, Keystone Library Network -- sorry was in a meeting 14:26:24 jihpringle for new features 14:26:27 reading backlog 14:26:37 remingtron, are we only focusing on 2.6 ...or 2.5 needs as well? 14:26:43 Welcome jl- ! 14:26:45 perhaps, we want to temporarily ignore old stuff and attack the 2.6 stuff to destroy our July first deadlien? 14:26:52 +1 14:26:57 yboston: yes, +1 14:26:59 +1 14:27:17 +1 14:27:24 jl-: welcome, here is the agenda http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:dig_meeting_20140410-agenda 14:27:40 jl-: we are talking about Remington's proposal 14:28:19 sounds like we agree to the July 1 deadline for documenting all new 2.6 features 14:28:19 though tonyb_ohionet is already looking at some older stuff that will server to give him expereince, so perhaps he can continue that 14:28:29 or not 14:28:50 remingtron: yes, I think we agree 14:28:54 I will be glad to help in anyway....I'll tackle the two bugs that yboston and I were working with... 14:28:56 yboston, remingtron thanks 14:29:09 kmlussier: +1 to a quick sentence about WCAG, that will help answer questions from sites evaluating Evergreen for compliance purposes 14:29:17 * yboston needs to look up meetbot syntax 14:29:40 dbs: Good point. 14:29:48 yboston: http://wiki.evergreen-ils.org/doku.php?id=community:using-meetbot for many of the basics 14:29:51 #agreed DIG will document all new 2.6 features by July 1, and all new future version features by the time the version is released. 14:30:21 sorry I meant in my own meetbot cheat sheet 14:30:48 ah :-) 14:31:42 #action DIG members will sign up for what features the will work on for July 1st on the DIG EG 2.6 to do page 14:31:54 #link http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:2.6_needs 14:32:04 jeff: gracias 14:33:14 should we set up some milestones for our next meeting or some time in the fututre? 14:33:19 will someone (with git access) be collecting the docs? 14:33:31 remingtron++ #For helping us focus. 14:33:33 I would submit new docs to the mailing list 14:33:47 then one of us that has git access can then add them 14:33:58 kbutler: A number of us have git access and can put them in a working branch if you send them to the mailing list. 14:34:05 that is only my suggestion, other may think otherwise 14:34:11 *others 14:34:17 That's fine. Just wanted to confirm. :) 14:34:34 yboston: +1 14:34:45 kbutler: no problem 14:34:54 yboston: what kind of milestones did you have in mind? 14:35:16 I meant something like... 14:35:33 by next week DIG memebres should pick what new feature 14:35:42 they want to work on 14:35:45 I think that's a good idea. 14:35:52 +1 to picking a feature 14:36:22 +1 14:36:28 +1, maybe with an email reminder in a few days 14:36:47 and only pick as many as you can finish before next meeting (in 1 month) 14:37:03 (so next meeting is also a milestone) 14:38:06 +1 to everyone thank you1 14:38:09 you! 14:38:10 we can also try pairing up the first month, so two people collaborate to get a few features done after oen month 14:38:15 so we get used to the process 14:38:41 For example, at the conference I was looking at the "striped" payments feature with Alexey, and we did not know in what section to add the docuemntation. we wanted to reach out the the developer but ran out of time 14:38:44 sounds great, I'm happy to help someone 14:39:21 and asking the developers is a great idea too. they can explain more about their features. 14:39:22 I'm happy to pair up with someone too. 14:40:15 who wants a DIG partner for this round of features? 14:40:20 I'm currently in the process of migrating 18 libraries (for test purposes) from voyager -> eg, so I'm hoping I can add something about migration or voyager specific migration at some point. migration seems to be rather undocumented (because ILS.* are unfortunately so different) 14:40:32 I always want to ask developers where they envisioned the documentation living, in case they had thought about it. it can be tricky deciding in a vacuum if it should be in admin settigns or in OPAC settings, etc 14:40:44 hence why I suggest teaming up for the first month 14:41:17 yboston: devs might not be the best people to ask about where docs should live; different mindsets 14:41:36 yeah, broader structure of the docs is an ongoing question, but I'm happy to work on that 14:41:47 dbs: absolutely, but I would always like to ask them in case they had thought about it. if not that is fine 14:42:11 fair enough! just keep in mind what we/they think might be wrong :) 14:42:31 jl-: I had talk about having a multi ILS "rosetta stone" wiki pages for that type of thing 14:42:41 jl-: yes, migration docs could be handy, take good notes! 14:43:06 alright, should we keep moving in the agenda? 14:43:27 +1 14:43:31 before we do do we want to agree to a simle milestone about signing up AND/or signing up in pairs the first month? 14:43:34 I need to leave in about 10 minutes. 14:43:49 related reminder, anyone writing asciidoc should look at our style guide (and offer edits!) 14:43:49 kmlussier: OK 14:43:49 http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:dig_style_guide 14:44:57 would it be easier to just sign up, and if you see only one person is on a feature, add yourself and contact them? 14:45:18 rfrasur: that sounds fine to me 14:45:23 yboston: Sorry, I'm confused. The milestone will be to sign up/team up in the first month or to sign up, team up, and then have that done in the first month? 14:45:52 dluch: I think sign up in the next week, then have first assignments done in a month 14:46:04 Done by the next meeting. 14:46:07 I was leaving open ended for the group to decide 14:46:18 There don't honestly seem to be that many features needed for 2.6...unless I'm completely misunderstanding. 14:46:42 rfrasur: So that should make it that much easier to have all of them documented. :) 14:46:51 should we count 2.5 new features that haven't been documented as well? 14:46:56 okay...so I'm not misunderstanding? 14:47:00 this is a release with few features, which makes it perfect to tryt his approach out 14:47:00 kmlussier++ 14:47:10 let's do 2.6 first and if we get done early, worry about 2.5? 14:47:19 kbutler: +1 14:47:22 rfrasur: more might appear, and some might be harder to document than expected 14:47:24 +1 to that 14:47:25 I would prefer to get the 2.6 ones done first before we tackle 2.5. To keep us focused and hit that deadline. 14:47:51 remingtron: that's my concern. Certain features require individuals with specific knowledge sets to work with them. 14:47:55 remingtron++ #some of those few ones could be doozies 14:48:03 FWIW, I haven't done my usual scan of the Change Log to see if there are any new features missing from the release notes. I know yboston was looking at it, but I don't know how far he got. 14:48:29 kmlussier: not far at all 14:48:43 but I started docuemnting your process at least 14:48:48 kmlussier: I started with things already in RELEASE_NOTES_NEXT and have been scanning launchpad committed bugs for 2.6 14:48:49 And I'm curious if it'd be a good idea to seek out those people that know how to use the features...or at least get started...and have them participate in the documentation, if they're willing, even if they don't traditionally participate in DIG 14:48:58 yboston: OK, then. I will commit to doing that within the next week too. Sorry, I was distracted for a few months, but I have time to focus on DIG again. 14:49:21 so it sounds we want to start with the 2.6 list as it is 14:49:38 rfrasur: yes, users and developers are welcome in the conversation, good ideas 14:49:57 lets sign ourselves up for a few of them, while working in pairs 14:50:06 kmlussier: you've had a lot on your plate! 14:50:15 That's one of the reasons why I threw out the "Update Expire Date" button as a possible option for someone new. It should be one that doesn't require specialized knowledge. 14:50:16 and shoot for completing in one month 14:50:26 kmlussier++ 14:50:27 My personal concern is that no matter how much I WANT to help, if I don't have any clue how to use a feature, I sure can't document it. 14:50:32 I've seen it, and once you click the button, you know what it does. 14:50:37 and if anyone gets stuck, just email the list or ask on IRC for help 14:50:47 yes, and perhpas when kathy does her releaso notes review, we might end up with newer features 14:51:03 rfrasur: Also, if you can find the LP bug where the feature was originally posted, there often is a lot of information on how it works. 14:51:29 kmlussier: good idea, let's add links to the TODO page as appropriate 14:51:37 kmlussier++ #yeah 14:51:39 btw, we are almost at the 1 hour mark. 14:51:47 remingtron++ #that'd be very helpful. 14:52:23 remingtron ++ 14:52:56 lets shoot to sign up for features by Esrly next week? I will pick one tht has someone already signed up 14:53:26 yboston: will you also send out an email reminder tomorrow or Monday? 14:53:29 BTW, we might want to ignore the ones with ESI lsited, since they might already have direct access tot he specs and the developers, so they might not need to pair up??? 14:53:36 I can send out the reminder 14:53:48 ty, and +1 on the ESI features. 14:53:51 yboston: I agree, ESI does a fine job with their docs 14:54:52 #agreed If DIG finisshes all of the 2.6 todos, we will shift to the 2.5 missing features 14:55:12 * kmlussier needs to run. 14:55:15 Bye all! 14:55:15 I also wanted to have a quick chat about release ntoes, but I will do that in the mialing list. 14:55:22 kmlussier: bye, thanks! 14:55:30 kmlussier: bye! 14:55:33 any final comments or questions as we approach the 1 hour mark? 14:55:41 yboston: one question 14:55:56 will the "work on old stuff" team be working in the background, or also focusing on 2.6 first? 14:55:57 (btw, I can keep going longer) 14:56:26 I would want to try focusing on 2.6 just so that we all get experience 14:56:42 on DIG practices, AsciiDoc, etc 14:56:50 sounds good to me 14:56:53 but we can choose to work in parallel 14:57:39 Good day everyone, I have a conundrum that I could use some input on. 14:57:56 * rfrasur listens 14:58:01 shart290: if you are willing to wait a moment, we are just finishing a meeting 14:58:03 I think 2.6 first is fine with me. 14:58:13 absolutely. thank you 14:58:19 shart290: give us a couple of minutes 14:59:00 so lets start signing up in pairs (or more) and lets tlak on the mailing list if you have questions, of just email me directly and I will point the way 14:59:10 +1 14:59:10 including helping phrase questiosn for the develoeprs 14:59:15 +1 14:59:19 +1 14:59:35 yboston: and you will email the list about your Release Notes topic? 14:59:41 yes 14:59:51 jsut added it to my calendar 15:00:16 any final questiosn or comments? 15:00:18 great, thanks 15:01:01 also, remeber, let me know if you need me to "sign" you up for features ont he wiki or ask me directly for wiki access 15:01:14 anything else? 15:01:40 next meeting should be (if we keep same schedule) May 1st 15:01:52 (and we can change schedule if we want) 15:02:04 OK, if there is nothing lese, I will stop the meeting 15:03:05 #endmeeting