Below is draft planning outline for approval. Teams, schedule and approach TBD.

I. Overview

OLE requires committed SMEs to complete User Documentation for all modules and all features delivered in the application, leveraging those SMEs with knowledge of the specifications, iterative code-reviews, and user-testing.
Training, checklists, and best practices will be shared among all Module SME team representatives, and the to-be-formed User Documentation team.
User Documentation should be developed in tandem with release, and completion should closely follow a scheduled milestone or product release (see timelines-with some variation for milestone releases, depending on FC/PM decisions for support, schedule)-- progressive completions in tandem with coded features.

Item	Purpose	Audience	Owner	SME Contact	Notes
Overviews / User Documentation	Broad overviews explaining the features of each module. Provides notation for where users can customize (Think story format; descriptions of how to do library tasks and overviews of each module)	All users of the software: Hands on users Partners	Nora Jain?	One per module	Jira passed to SMEs; due 1/31/2013
Technical Documentation	Provide information about the technical processes of OLE. This explains how a core feature is designed and built. This is of importance to core contributing developers and others who may want to extend a feature and how a core feature can be used by an application developers.*	Library IT System Admins Those localizing OLE	HTC Technical Council	Technical Council?	Do we have someone specific leading this?
Release Documentation	Provide detailed information about the changes and/or enhancements of each release of OLE. (Think what has changed; how it has changed. This will be a basic technical overview for functional users and SHORT!)	All users of the software: Hands on users Partners	Nora?
Online Help and "Big Book of OLE"	First line of reference when users have a question as they're using software. Provide look-up within the OLE system and details of the functions available within OLE. This will be very detailed and contain explanations of each OLE screens.	All users of the software: Hands on users Partners	Jain? Nora	Same SMEs as for Overview Documentation	Working to determine which online help product to use. Continuing on the Big Book
Start-up guide	Provide instructions for how to set up and configure OLE. (Import patrons, bib data; set up chart of accounts, etc.)	All users of the software: Hands on users Partners Library IT System Admin	Technical Council?		Kathy started CoA, already in Google Docs; Documentation in planning

* Taken from https://wiki.kuali.org/display/KULRICE/Documentation+Policy

II. Outline: Content & Teams

For the Overview Documents, each Jira has an attached outline.
For the Big Book, the outline is below files in the User Documentation Sandbox

III. Timeline

Establish documentation timetables as offsets to Release Dates, for each deliverable or assignment
1. Begin user documentation
  1. Sketch outlines: develop in tandem once specs 50% complete
  2. Sketch content: Spec completion/signoff + 1 week
  3. Drafting content: in tandem with code/development and iterative code reviews; should be able to complete outline and some content
2. Draft #1 user Documentation: within 2 weeks of sprint release for coded feature
3. Draft #2 user documentation: Within 2 weeks after release of final code for features, or Release overall
4. Format Review copies due: Draft #2 date + 2weeks (time consuming)
5. Initial QA Review due: Format Review Date + 1 week
6. Final due: Initial QA date + 2 weeks
7. Publish due: Final date + 1-2 weeks
Add 10% + contingency to Draft #2/Format Review dates (ie, some code won’t be completed until just before release)
Create Documentation calendar for each Release, with above offsets for global release
1. Publish within 2-10 weeks of Release date (TBD with PM, depending on type of release, complexity, available resources)
Coordinate schedule with Sprint Releases, and most current Milestone or Product Release schedules
1. what are expectations for support, technical or user documentation:
  1. Snapshots: code only iterative/timely releases (biweekly sprints or future iterations, like 1.1, 1.1.1 etc)
  2. Milestone Releases: like OLE 0.3, 0.6, 0.8?
  3. Product Releases: like OLE 1.0, OLE 1.5, OLE 2.0 etc
Monitor final code-promotion timetable to DEMO environment to determine when code for release is locked, and also when environments might be down
Publish and communicate when servers are offline (maintenance, upgrades, refreshes, code promotions) and share with Writers- as they cannot access during those times for Screen Captures, etc.
1. Suggestion: While we may wish to maintain separate KIS groups/lists/emails for SME Teams, vs Testers Team, vs User Documentation Team, why not build a distribution-only list for system outages or whenever DEV, TST, or DEMO go up/down? Could include SME team analysts, FC leads, TC leads, writers/User doc leads etc-- to convey system messages?

IV. Resources

Garner support and SMEs via Tiger/SME Teams or thru Functional Council as additional resources for initial efforts
Identify documentation lead per module
Identify documentation team per module- existing, past, or current features (ideally a rep from each spec team, or testers)
Like “testers”, add documentation rep as assignment to each spec handoff, and begin integrating into code review meetings with SME teams
Regular meetings and training
1. Allow each module to have own meetings, organization, manage assignment
2. Monthly meetings at beginning of release for “touch base” with all writers/all modules
3. Bi-weekly documentation meetings (across all modules, and leads) in 1 month before release, and 2 months after release up to publishing date
Create sandbox for shared documents (schedules, training material, templates, and sandboxes for each module’s user documentation drafts)
Training (how to, templates, best practices, checklists)

V. Training

Don’t leave to last minute!
Solicit help from other SMEs & manage mini writing assignments where helpful!
Document Templates
1. Publish format templates to sandbox
2. Publish plain text with outline headings to sandbox
3. Writers: plain text, and import to templates?
Documentation Checklist: Content (bugs, fixes, new code, new screenshots, etc)
Documentation Checklist: QA (overall)
Documentation Checklist (Nora): Publishing
Common glossary for documentation usage:
1. 3rd person/you vs generic user, etc.
2. User vs Staff vs. Operator (libraries have indicated their vernacular for "user" means patrons of library/users of library public catalog
3. Other, esp OLE -defined terms and use of Document Store/DocStore; OLE Instance; OLE Holding vs Source Holding
Links and usage of common elements documentation- do not include in every user guide, but provide hyperlinks to common/shared Glossary, Rice terms, Edoc elements, common actions/buttons, etc.
Use of Sandbox, doc versioning, Track Changes
Gliffy Sandbox: open-source modeling tool (like Visio!) for sharing and creating workflows, dataflows, or org chart models. Checkc out the OLE Gliffy Sandbox Instructions

VI. Quality Assurance & Review

Draft Review Process (Content Completion)
Format Review Process (QA in Template, continue edits)
Quality Review Process (language, uniformity, standards, link checking)
Final Approval Doc Review (all edits via redline or plain text substitutions; single doc owners for incorporating all edits)

VII. Publishing

PDF
(Future) DocBooks
Version Control

VIII. Maintenance

Future Coding/Deliverables added
Feature Enhancements
Documentation Improvements (format, indexing, maximizing Adobe PDF outlining/indexing)
Online Help
Archiving between releases

	File	Modified
Labels No labels Preview View	Microsoft Word Document SelectAcquire User Guide Outline- Draftv3.docx V3- prelim draft outline S&A combined user guide	Oct 22, 2012 by Kathleen Gerdink (Unlicensed)

Browser not supported