14:15:57 <yboston> #startmeeting DIG Monthly Meeting Evergreen Documentation Interest Group (DIG) Monthly Meeting.
14:15:57 <pinesol_green> Meeting started Thu Aug  6 14:15:57 2015 US/Eastern.  The chair is yboston. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:15:57 <pinesol_green> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:15:57 <pinesol_green> The meeting name has been set to 'dig_monthly_meeting_evergreen_documentation_interest_group__dig__monthly_meeting_'
14:16:17 <yboston> The agenda can be found here http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:dig_meeting_20150806-agenda
14:16:28 <yboston> #topic Introductions
14:16:36 <yboston> Please feel free to start introducing yourselves...
14:16:46 <yboston> #info yboston is Yamil Suarez @ Berklee College of Music - DIG meeting facilitator
14:17:01 <Stompro> #info Stompro is Josh Stompro @  Lake Agassiz Regional Library MN
14:17:18 <remingtron> #info remingtron is Remington Steed, Hekman Library (Calvin College)
14:19:09 <yboston> OK, I think I wil start now or shoudl we cancel if no one else shows up?
14:19:33 <kbutler> #info kbutler is Kate Butler, Rodgers Memorial (Hudson, NH)
14:19:43 <remingtron> welcome kbutler!
14:20:00 <yboston> lets begin
14:20:31 <yboston> not sure in kmlussier is around, so for now I will start with
14:20:33 <yboston> #topic last meeting's action items
14:20:37 <kmlussier> I'm here
14:20:43 <kmlussier> #info kmlussier is Kathy Lussier, MassLNC
14:20:49 <yboston> nice
14:20:58 <yboston> #info 1) Stompro will follow up with krvmga on Added Content documentation
14:21:13 <Stompro> I sent Jim an email and he said he didn't have any outstanding docs.
14:21:22 <yboston> OK
14:21:30 <Stompro> So I'll move forward with the items I took over from him.
14:21:42 <yboston> excelent
14:21:52 <Stompro> When I have a chance, we are getting into the mapping/library settings phase of our migration, so I have less time.
14:22:07 <kmlussier> Fun!
14:22:24 <yboston> shoudl I add an action item like: #action Stompro will continue working on Added Content documentation additions
14:22:35 <yboston> ?
14:22:35 <Stompro> He did give me some Novelist Select setup instuctions that Might fit into the added content section.
14:22:56 <Stompro> I don't think it needs an action item, I've got it marked off on the documentation needs page.
14:23:00 <yboston> OK
14:23:03 <yboston> moving on
14:23:11 <yboston> #info 2) kmlussier will complete the marc stream importer work and check on the status of the RDA docs
14:23:56 <yboston> I can postpone for next meeting
14:24:03 <kmlussier> #info kmlussier has started the marc steam importer docs
14:24:14 <yboston> kmlussier++
14:24:15 <kmlussier> Progress
14:24:38 <remingtron> kmlussier++ #progress!
14:24:47 <kbutler> kmlussier++
14:24:48 <yboston> should I post the sae action item?
14:24:48 <kmlussier> At this rate, they might be done by 2020. :)
14:24:56 <kmlussier> Yes, please do.
14:24:56 <yboston> *same
14:24:59 <yboston> OK
14:25:18 <yboston> #action kmlussier will complete the marc stream importer work and check on the status of the RDA docs
14:25:30 <yboston> #info 3) remingtron will send out an email to the Dig list anouncing that a new file extension will be used for AsciiDoc files
14:25:38 <remingtron> I was made aware of a possible problem with the way git tracks history when a file name changes. So I want to test that before any more public announcements.
14:25:47 <yboston> interesting
14:26:16 <yboston> I understood that it usually catches name changes
14:26:23 <remingtron> don't want to mess up git history too much, especially for a non-essential change
14:26:28 <kmlussier> I added a release notes entry with the adoc extension yesterday. But Stompro noted that an update needs to be made to the script that generates the release notes.
14:26:30 <yboston> let me know if I can help
14:26:34 <remingtron> git does catch name changes, but it doesn't show history nicely
14:26:45 <yboston> oh
14:26:54 <yboston> good to know that now
14:27:01 <kmlussier> We'll need to make sure that gets done before the release notes are generated for 2.9. Or we'll have to make sure we stick to the txt extension on those for now.
14:27:34 <remingtron> kmlussier: sounds like we just need a LP bug for that?
14:27:37 <yboston> any volunteers for reachign out to Robert?
14:27:46 <kmlussier> Yes, +1 to LP entry
14:27:55 <kmlussier> yboston: That's not a Robert thing.
14:28:11 <Stompro> New docs can at least start using .adoc, even if the full conversion is spaced out.
14:28:11 <yboston> sorry, misunderstoofd
14:28:28 <kmlussier> The script was originally created by miker and is usually handled by the RM. But anybody could update it. It's in the release notes next directory.
14:28:37 <yboston> yes, LP bug should help get things started
14:28:42 <Stompro> I can create the LP bug.
14:29:11 <kmlussier> Stompro++
14:29:24 <yboston> I have been meaning to learn how to build release notes. I will look at it in case it is a simple fix
14:29:24 <remingtron> thanks Stompro
14:30:02 <yboston> #action Stompro will create LP bug for teaching the release notes creation bacth file(s) to handle .adoc file suffuxes
14:30:25 <yboston> (sorry for my spelling, when I type fast)
14:30:53 <Stompro> I'll do it in a few minutes, no need for an action item...
14:30:53 <yboston> anything else on this issue/topic before me move on?
14:31:08 <remingtron> Stompro: you're that much more ahead on next meeting :)
14:31:36 <yboston> moving on
14:31:49 <yboston> #info 4) remingtron will begin testing use of and conversion to the .adoc extension
14:32:07 <yboston> is there more to say about this?
14:32:25 <remingtron> not yet, I'll keep working on it
14:32:35 <yboston> no problem at all
14:32:38 <yboston> remingtron++
14:32:42 <yboston> moving on
14:32:47 <yboston> #info 5) kmlussier will send out an email to DIG list to request updates on unfinsished 2.8 new features
14:33:09 <kmlussier> Hmmmm
14:33:12 <yboston> also related to this
14:33:13 <yboston> #info 6) kmlussier will follow up with direct emails to request updates on unfinsished 2.8 new features or to ask for works in progress
14:33:25 <yboston> I can postpone
14:33:46 <kmlussier> Sorry, I can do that today.
14:34:10 <yboston> I can repost so you are a head for next week :)
14:34:17 <yboston> sorry, next month
14:34:39 <yboston> #action kmlussier will send out an email to DIG list to request updates on unfinsished 2.8 new features
14:34:45 <yboston> #action kmlussier will follow up with direct emails to request updates on unfinsished 2.8 new features or to ask for works in progress
14:34:57 <yboston> should I move on?
14:35:02 <kmlussier> sure
14:35:06 <yboston> OK
14:35:12 <yboston> #info 7) yboston will move the undocumented content of the 2.8 new feature “TPAC Discoverability Enhancements” to its own section in the docs
14:35:25 <yboston> I started workign on this, but not done
14:35:53 <yboston> I came up with three possible locations, and I emailed dbs today to ask his opinion in case he had any ideas
14:36:37 <remingtron> yboston++ #progress!
14:36:48 <yboston> the locations are 1) "Using the Public Access Catalog" 2) developer resoruces, where we might encourage developers to keep addign support
14:36:57 <yboston> 3) As an appendix to
14:37:02 <yboston> the whole manual
14:37:03 <Stompro> yboston++
14:37:12 <yboston> I will psotpone for next meeting
14:37:39 <yboston> but let me know if you have anythoughts right now off the top of your head
14:37:43 <yboston> #action yboston will move the undocumented content of the 2.8 new feature “TPAC Discoverability Enhancements” to its own section in the docs
14:38:20 <remingtron> yboston: I think I'd vote for 1), without looking into it
14:38:45 <yboston> thanks, that is all I wanted for now
14:38:58 <yboston> moving on
14:39:06 <yboston> #info 8) remingtron will contact Robert Soullier about updating the docs sites to match the footer of the regular EG site; also to add the CC icon
14:39:13 <remingtron> done!
14:39:19 <yboston> nice
14:39:23 <remingtron> #info See the new footer at: http://docs.evergreen-ils.org/
14:39:30 * kmlussier agrees with remingtron on location for schema.org docs
14:39:41 <yboston> kmlussier: thanks
14:39:43 <remingtron> rsoulliere++ (spelling?)
14:40:32 <remingtron> Robert changed the footer for docs version 2.6+, since those are the current supported versions
14:40:39 <yboston> cool
14:41:15 <yboston> rsoulliere++   (I looked up spelling)
14:41:25 <kmlussier> rsouilliere++
14:41:25 <yboston> moving on?
14:41:44 <yboston> #info 9) kmlussier will add an agenda item tot he web team about updating the doc site footers to match the main site footer, as well as include the CC icon
14:42:12 <kmlussier> Done
14:42:28 <kmlussier> The web team didn't think it was critical for the two footers to match.
14:42:28 <yboston> cool
14:42:38 <yboston> OK
14:42:42 <kmlussier> They had one request to update the copyright date in the docs footer, but it looks like that happened.
14:43:04 <kmlussier> We're also looking to add the CC licensing for the web site contact, but gmcharlt and I first need to do some work to reach out to content creators for the WP site.
14:43:16 <kmlussier> Ugh. Not web site contact. Web site content.
14:43:53 <yboston> OK
14:44:09 <yboston> anything else?
14:44:23 <kmlussier> nope
14:44:25 <yboston> menaing, comments from someoen else or quesitons
14:44:32 <remingtron> nothing from me
14:44:36 <yboston> OK
14:44:40 <kbutler> I'm good.
14:44:48 <yboston> that is the last of the previous meeting action items
14:45:36 <yboston> on the agenda we have various topics that we can discuss
14:45:37 <yboston> http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:dig_meeting_20150806-agenda
14:45:51 <yboston> web client docs, re-org, etc
14:45:57 <yboston> any requests?
14:46:07 <remingtron> how about 2.8 progress?
14:46:22 <remingtron> I'd like to discuss how we might push things forward to completion
14:46:27 <remingtron> thoughts?
14:46:32 <yboston> good topic
14:46:58 <remingtron> (I don't mean make people feel bad who signed up for something and haven't done it, but I do mean following up when necessary)
14:47:43 <yboston> we have plans to have kmlussier reach out
14:48:04 <remingtron> yes, kmlussier's coming emails are certainly the right idea
14:48:14 <Stompro> How would people feel about adding the date next to their name when they sign up for an item, so it is easy to see which items are over 6 months old, and probably not being activly worked on?
14:49:10 <remingtron> my hope is that we can find an effective way to finish up the last 10% of each version
14:49:13 <kmlussier> Yeah, there are just a handful of items. Two of them are mine, but I have a working branch that is partially completed.
14:49:33 <kbutler> I think one of them is mine.  I should finally have time to work on it in the next week or two.
14:50:10 <yboston> when we get to the that last 10%, I guess we can get more veteran volunteers
14:50:15 <yboston> to offer to take over
14:50:17 <remingtron> kmlussier and kbutler: thanks to both of you!
14:50:31 <yboston> for the folks that are not done, or at least help them finsish up
14:51:07 <remingtron> yboston: that's what I'm wondering, how we can make this a more collaborative project so it's easy to help out a little here and there
14:51:18 <remingtron> it seems GitHub could facilitate that well
14:51:47 <yboston> I defiently see Gists helping
14:51:48 <remingtron> kmlussier: can you easily push your working branch to github for collaboration?
14:52:00 <kbutler> I would definitely like to get more comfortable using GitHub.
14:52:02 <kmlussier> I could push it to the working repository
14:52:15 <remingtron> or should we declare that the master repo is open for such half-finished work?
14:52:30 <yboston> I just started experimenting pushing a copy of EG git repo on Github so I can store works in progress
14:52:38 <yboston> I can share my notes with folks
14:52:46 <kbutler> yboston that would be great
14:52:51 <kmlussier> To be honest, I'm going to be working a lot on billing docs through the end of the month anyway, so it's just as easy for me to finish them up at this point.
14:53:15 <remingtron> if we just use the master repo, then people can easily "fork" the repo, make their edits, and make a pull request even if their work isn't done
14:53:23 <kmlussier> Is there a reason we would be pushing those to GitHub instead of the working repository? For those of us who are already comfortable with pushing branches there?
14:53:35 <Stompro> What about public gists for collaboration?  Maybe just include links to the gist from the documentation needs page?
14:53:49 <yboston> Stompro: I was just thinking that
14:53:54 <remingtron> kmlussier: I'm mostly thinking of those not comfortable with git
14:54:01 <kmlussier> Ah, ok. That makes sense
14:54:05 <remingtron> so a web-only interface would be beneficial
14:54:34 <yboston> I was just working with Carole from Bibliomation by sharing both a public and a private Github Gist
14:54:42 <yboston> to fix some issues she had
14:54:45 <yboston> went well
14:55:27 <remingtron> Stompro: gists could work; it leaves a little more work for whoever pushes it into the master repo, but it's an improvement on our current process
14:56:08 <yboston> I do like the idea of havign folks post a link to a Gist at the end of a DIG hackfest or hack-a-way
14:56:17 <yboston> so that we get at least a quick snapshot of
14:56:22 <yboston> where people left of
14:56:26 <yboston> off
14:56:47 <remingtron> yboston: yes, great idea
14:56:48 <yboston> or even a Google Doc link
14:56:54 <yboston> Stompro++
14:57:09 <remingtron> also, I'd like to formally propose that we ask the Dev list if we can use the master repo docs folder for work-in-progress, with the promise that it will be nice before a version is released
14:57:31 <remingtron> I think that would allow us more freedom for using GitHub for collaboration
14:57:35 <yboston> or what about a working branch for DIG work in progress?
14:57:47 <yboston> just to offer to solutions to the devs
14:57:52 <yboston> *two
14:57:54 <kbutler> I think keeping work in progress in relatively one spot would probably help.
14:58:08 <remingtron> yboston: I don't think EG currently has working branches on github
14:58:10 <kbutler> I know when I get told 'email it, or a google doc, or github, or etc etc.' I worry which one is preferred.
14:58:44 <yboston> I meant to use a EG working repo topic branch for DIG to use
14:58:51 <yboston> with an agreed term
14:58:53 <remingtron> kbutler: we could always say "We'll take anything, but we prefer GitHub"
14:58:56 <yboston> I mean name
14:59:04 <krvmga> has anyone else experience the vertical green band on the right side of the staff client screen when looking at a record with parts?
14:59:08 <kbutler> remingtron That's true
14:59:28 <yboston> krvmga: we are havign a meeting now
14:59:38 <yboston> krvmga: give us a few minutes
14:59:38 <krvmga> sorry, back later
14:59:47 <yboston> krvmga: no problem at all
14:59:57 <remingtron> yboston: I don't quite understand your idea yet
15:00:09 <remingtron> you mean instead of github?
15:00:36 <yboston> instead of Github for those that are familiar with git and using "working"
15:00:48 <yboston> but for beguiners I support using github
15:00:59 <remingtron> yboston: okay, we are on the same page
15:01:11 <yboston> want to twam up to play around witht his
15:01:19 <yboston> ?
15:01:28 <kmlussier> remingtron: When you say the master repo docs folder, are you talking about doing it in github? Does it affect the master branch in the Evergreen git repository?
15:01:36 * kmlussier is confused.
15:01:47 <remingtron> kmlussier: yes, it's part of the normal master repo
15:01:51 <yboston> kmlussier: I beleive he means that I would need to fork the main EG repo
15:01:56 <yboston> oh
15:02:02 <remingtron> kmlussier: the only difference is some folks (like me) only have commit access to the docs folder
15:02:39 <kmlussier> I'm not sure I'm comfortable with partial docs being in the master repo.
15:02:49 <remingtron> so I just want the Dev's to approve us using the master repo in a way that we don't currently allow for code
15:03:03 <remingtron> kmlussier: any reason?
15:03:04 <yboston> keep going remingtron
15:03:51 <yboston> I am a little confused. Can you give an exampel of what John Doe the new contributor might do with Github, versus what you might do to push John's info
15:03:53 <kmlussier> Because of the likelihood they won't be done by release time.
15:03:53 <yboston> ?
15:05:09 <kmlussier> And I'm also not picturing how it helps improve collaboration on those docs.
15:05:13 <remingtron> kmlussier: I agree, we'd need a plan for anything that's really ugly, but we currently have lots of minor issues with all of our live docs
15:05:33 <remingtron> okay, here are the benefits I imagine:
15:06:07 <remingtron> John Doe can use GitHub to make even a tiny edit (like fix a typo)
15:06:33 <remingtron> GitHub makes it easy, so he clicks "Edit this file", which automatically forks the master repo to his GitHub account
15:06:45 <remingtron> he makes the change, then clicks "Create pull request" and we get an email about it
15:07:09 <yboston> oh, OK you are talking about John forking the EG master repo
15:07:11 <remingtron> Now, we can use GitHub to preview it and easily merge it in
15:07:14 <yboston> then doing a pull request?
15:07:18 <remingtron> yboston: yes
15:07:32 <yboston> sorry, for some reason I thought you meant something else
15:07:52 <yboston> We followed that worlflow already with the potential GNU interns
15:07:53 <remingtron> for bigger additions, like new files, we still have some work to do
15:07:57 <yboston> and I think Stompro too
15:08:11 <yboston> remingtron: that should handle file changes to
15:08:14 <yboston> too
15:08:27 <kmlussier> remingtron: But the way you describe it, the thing that gets merged in doesn't sound like it's partially finished.
15:09:11 <remingtron> kmlussier: I'd want even the partially finished stuff to get added this way, and hopefully the original person can keep committing parts until it's done
15:09:20 <remingtron> if they can't, then anyone else can take over
15:09:31 <remingtron> or help along the way, just like a collab branch
15:10:11 <remingtron> My main goal is to prevent stuff from stalling out
15:10:14 <Stompro> Can't anyone fork the modified branch that the user submitted as a pull request also, and continue to work on it?
15:10:40 <yboston> we could just make the user make a pull request, and that can be used to follwo up with stuff later on to finally merge it to master or release branch
15:11:03 <remingtron> Stompro: probably, so maybe we keep it in that pull request branch until it's done
15:11:23 <dbs> Why even bother with GitHub and pull request and AsciiDoc, seriously?
15:11:43 <dbs> Just let writers write and have a few Asciidoc / git-knowledgable people.
15:12:11 <dbs> In Word or Google Docs or whatever: the content is the important contribution
15:12:58 <kmlussier> I'm inclined to agree with dbs. I think it's great that we do so much work teaching asciidoc and finding ways to use github to make it easier, but I think it also puts off potential contributors.
15:12:59 <remingtron> dbs: I support that approach
15:13:08 <krvmga> i agree with dbs
15:13:29 <Stompro> dbs, that is still an optiion, and I think it gets communicated to those wishing to work on documentation.  Yamil mentioned that during the doc hackfest.
15:13:32 <yboston> on a related note, we coudl use Google Drive, so we could share partially complete asciidoc and inital screenshots. so they stay together
15:14:21 <remingtron> I guess the main thing to emphasize is "please share your work-in-progress link as soon as possible so others can help"
15:14:23 <kbutler> dbs: I think sometimes that can lead to clogs where contributions do not get added.
15:14:27 <yboston> more specifically, we should encourage a "data dump" / progress report at the end of hackfests, etc so we know where to pick up later on
15:14:36 <kbutler> dbs: It also can make it hard for people to know if someone else is working on something already.
15:16:13 <yboston> so we have reached the one hour mark
15:16:44 <yboston> so I think we all agree that we need to ask for works in progress to be stored somewhere easy for new volunteers?
15:16:46 <kmlussier> I don't see how collaborating in Google docs would make it more difficult to see if someone else is working on something.
15:17:08 <remingtron> yboston: yes
15:17:34 <yboston> kmlussier: not sure to who or what comment you are replying too?
15:18:15 <remingtron> kmlussier: the key is if people are willing to share their link
15:18:42 <yboston> remingtron: I agree that sharing the Gist, Google doc, etc  link is key
15:18:58 <kmlussier> Yes, that could be done from the wiki page where the person has added their name?
15:19:10 <yboston> kmlussier: yes
15:19:17 <dbs> kbutler: separate forks makes it hard to coordinate too, fwiw
15:19:26 <remingtron> kmlussier: yes, can you ask in your email if people are willing to share their links that way? Google doc, gist, etc.?
15:19:34 <kmlussier> remingtron: Sure thing
15:19:54 <yboston> or just habe them email their text fiels and screenshots to the list
15:19:55 <remingtron> dbs: a good point
15:19:55 <dbs> +1 link from wiki to <wherever content lives>
15:20:07 <kbutler> I'm not necessarily advocating for any particular solution, but I do think 'let the writers write wherever' has been confusing and hard to track.
15:21:13 <dbs> Right. Communication is key.
15:21:47 <dbs> Writers _should_ be able to communicate somehow, right? :)
15:21:52 <yboston> to me the most important is havign a "paper trail" of sorts to the works in progress
15:22:00 <remingtron> okay, that sounds like consensus
15:22:22 <remingtron> kmlussier will mention it in her email, and I will add such a request to the wiki page
15:22:30 <yboston> OK
15:22:45 <yboston> we shoudl wrap up, lets get final comments and quesitosn in
15:22:52 <remingtron> that's all from me, thanks all!
15:23:34 <yboston> #idea encourage volunteers to submit links to their works in progress on the relevant DIG wiki page
15:23:47 <yboston> any other "ideas"?
15:24:51 <yboston> #idea possible palces to store works in progress to allow linking back to content include: dropbox, Google docs/drive, Github forks, Github Gists
15:25:03 <yboston> anything else?
15:25:20 <kbutler> Possibly instructions for using some of said locations effectively?
15:25:29 <kbutler> Or just suggestions or something.
15:25:37 <yboston> that makes sense
15:26:08 <yboston> #idea come up with guidelines/suggestions for how to store works in progress or finsished work for DIG to access later on
15:26:36 <yboston> #idea always ask volunteers to share works in progress at the end f DIG hackfest or DIG hack-a-ways
15:26:45 <yboston> OK, I will end the meeting
15:26:51 <yboston> 3
15:26:52 <yboston> 2
15:26:55 <yboston> 1
15:27:00 <kmlussier> heh
15:27:06 <yboston> #endmeeting