Improvement suggestions improvement suggestions

[edarsow]

Some ideas of metrics to track:

• When the problem/improvement is logged and by whom
• I think assigning an intensity to an improvement suggestion makes sense. The 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 the intensityclass table are broken into two different Java objects: IntensitySchema which stores a list of IntensityClass objects. This allows a bunch of different clients to use the same database table for creating custom intensity schemas.
• We also want a sensible schema of ticket status records in the improvementsuggestionstatus table so we can park issues that are de-prioritized and not have them cluttering up priority items
• To whom does it get assigned? You may think about ways in which users can be assembled in a priority queue for various fix-it tasks and write some logic to assign improvementSuggestion objects to those users. Interestingly, there is an unused organ on records from the loginmuniauthperiod table called assignmentrank which is not currently used but could become part of the routing process for improvementSuggestions. NOTE: In Java we have User objects which are built from records in the databse's login table (legacy name)
• After the creation of some sort of assignment/triage system: We want a way to see for any given user, what is their priority fix to make from the improvementSuggestions records
• We want to be able to see in aggregate the status of various types of improvementSuggestions. So we'd like to be able to say things like: 45% of all improvement suggestions were classified as "small bugs" and were resolved within 12 days of filing. This will probably require multiple additional fields on the 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 the recovered 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

1. Mission-Critical: The deployed system is broken in an important way
2. Minor Bug: There's something not working correctly, but it doesn't block critical work
3. Feature Idea: Something user would like to see the system do SG Notes: In the past, the IT department categorized JL: I'd also like to know your take on the priority so we can adapt to your realities. So this would be a two-phase report: what actually is happening, and what user believes should be happening SG: I take a lot of screen shots. JL: Would multiple attachments be meaningful? SG: I'm trying to capture information in one spot so we can recreate the workflow

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

[edarsow]

This issue was tabled incident to grant madness and Joanne starting grad school in DC

[edarsow]

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