2011-06-29 Documentation Meeting

Sakai Documentation Meetinghttp://titanpad.com/FocEf4Uk5e
Meeting ID: 72524                                                                                                                                                                                          
Phone dial-in: 
310-506-6992 (Main)

ATTENDEES:

• Alan Regan, Pepperdine
• Mathieu Plourde, Delaware
• Elizabeth Venstra, Indiana
• Rebecca Darling, Wellesley
• Jonathan
• Matt Clare
• Jim Mezzanotte
• Roger Brown, Cape Town
  AGENDA:
• Status of page suggestions / edits
• How is the Google doc working for everyone? Problems, issues?
• Deadline
• Longsight volunteers server for hosting a help file editor for future edits
• https://sakaihelp.longsight.com/
  NOTES:
  Proofreading by IU
  comfortable with at least 3 days
  Longsight editor is a content management system; only one editor at a time. - Hosted in Drupal
  Short-term goal:
  Alan has been making progress--first handful of pages
  Everything under the hood is proprietary coding for IU, but served as XML (the XSL translator swaps out correct versions of pages)
  "Note: To complete these procedures, you must be assigned..."
  Matt Clare: at his institutions, they replace that boilerplate and add floating text box to top right with picture of permission checkbox, to clarify you need to have x permission.
  the boilerplate is necessary . . . need to apply it more consistently in every document where it's relevant  - If you see it missing on a page where it's relevant, put a note to add it, or add it.
  Is the boilerplate there to help understand why you can't do something vs. helping someone figure out how to get themselves the permission?
  flag on boiler to display or not; in a sense this is already there . . . if an institution has its own XSL set up, it could have it excluded (OOTB help does not do this)  Repository is available to whoever has a key.  Can apply style sheet, branding, etc.  The problem is that most institutions don't have resources to maintain this.  Need server, someone to maintain, etc.  Sakai pulls it across (Stephen Marquard) as one canonical version.  If you set up your own version, you could get it dynamically (not cached as in OOTB version).
  This can be a lot of extra work. Many schools don't have the resources for this. Would be better if it could be managed centrally by a tool which can be used to select which help components you would like to use.  The issue is having someone own it.
  Jonathan will write something up to make this clear.  
  Need: 1) how it is working now and 2) vision of how it could work--clear distinctions between the two.
  Longsight as possible host?? prototype for editing is up, but not for branding 
  Help should support customizations, but also facilitate re-using documents common for all
  By Friday morning (9am Pacific, 12pm Eastern), July 1st, begin marking pages as approved and ready to go, so Elizabeth's team can start reviewing them. 
  A few people working on site info, other people could work on groupings for other help tools. 
  Suggestion to organize grouping work: Page in Confluence (or Google docs) with full list of tools, column for volunteers, column for comments, 
  IU will start making the changes in the official docs and mark the google doc when they've finished reviewing it. Then it will be considered 'locked' (<-- is that accurate?) Well, at least, after that point, maybe contact me (Elizabeth)?  (consider it a soft lock)
  Site Info = 20pgs -- 18pgs + 2 new (Parent Site & Import from Archive)
  Import from file--list of what can be imported?
  disclaimers--can import bb 6/later versions may or may not work, something like that?  Alan will email dev list to check on this  (no mention of this in last 4-5 months on dev list)
  Table "Menubar" label discussion for now. this language permeates all the Help documents. More community input/concerns. 
  If you find "menu bar" instead of menubar or it refers to something else other than the list of tools on the left, flag it and send it to Elizabeth
  when thinking about new possible solutions: will the system help you do the kinds of things we've talked about today?  (treat the things we've talked about as use cases)
  Make mediocrity our goal!
  Set our sights for making things better.
  Set our sights for making things better "Alan Regan" :)
  Jonathan will identify which tools are in the help files if people have extra cycles to work on the groupings - will be set up in a google doc for people to claim

Thank you everyone for attending today's meeting!

ACTIONS:
1.) Jonathan Bolte will summarize the existing system (including the XML/XSL process)
2.) Writers and proofreaders will sign up on the GoogleDoc to edit or review pages
3.) Site Info deadline is Friday, noon Eastern time for edits. (Note: can continue to work on other pages Tuesday or Wednesday.)
4.) Jonathan Bolte will check with IU trainers and identify the language that they use for the left-hand menu and tool submenu, etc. To identify if a change of "menubar" may be possible/recommended.

DECISIONS:
1.) Discussion of "menubar." Decision to defer until more info available. The term "menubar" can be confusing to end-users, since so many options. (Another option is to update the "Menubar: Overview" page and provide better clarification there...)
2.) Boilerplate on permissions should be consistent. If we find pages that should have this notice but don't have it, be sure to make a note at the top of the page for Elizabeth's team (e.g. [PERMISSIONS BOILERPLATE HERE] )

GENERAL AGREEMENT:
1.) We have a need for a solution to allow institutions to customize documentation, by identifying tools they are using, rename tools, brand the institution, etc. A way to tag, flag, and/or code elements (such as tool names, system name, or boilerplate notices) so that schools can pick what they use and the system will generate customized XHTML or RTF (?) output files for repurposing.