Thanks for this @rymai I was about to create this but didn't get to do so.
I think we should limit this to descendant sub-groups and projects.
My worry about expanding this to include projects in a different group will create complexity in permissions. E.g. including gitlab.com/charts projects into a graph configured in gitlab.com/gitlab-org/
We should rely on moving the projects for inclusion at the top/parent level.
Is there a use case where we would want to exclude a project that we have heard about? Or are we looking to reflect the metrics in the standalone app by excluding projects that are not currently imported there?
The main usecase would be throughputs, the current ask would be to limit to work that contributes into a new feature. So personal projects, experiments that do not have a bottom-line business impact will be excluded.
We have been a bit more flexible with this on our side.
First iteration is Dalia's google doc
Second iteration is the investigation into high traffic contributions
Still given the above we have been quite selective and including projects that move throughputs forward.
From the discussion with @markglenfletcher we think that inclusion would be better since its specific.
We don't want to keep updating the exclusion list if people create new projects that do not affect the bottom-line of throughputs. Hence the mechanism should be a list of included projects.
@markglenfletcher, I just discussed with @godfat on our 1:1 and I am proposing this to be moved further to make way for the label migration for all the teams.