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. Introductions: paste ”/me is <name> <affiliation>” to identify who you are and what organization, if any, you represent
2. Updates from Content Coordinators
3. Old Business
   1. Think of ways to increase participation, create an informal survey, training during a DIG hack-a-way, or online DIG training sessions between conferences (by Yamil)
      1. brainstorming on survey draft (Yamil)
   2. Including technical information in end-user docs - http://markmail.org/message/twcwas7r4yuavxcq (by Kathy)
   3. Yamil's DocBook to Asciidoc conversion project (by his intern)
      1. needs help proofreading
      2. track progress in the bottom section of Evergreen 2.5 Documentation Needs
   4. Post conference DIG hackfest discussion
      1. remaining work to be finished
      2. ideas for next year's conference
   5. Reminder to use (and keep improving) the DIG AsciiDoc Style Guide
   6. Discuss if we should pick a new monthly day and time for DIG to meet (Yamil)
4. New Business
   1. Early plans for updating documentation for new web-client (Yamil)
   2. Proposed goal (by Remington): Document all new 2.6 features by July 1, and all new future version features by the time the version is released.
      1. We could accomplish this by adopting a simple workflow, where each active DIG member commits to document 1-3 features per month (from a list like the 2.5 needs list) and report on progress at each monthly meeting. We may also want to meet more frequently (twice a month?).
      2. I have created a draft of a 2.6 Docs Needs page.
      3. To ease the burden on us and improve speed and understanding, we should partner with the developer(s) of new features as much as possible.
      4. All older features that need to be documented should be part of the DIG workflow too, but maybe secondary. Perhaps when an EG version begins the Alpha phase we shift focus to new features until the final release, and then we shift focus back to older features that need work.

Next Meeting: TBD