Include more stats in next OSFV Status on DUG #12

[wiktormowinski]

In regards to stats section of a presentation we could include 2 more stats:

• % ratio how many tests are auto and how many are man, (need for a new script to do just that)
• number of supported models for auto tests (for example number of individual platform configs)

To follow up topics from previous
Focus on updating progress on CI runner Scoped Regression

NOTE: Also if we plan on doing OSFV Status frequently (each DUG) a new way of summing up recent big changes needs to be introduced,

• maybe a person tasked with presenting the recent updates should start preparing notes as soon as the last DUG has finished to be up to date,
• or lay this responsibility on everyone to announce changes such as: new test case/suite, script/tool, other; on a MM channel with a special tag (i.e. OSFV_STATUS-{DATE}) so that next presenter could just CTRL+SHIFT+F for brief list of changes and build up from there.
  i believe such effort would benefit the process of reporting the state of OSFV to community

[philipanda]

% ratio how many tests are auto and how many are man, (need for a new script to do just that)

As of today it won't be very representable as most manual tests are still on docs.dasharo, or as in the QubesOS tests, in a limbo state where the test does theoretically exist and is a part of the test scopes, but it is technically not implemented in OSFV nor documented on docs.dasharo. Once we transition to documenting manual test cases as robot test cases with comments it will be a great way of keeping the track of this

or lay this responsibility on everyone to announce changes such as: new test case/suite, script/tool, other; on a MM channel with a special tag (i.e. OSFV_STATUS-{DATE}) so that next presenter could just CTRL+SHIFT+F for brief list of changes and build up from there.

That would be great. Although I am afraid that it would be hard to keep the granulity of these annoucements. Some people might underestimate their work and think it's not worth mentioning, others might spam too much with little fixes that are not really fit to be presented as big achievements

[wiktormowinski]

That would be great. Although I am afraid that it would be hard to keep the granulity of these annoucements. Some people might underestimate their work and think it's not worth mentioning, others might spam too much with little fixes that are not really fit to be presented as big achievements

well now to think about it might prove to be more of a hindrance than help if somebody doesn't report contribution and presenter relies 100% on these tagged messages,
To fix that i think that defining strict categories that only useful changes can fall into

[philipanda]

Or maybe leave the scope of the presentation to someone who has access to all our projects and manages the milestones, sprints and tasks, like @BeataZdunczyk? At the very least, an early review of the planned scope from you, Beata, or @macpijan could be very valuable. Not every team member is well informed about every interesting project worth mentioning unless it already was bragged about internally

[wiktormowinski]

scope of the presentation to someone who has access to all our projects and manages the milestones, sprints and tasks

that makes sense actually

[macpijan]

At the very least, an early review of the planned scope from you, Beata, or @macpijan could be very valuable.

I would be glad to review if I have the planned scope earlier than a few hours before presentation. This presentation has been planned for months.

[philipanda]

If I have the planned scope earlier than a few hours before presentation

I Agree with that. We should start working on them much earlier. The presentation should be taken more seriously even if creating it is not a huge effort. Maybe just that could help with improving the future ones