This meeting will be held on the #evergreen channel on the Freenode IRC network (http://evergreen-ils.org/irc.php) beginning at 2:00 PM EST. Current and future DIG participants are encouraged to attend, and any interested members of the Evergreen Community are welcome as well. For updates, notifications, and discussion please sign up for the Evergreen Documentation Discussion List.

1. Volunteer to Take Minutes?
2. Introductions: paste ”/me is <name> <affiliation>” to identify who you are and what organization, if any, you represent
3. Updates from Content Coordinators
4. Old Business
   1. Interest in starting an "official" and actively maintained list of things (software, hardware, etc.) compatible with EG? Policy for managing the list?
      1. Jason sent an email out: http://georgialibraries.markmail.org/thread/vd5nfg75fiyeu22o
5. New Business
   1. Discuss what DIG thinks the role of the DIG release coordinator should be (suggested by Tim Spindler)
   2. DIG recap of Evergreen conference
   3. Brainstorm ideas for next conference (proposed by Yamil Suarez)
   4. Documentation merged with the code repository: what that means! (proposed by Dan Scott)
      1. The DIG master branch (representing Evergreen 2.2 docs in Asciidoc) was merged with the code master branch (representing 2.3 development branch):
         • Advantages (in theory):
           1. Release notes and installation documentation is now truly single-sourced!
           2. Users get a complete copy of the documentation when they download the source, and can build their own HTML / PDF / ePub versions!
           3. There's a slightly better chance that developers will contribute directly to the documentation when they add features or change functionality!
           4. DIG committers (Robert, Yamil, others?) have the ability to commit directly to the "doc" subdirectory of the code, and can use the same "working" repository for staging branches, etc, as the rest of the development team ("one big team!")
         • Thoughts:
           1. The DIG commits going forward probably should use the same sign-off conventions and commit message conventions as the rest of the code
           2. Once the 2.2.0 release is cut, we should merge the Asciidoc changes into the code rel_2_2 branch so that we can maintain the 2.3 docs separately from the 2.2 docs
           3. The DIG DocBook branches (2.1, 2.0, 1.6) are still maintained in the DIG repository, so any doc changes targeted at that level of docs needs to be committed there, until those releases fade away

Next Meeting: TBD