More subject types

[Sebastiaan127001]

When using the QT instance itself as a metric source. The issues can accumulate well above the 100 items. If QT had more detail in subject types, this could have been avoided by creating more metrics with these detailed subject types.

Suggested subject types (bold) with accompanying metrics. Subtypes have the same metrics as their supertype, plus the additional metrics listed under the subtype.

• Process
  • Continuous integration/deployment
    • Merge requests
    • Unmerged branches
    • Pipeline duration
  • Technical debt management
    • Dependencies (for outdated dependencies)
    • Issues
    • Suppressed violations
    • Violation remediation effort
  • Defect management
    • Issues
  • Test management
    • Tests
    • Test cases
    • Manual test duration
    • Manual test execution
    • (Also include test coverage metrics?)
  • Backlog management
    • User story points (to measure ready work)
    • Velocity (to know how much work should be ready)
• Software
  • Size
  • Security warnings
  • Ops
    • DORA metrics
  • Application
    • Scalability
    • Slow transactions
    • Test cases
  • Component
    • Commented out code
    • Complex units
    • Dependencies
    • Duplicated lines
    • Long units
    • Many parameters
    • Violations
  • Tests
    • Tests
    • Test branch coverage
    • Test line coverage
  • Documentation
    • Source up-to-dateness
    • Time remaining
• Development environment
  • CI-tools
    • Failed CI-jobs
    • Unused CI-jobs
  • Performancetest environment
    • Performancetest duration
    • Performancetest stability
  • Development tool
    • Source version
• Quality report
  • Missing metrics
  • Metrics

Add both the subject type and the subject subtype to the list of subjects. The subject type allows adding all metrics of the underlying subtypes.

Changes should be backwards compatible.

Tasks:

1. Rename the CI-environment "ci" to "development_environment" in the data model and the default name to "Development environment".
2. Write migration code to insert a new copy of each (non-deleted) report with the new subject key (if the report has one or more subjects with the key "ci").
3. Create a separate PR for 1 and 2.
4. Add the new subject subtypes to the data model. Subjects get an optional list of (sub)subjects, see https://pydantic-docs.helpmanual.io/usage/models/#recursive-models. In the database this should look something like this:

subjects: {
    software: {
    name: "Software",
    description: "...",
    metrics: [...],
    subjects: {
       defect_management: {
          name: "...",
       }
    }
}

1. Add a validator to check that the list of metrics of a subject type contains all metrics of all subject subtypes (recursively).

Blocked by: #8176

[Sebastiaan127001]

In addition to this, it would be useful to have a subject type for documentation, in HQ this used to be called "product quality".

[Sebastiaan127001]

@fniessink 1+ upvote for this feature request 😄

[Sebastiaan127001]

the sub-subject types above are just an example, we should refine this better to make a more adequate list

[Sebastiaan127001]

also relates to #3129

[Sebastiaan127001]

%VOTE