Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong lead time in Efficiency dashboards (gauge visualization) #507

Open
canasdiaz opened this issue Jan 27, 2023 · 1 comment
Open

Wrong lead time in Efficiency dashboards (gauge visualization) #507

canasdiaz opened this issue Jan 27, 2023 · 1 comment
Labels

Comments

@canasdiaz
Copy link
Contributor

When showing the lead time in the GitHub efficiency dashboards, we either have the wrong documentation or metrics. The lead time presented in the gauge is only using the items created in the selected time frame. This needs to be corrected. For example, if we select the last 6 months, the lead time would not include anything about a ticket opened for three years and recently closed.

How can this be solved? I see two options:

  1. we update the documentation both in htps://chaoss.github.io/grimoirelab-sigils/ and in the panel itself to include this limitation
  2. we do this calculation with an index pattern that uses the closing date as the default time field instead of one using the creation date
@canasdiaz canasdiaz added the bug label Jan 27, 2023
@fioddor
Copy link

fioddor commented Jan 27, 2023

At first glance, the second one makes more sense to me as the usual case: How old is the stuff we're closing in the time period.

But the first one could make sense under certain circumstances: Imagine we want to accelerate. What can we do? We can change templates or tags or automate checks. These actions affect the new stuff, so we'd like to exclude stuff created before.

And I can expect the user to expect that by default the time picker filters the creation date of the elements for most visualizations.
They can extend the time-picker and apply a filter to the closing date.

Regardless of the solution we chose, the documentation needs to explicitly disambiguate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants