Open edarsow opened 3 years ago
This issue was tabled incident to grant madness and Joanne starting grad school in DC
Migrated: Brainstormed Ideas for Help System:
A learning object represents a self-contained unit of instruction about a process or feature Written tutorial Audio and/or Video tutorials (ADA compliant pages can provide audio only) Annotated screen shots Role-based training consists of relevant learning objects for that role Body of documentation should be searchable by keyword and return results across all objects/roles Documentation components should be printable and web accessible (Ideally, PDF export) Feature change requests should be tracked such that necessary changes to documentation of those features are bundled in the same tracking workflow. Documentation processes should also respond to version releases "What's new" notices should allow users to understand changes as they happen Design principle: Don't repeat documentation in different objects, instead, break a multi-faceted object into smaller objects that can be arranged as needed. Example: managers may need less or more information than direct user of the process Eventual integration into a normalized relational database
Some ideas of metrics to track:
intensityclass
table can be used to create a schema of your desired name with intensity titles and numeric ratings to help in sorting objects that have an Intensity. Note that on the Java side, the records from theintensityclass
table are broken into two different Java objects:IntensitySchema
which stores a list ofIntensityClass
objects. This allows a bunch of different clients to use the same database table for creating custom intensity schemas.improvementsuggestionstatus
table so we can park issues that are de-prioritized and not have them cluttering up priority itemsloginmuniauthperiod
table calledassignmentrank
which is not currently used but could become part of the routing process for improvementSuggestions. NOTE: In Java we haveUser
objects which are built from records in the databse'slogin
table (legacy name)improvementsuggestion
table which currently only timestamps submission date.Changes to the tables can be made by writing a SQL script that gets pushed to the
codeconnect/database/patches
directory and submitted as a pull request to therecovered
branch.Notes from Joanne and Sean conference 20-APR'21
JL: Tickets can be classified as major and minor. Does this seem correct. Something not working would be more of a priority than feature suggestion
Notes: Associate features with a product release
ECD: Needs planned release schedule (perhaps 2-week schedules, which sprint to associate them with) PS: Releases emerge from sprint dates JL: The spreadsheet ticket/issue tracking can become the skeleton for our DB tables and Java Business Objects ECD: Develop rudimentary keying schema among our Grant deliverables, activities supporting those deliverables, the releases in which we plan to have feature X or Y included, and perhaps github issue links/numbers