⭐️ Future Issues for pre-refinement

[Sebastiaan127001]

Project requests

• I recently had a project (E) request to trigger the refresh of a metric or at least have an indication of which metric is being refeshed currently. See also Show whether the latest measurement of metric has been done with the current configuration of its source(s) #3134
• project G requested me to show the number of realised issues in the last sprint (this is not possible though JQL, but the info is available). Another use case for this came from project F:
  As a quality manager, I would like to see the percentage of issues with label X that have been part of the previously closed sprint. (what percentage were tech debt stories?). This should become possible when Allow for calculation when adding multiple sources #5098 is implemented.
• Several of my project face the problem of running out of nexus storage during software development. Can we add a collector to fetch the percentage of used storage on a Nexus host? No, is monitoring; outside scope Quality-time. There is an issue in progress to add this to the development platform at ICTU (IES-5817).
• Have the possibility to see the source up to date ness of a file stored in Nexus #5117
• Comments with long URLs don't wrap #5118

New improvement ideas

• Have the possibility in missing metrics metrics to exclude certain subject from a report. #5119
• Merge test line coverage and test branch coverage into one metric type #5120
• Link to RTD from metric rationale popup and source header #5121
• in relation to make Quality-time a more mature report (Monitor the quality of the quality management #4069) I would be useful to have the option for the user to use variables in the comment field. For this we need a section to store the placeholders and the related text. Like = "https://jira.organisation.com/". Unfortunately, Quality-time uses HTML for comments at the moment which doesn't support variables. One alternative may be to switch to Markdown for comments and investigate whether Markdown variables may offer a solution. See https://www.brianchildress.co/variables-in-markdown/.
• Security Warnings for container image scanning (like Anchore or Trivy) should be in CI subject (https://github.com/ICTU/quality-time/blob/master/components/shared_data_model/src/shared_data_model/subjects.py ) #5122: We will add extra subject types to More subject types #3130 to add "system" or "infrastructure" as possible product type.
• Add a time ago/to text to all date input fields #5123
• supply a functionality to erase all technical debt of a certain metric in one click. This could be one button that sets yes to no, deletes the related issue and deletes the end date and the accepted amount. See Add an option "No, and reset technical debt end date, clear value, and remove linked issues" #5125.
• build collector for mocha so that Quality-time can read mochaweome.json which shows Cypress test results. @Sebastiaan127001 checks whether the JUnit report of Cypress can be used instead.
• In relation to this issue: Distinguish between direct and indirect metrics. #4931 SonarQube can be a compound metric too. Violations versus the separate violations like 'long units'. The metrics for specific violation types ('long units', 'too many parameter', etc.) already support the percentage scale. The violations metric does not. Note that the percentage scale for the violations metric only makes sense when filtering violations by type or severity otherwise the percentage is always 100%.
• Measure the density of violations by dividing the number of violations by the size of the code base #5128
• apart from filtering measurement entities, it would be useful to be able to filter results in general, this might fix the version problem, see also Allow for filtering out specific measurement entities through regular expressions #3328 (comment)
• Include report title in HTML <title> #5129
• Create feature request to accept version numbers with postfix parts. Supply a few examples of version numbers that currently fail.

[Sebastiaan127001]

@fniessink as promised, I hereby include a list of software versions that development teams use, but that do not match the semver / pep standard and therefore break the software version metric.

team F
230216.post60271390
230215-a217ad48
230208-4806c8d0

team E
0.0.38.0
0.37.0
1.7.61.0-SNAPSHOT

Does this help you to improve the metric?

[Sebastiaan127001]

@fniessink as promised. I have discussed with the team the benefits of Mocha Awesome test reporter compared to JUnit. The team (G) stated that both reports contain the same information that Quality-time needs. The team advises, however, to, eventually, create a collector for the Mocha Awesome JSON since this is the standard for Cypress. The JUnit format was initially intended for unit test reports.