Page Comparison

]

h3. II. Outline: Content & Teams

* For the Overview Documents, each Jira has an attached outline.

** Select & Acquire, including MER: [OLE-3572|https://jira.kuali.org/browse/OLE-3572

]
** Describe: [OLE-3570|https://jira.kuali.org/browse/OLE-3570

]
** Describe: [OLE-3572|https://jira.kuali.org/browse/OLE-3572

]
** Deliver: [OLE-3571|https://jira.kuali.org/browse/OLE-3571

]
* For the Big Book, the outline is below files in the [User Documentation Sandbox|https://wiki.kuali.org/display/OLE/0.8+User+Documentation

+Sandbox]

h3. III. Timeline

# Establish documentation timetables as offsets to Release Dates, for each deliverable or assignment

## Begin user documentation

### Sketch outlines: develop in tandem once specs 50% complete

### Sketch content: Spec completion/signoff + 1 week

### Drafting content: in tandem with code/development and iterative code reviews; should be able to complete outline and some content

## Draft #1 user Documentation: within 2 weeks of sprint release for coded feature

## Draft #2 user documentation: Within 2 weeks after release of final code for features, or Release overall

## Format Review copies due: Draft #2 date + 2weeks (time consuming)

## Initial QA Review due: Format Review Date + 1 week

## Final due: Initial QA date + 2 weeks

## 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

## 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

## what are expectations for support, technical or user documentation:

### Snapshots: code only iterative/timely releases (biweekly sprints or future iterations, like 1.1, 1.1.1 etc)

### Milestone Releases: like OLE 0.3, 0.6, 0.8?

### 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.

## 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?

h3. 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

## Allow each module to have own meetings, organization, manage assignment

## Monthly meetings at beginning of release for "touch base" with all writers/all modules

## 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)

h3. V. Training

# Don't leave to last minute\!

# Solicit help from other SMEs & manage mini writing assignments where helpful\!

# Document Templates

## Publish format templates to sandbox

## Publish plain text with outline headings to sandbox

## 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:

## 3rd person/you vs generic user, etc.

## User vs Staff vs. Operator (libraries have indicated their vernacular for "user" means patrons of library/users of library public catalog

## 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:OLE Gliffy Sandbox Instructions]

h3. 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)

h3. VII. Publishing

# PDF
# (Future) DocBooks
# Version Control

h3. VIII. Maintenance

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


\\
{anchor:Attachments}
{attachments}