Closed borisbaldassari closed 5 years ago
thank you @borisbaldassari , @mhow2 are you fine with these requirements or you would like to include more?
Hi @valeriocos I still need to update the XXX's and upload a drawing of what it could look like. But as far as I'm concerned this should be enough.
Well, thank you Boris, Valerio it looks pretty good to me. I have some remarks:
In addition, note that in the current state, SCAVA is not able to "group" several sources to a single project. If you have several mailing lists and bug trackers that relates a single project, the only way is to add several projects in SCAVA. Which would means additional operations when gathering everything up to a dashboard for a given project.
Here is a proposal for the look.. It can (should) be updated as we make progress, depending on the metrics, factoids, plots we can get, but the general idea is there. Please feel free to comment/criticise.
To answer Martin's questions:
* Are the dashboards expected to show up something from factoids ?
Yep, the 'FACTS' section could display both metrics and factoids.. Or they could be put in another section maybe. But it definitely makes sense, yes.
* It misses the average sentiment in bugtracker(s) (including comments of course)
Right, it should be included. Then I guess that once we have the skeleton (so to speak) it must be easy to slighty change/update the metrics or presentation..
* "history of commits over the last 3 months" doesn't tell if we are asking for a number of commits, or the list of all commit titles (strings). Maybe the drawing will tell this better.
I'm thinking of a plot here, so: "the number of daily (or weekly) commits over the last 3 months".
In addition, note that in the current state, SCAVA is not able to "group" several sources to a single project. If you have several mailing lists and bug trackers that relates a single project, the only way is to add several projects in SCAVA. Which would means additional operations when gathering everything up to a dashboard for a given project.
I'm not sure of what it implies. Without creating several projects (which would be catastrophic for the usability imho) we can still have a connector for the mailing list, and say one for the forums right? This should be further defined..
Thanks, cheers!
Without creating several projects (which would be catastrophic for the usability imho) we can still have a connector for the mailing list, and say one for the forums right?
Not 100% sure to understand but what I am saying here is : 1 SCAVA project = 1 mailing list + 1 forum + 1 issue tracker
said differently, It is not possible to assign several sources of the same kind to a single project in SCAVA
Understood.
Are the dashboards expected to show up something from factoids ?
Yes, two PRs containing an initial dashboard for factoids are available:
It misses the average sentiment in bugtracker(s) (including comments of course)
Two PRs containing an initial dashboard for sentiment are available:
"history of commits over the last 3 months" doesn't tell if we are asking for a number of commits, or the list of all commit titles (strings). Maybe the drawing will tell this better.
I'll check what we have in the data and plot something
In addition, note that in the current state, SCAVA is not able to "group" several sources to a single project. If you have several mailing lists and bug trackers that relates a single project, the only way is to add several projects in SCAVA. Which would means additional operations when gathering everything up to a dashboard for a given project.
I'm not sure of what it implies. Without creating several projects (which would be catastrophic for the usability imho) we can still have a connector for the mailing list, and say one for the forums right? This should be further defined..
This issue should be handled by SCAVA, and not by the dashboards
In addition, note that in the current state, SCAVA is not able to "group" several sources to a single project. If you have several mailing lists and bug trackers that relates a single project, the only way is to add several projects in SCAVA. Which would means additional operations when gathering everything up to a dashboard for a given project.
I'm not sure of what it implies. Without creating several projects (which would be catastrophic for the usability imho) we can still have a connector for the mailing list, and say one for the forums right? This should be further defined..
This issue should be handled by SCAVA, and not by the dashboards
—
I don't think this is a blocking issue. Indeed, it can be added as a future enhancement of the platform, but I would give it a very low priority at this stage. Does this make sense for our use case providers @boris, @aabherve, @MarcioMateus, @geryxyz , @mhow2 , @valeriocos
@davidediruscio : "several sources of the same kind to a single project" issue doesn't look blocking to me in the way we have a workaround. This being said, it could have a significant impact in the long term. I'll open an issue about it in order not to forget.
It's not a blocking issue indeed, but this information should be included before the data reaches the dashboards.
@davidediruscio Same as @mhow2 : not blocking, but useful in real life.. We can do without however for our use case.
Just opened https://github.com/crossminer/scava/issues/135 for the record.
@borisbaldassari @mhow2 I attach an initial dashboard derived from the image above
The dashboard shows (from left to right, from the top to the bottom):
commits
)Bugs
)Average Sentiment
)The dashboard misses the sys conf file table (because this data is still not available on SCAVA) and the similar projects section.
Quality attributes are uploaded only when executing Prosoul. As discussed before, if we agree on a default QM to be included in the dashboard, I can see how to automate the process to have QM data directly in the dashboard (without using Prosoul).
If the current dashboards are OK for you all (@mhow2 @borisbaldassari @davidediruscio ), can we close this issue?
Works for me, if I have updates/needs I'll open another issue. So we can close this imho.
Here are a couple of requirements that we need in order to fulfil our Use Case. We shall have a dedicated page for each defined project, easily accessible from the home page.
For each project, we shall have: