Versions Compared

Version Old Version 26 New Version 27
Changes made by

Nora Roggeveen-Sams (Unlicensed)

Nora Roggeveen-Sams (Unlicensed)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Item

Purpose

Audience

Owner

SME Contact

Reviewers

Notes

Drivers Manual Overviews /
User Documentation

Reference manual for details of how to use Broad overviews explaining the features of OLE. Provide case studies also to show how to use OLE in specific situations. Provide 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?

Will need one One per module

Will need to determine Reviewers

Need to figure out SMEs and dates 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 to lead 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

Nora with... Technical Council?

 

 

Do we want to do something like this? Or handle this in one of the other pieces of documentation? 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.
    • Select & Acquire, including

...

III. Timeline

  1. 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
  2. Add 10% +  contingency to Draft #2/Format Review dates (ie, some code won't be completed until just before release)
  3. 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)
  4. 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
  5. Monitor final code-promotion timetable to DEMO environment to determine when code for release is locked, and also when environments might be down
  6. 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?

...